<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Hi Michael,
<div><br>
</div>
<div>Java starts from the default KDC and it expects a referral could happen. Does MIT krb5 always start from the client’s own KDC?</div>
<div><br>
</div>
<div>If you change the default realm to <a href="http://AD001.SIEMENS.NET">AD001.SIEMENS.NET</a>, does it work? Does it work with your other scenarios?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Max<br>
<div><br>
<blockquote type="cite">
<div>On Aug 30, 2024, at 05:09, Osipov, Michael (IN IT IN) <michael.osipov@innomotics.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div>Folks,<br>
<br>
please consider the following case/bug with JGSS:<br>
Tried with OpenJDK 8u4xx, can try newer, but doubt that it will be any different.<br>
<br>
* KDCs are Active Directory<br>
* Machine: member of INNOMOTICS.NET<br>
* krb5.conf: Default realm is INNOMOTICS.NET<br>
* Client: Logged in from a different realm in this machine: foo@AD001.SIEMENS.NET<br>
* One-way trust from AD001.SIEMENS.NET, means with an account from AD001.SIEMENS.NET you can access resources from both realms, but you cannot access resources from AD001.SIEMENS.NET with your INNOMOTICS.NET account. That is on purpose.<br>
<br>
Use case:<br>
Client wants to access AD DS via LDAP and authenticate with an SASL GSSAPI bind: ldap@dc1.ad001.siemens.net. Client and target realm are identical. AS-REQ, AS-REP from AD001.SIEMENS.NET are fine, now here is the problem: To form the TGS-REQ it requests a cross-realm
TGT for INNOMOTICS.NET and then asks a KDC in INNOMOTICS.NET for a service ticket for ldap@dc1.ad001.siemens.net. This KDC of course says:<br>
<blockquote type="cite">16174 >>>KRBError:<br>
16175 sTime is Thu Aug 29 20:19:07 CEST 2024 1724955547000<br>
16176 suSec is 106542<br>
16177 error code is 7<br>
16178 error Message is Server not found in Kerberos database<br>
16179 sname is ldap/dc1.ad001.siemens.net@INNOMOTICS.NET<br>
16180 msgType is 30<br>
</blockquote>
<br>
End of story. The bug for me is that, for some reason, JGSS assumes that the target is in the default realm of the machine instead of asking its own realm which should give it all necessary cross-realm referrals.<br>
<br>
Here is what MIT Kerberos does:<br>
<blockquote type="cite">$ cat /etc/krb5.conf<br>
# Kerberos configuration<br>
[libdefaults]<br>
default_realm = INNOMOTICS.NET<br>
forwardable = true<br>
canonicalize = true<br>
dns_lookup_kdc = true<br>
dns_canonicalize_hostname = false<br>
qualify_shortname = ""<br>
rdns = false<br>
udp_preference_limit = 1<br>
kdc_timeout = 1000<br>
max_retries = 1<br>
$ klist<br>
Ticketzwischenspeicher: FILE:/tmp/krb5cc_2011<br>
Standard-Principal: foo@AD001.SIEMENS.NET<br>
Valid starting Expires Service principal<br>
2024-08-30T10:13:05 2024-08-30T20:13:05 krbtgt/AD001.SIEMENS.NET@AD001.SIEMENS.NET<br>
erneuern bis 2024-08-31T10:10:22<br>
$ ldapwhoami -H ldap://ad001.siemens.net<br>
SASL/GSSAPI authentication started<br>
SASL username: foo@AD001.SIEMENS.NET<br>
SASL SSF: 256<br>
SASL data security layer installed.<br>
u:AD001\foo<br>
$ klist<br>
Ticketzwischenspeicher: FILE:/tmp/krb5cc_2011<br>
Standard-Principal: foo@AD001.SIEMENS.NET<br>
Valid starting Expires Service principal<br>
2024-08-30T10:13:05 2024-08-30T20:13:05 krbtgt/AD001.SIEMENS.NET@AD001.SIEMENS.NET<br>
erneuern bis 2024-08-31T10:10:22<br>
2024-08-30T10:13:19 2024-08-30T20:13:05 ldap/dc1.ad001.siemens.net@<br>
erneuern bis 2024-08-31T10:10:22<br>
Ticket server: ldap/dc1.ad001.siemens.net@AD001.SIEMENS.NET<br>
</blockquote>
<br>
Also looking at the output of KRB5_TRACE and pcaps MIT Kerberos never contacts any KDC in INNOMOTICS.NET.<br>
<br>
The workaround is the following in krb5.conf:<br>
<blockquote type="cite"># JGSS does not use the client's realm to obtain a ticket and needs this hinT<br>
[domain_realm]<br>
.ad001.siemens.net = AD001.SIEMENS.NET<br>
ad001.siemens.net = AD001.SIEMENS.NET<br>
</blockquote>
<br>
This is ugly because:<br>
* I have to do this on all affected machines and cannot rely on AD to give me the right referral<br>
* if I have an SPN, e.g. HTTP/svc.ad001.siemens.net in INNOMOTICS.NET, a migrated machine from AD001.SIEMENS.NET to INNOMOTICS.NET available under multiple virtual hostnames the init_sec_context will likely fail because that SPN is not known AD001.SIEMENS.NET,
I can hope that AD will send me a referral. But in any case it will incur unnecessary round trips. I need to explicitly exempt those hosts here throughout my setup.<br>
<br>
Max, can you have a look at this? I can provide all the necessary debug/trace/pcap files to you. Just let me know what you would like to see.<br>
<br>
Michael<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>