Null realms and servers
jaltman at secure-endpoints.com
Fri Dec 15 18:51:35 EST 2006
I believe that matching against the default realm is the correct
change for this case.
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 mit.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20061215/26d4ca71/attachment.bin
More information about the krbdev