Are there conventions for service principal naming?
Douglas E. Engert
deengert at anl.gov
Mon Dec 14 12:35:19 EST 2009
Matthew M. DeLoera wrote:
> Over the past few days I've managed to discover some details about
> service principal naming that I wanted to confirm with all of you, if
> you please.
> If my SPN is in the form service_name/fqdn at REALM :
> - I'm running gssglue (Ubuntu) with the MIT GSS-API and krb5 libs. When
> I sniff with WireShark, I notice that the SPN in my requests is always
> forced to all lower-case, regardless of what my code specifies. This
> burnt me some when I was recently debugging a linux service with AD2003.
> I couldn't understand why I kept getting "no principal in keytab matches
> desired name". It took forever to finally notice mixed-case in what
> should have been the matching principal in my keytab. (I'd inadvertently
> specified all upper-case when I ran ktpass in AD). I've since managed to
> google some mention that the fqdn *must* be all lower-case. So, is it
> correct that my fqdn will always be forced to lower-case on the wire? If
> so, there are a couple changes I'd want to make in my own software.
> - Are there any guidelines to what I should use for service_name? Any
> lower/upper case conventions? Right now I'm just using "host/", and I
> haven't managed to find any definitive rules on a convention to follow.
Kerberos principals are case sensitive.
Windows is case insensitive. AD will try and preserve the case from a
Kerberos request and return the same case in the response.
FQDNs are based on DNS names and are usually written as lower case.
(Not sure if *must* be all lower-case is required or not but makes it easier.)
(The gssglue maybe converting to lower for you. Check the code.)
The service part of a principal can be mixed: HTTP is upper, host is lower.
The salt for DES and AES is case sensitive even in AD, but AD is using the
sAMamAccountName and uppercase of AD domain name not the UPN in the salt.
So easiest thing to do is to use lower case for all names, except for the
service names like HTTP.
> That's all. No problems to speak of, otherwise!
> - Matthew
> krbdev mailing list krbdev at mit.edu
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
More information about the krbdev