Hi Valerie
http://cr.openjdk.java.net/~weijun/7061379/webrev.00/
The bug report says the TGS-REQ "asks for a KRB_NT_SRV_INST type whereas
the kdc answers with a KRB_NT_PRINCIPAL type. Thus, equalsWithoutRealm
function fails and authentication is refused". The KDC's behavior is a
little abnormal but RFC 4120 6.2 [1] does point out:
... The name-type SHOULD be
treated only as a hint to interpreting the meaning of a name. It is
not significant when checking for equivalence.
So I remove the name-type check in PrincipalName.equalsWithoutRealm().
This also makes equals() transitive, which is good. The hashCode()
method has never been dependent on the name-type, so there is no need to
update it.
The regression test introduced a new KDC option to set name-type for
sname in a KDC-REP to be an arbitrary value, in order to prove it is now
ignored in "checking for equivalence".
Thanks
Max
[1] http://tools.ietf.org/html/rfc4120#section-6.2
-------- Original Message --------
*Change Request ID*: 7061379
*Synopsis*: [Kerberos] Cross-realm authentication fails, due to nameType
problem
=== *Description*
============================================================
FULL PRODUCT VERSION :
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02, mixed mode)
/!\ same bug with open jdk 1.7
ADDITIONAL OS VERSION INFORMATION :
Linux x86_64 Intel(R) Xeon(R) CPU L5520 @ 2.27GHz GNU/Linux
EXTRA RELEVANT SYSTEM CONFIGURATION :
/!\ same bug with open jdk 1.7
A DESCRIPTION OF THE PROBLEM :
Authentication to remote server fails. Error doesn't appear in the logs
but the debugger points out the following error:
KRB_AP_ERR_MODIFIED (erreur 41) Message stream modified
in sun.security.krb5.KrbKdcRep class, line 56
Cross-realm authentication to one remote service is processed in
sun.security.krb5.internal.CredentialsUtil class.
It consists in the obtention of a token for the krbtgt/REALM1 at REALM2
principal.
Function acquireServiceCreds() negotiates with the kdc, by throwing
requests and receiving responses. equalsWithoutRealm() function is called.
The function equalsWithoutRealm() in sun.security.krb5.PrincipalName
checks the conformity between principal asked in request and principal
obtained in response.
However, there is a type mismatch between the two krbtgt principals:
request asks for a KRB_NT_SRV_INST type whereas the kdc answers with a
KRB_NT_PRINCIPAL type. Thus, equalsWithoutRealm function fails and
authentication is refused.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Try to access from one realm to whatever remote 'kerberized' service.
For example: GSSAPI and JNDI for remote LDAP server.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expected result: successful authentication with remote service access.
ACTUAL -
Error is caught but not reported in system.out, and remote
authentication fails.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
KRB_AP_ERR_MODIFIED (erreur 41) Message stream modified
in sun.security.krb5.KrbKdcRep class, line 56
is reached but never thrown to the logs.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Modifying the acquireServiceCreds() function solves the problem. But
maybe the best solution is to change the request for a cross-realm krbtgt.
Line 134 in CredentialsUtil.java:
for (cTgt = ccreds, i = 0; i < realms.length;)
{
// tempService = new
ServiceName(PrincipalName.TGS_DEFAULT_SRV_NAME,
// serviceRealm, realms[i]);
if (!localRealm.equalsIgnoreCase(serviceRealm)) { //do cross-realm
authentication
if (DEBUG) {
System.out.println(">>>DEBUG: Credentails request cross realm
ticket for " + "krbtgt/" + serviceRealm + "@" + localRealm);
}
tempService = new ServiceName("krbtgt/" + serviceRealm + "@" +
realms[i]);
}else{
tempService = new ServiceName(PrincipalName.TGS_DEFAULT_SRV_NAME,
serviceRealm, realms[i]);
}
if (DEBUG)
{
System.out.println(">>> Credentials
acquireServiceCreds: main loop: [" + i +"] tempService=" + tempService);
}
...
...
...
SUPPORT :
YES