Null realms and servers

Jeffrey Altman jaltman at
Fri Dec 15 18:51:35 EST 2006

I believe that matching against the default realm is the correct
change for this case.

Jeffrey Altman

Sam Hartman wrote:
> Folks, I noticed a behavior change in 1.6 and I want to discuss it.
> In previous versions, you end up calling krb5_sname_to_principal
> (probably via gss_import_name) on the server to construct the
> principal to look up in the keytab.  If you have a domain_to_realm
> mapping that is used to determine the realm.  If not, then the domain
> name is upper cased and treated as a realm.
> However the behavior of sname_to_principal changed in 1.6.  IF there
> is no domain realm mapping, then it returns a null realm.  The code
> that gets a ticket from the KDC uses this as a trigger to start at the
> client's realm.
> However the keytab code is not changed.  So if your service is missing
> a domain_realm entry, it will not find its keys.
> First, is it acceptable to release 1.6 in this stae.  My gut feeling
> is that we will need to document the bug, but it is acceptable.  It's
> not great and we want to fix it.
> I'm also not sure what the fix is.  One option would be to match any
> realm if you get a null realm principal in the keytab code.  I dislike
> this option a lot even though I think Doug would like it.  The problem
> is that you get behavior that might encourage some people to remove
> domain_realm mappings.
> Another option is to match against the default realm in the keytab
> code if you get a null principal.  This provides a change in behavior
> over previous versions but is probably the best compromise.
> _______________________________________________
> krbdev mailing list             krbdev at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url :

More information about the krbdev mailing list