[security-dev 00103]: How to get the default Kerberos realm?

Max (Weijun) Wang Weijun.Wang at Sun.COM
Wed Mar 12 08:06:29 UTC 2008


Hi All

Currently, the JDK works like this (in sun.security.krb5.Config):

1. If the java.security.krb5.kdc system property is set, return it
2. If [libdefaults] default_realm exists in krb5.conf, return it
3. Using DNS (if allowed)
    a. Find the full qualified host name of the localhost
    b. Find its longest rightmost match in [domain_realm] in  
krb5.conf, or return null
    c. Try to locate this match in DNS using the entry  
_kerberos.THE.LONGEST.MATCH, or shorter, say, _kerberos.LONGEST.MATCH  
etc, until a record is found, or return null
    d. If the record's TXT value include THE.MATCH, return it, or  
return null

It seems b,c in 3 is merely a confirmation of a, which means both  
domain_realm mappings and DNS must agree on the value of the realm. I  
think this AND rule should be changed into an OR rule. Also, the DNS  
search should not be based on realm name, but domain name, which is  
how DNS normally works.

Thus, I'd like to split 3 to two parts:

3'. Using domain_realm
    a. Find the full qualified host name of the localhost F.Q.H.N
    b. Find its longest rightmost match in [domain_realm] in  
krb5.conf, return it
4'. Using DNS (if allowed)
    a. Try to locate it in DNS using the entry _kerberos.F.Q.H.N, or  
shorter, say, _kerberos.Q.H.N etc, until a record is found
    b. return the record's TXT value (wish there's only one)

Also, if a local credential cache (either krbccc_XXX file or LSA)  
already includes an initial TGT, it should be used directly. Thus,  
I'd like to add between 2 and 3 a new rule between 2 and 3:

2'. If a credential cache already includes an initial TGT, return the  
issuer's realm.

This is useful because the machine and the logon user can be  
registered in different domain. For the sake of SSO, kerberos  
settings would better follow the user, not the machine.

So my suggestion is 1 - 2 - 2' - 3' - 4'.

Any ideas?

Thanks
Max




More information about the security-dev mailing list