confusion with service principal names in Active Directory

John Jasen jjasen at
Mon Mar 30 12:06:42 EDT 2009

Please forgive me if this is not the right venue.

I seem to have not found the magic required to use kerberos service
principal names on unix systems against an Active Directory server.

In the one particular example, we're trying to use kerberized NFS, so
the server daemon needs to be able to find nfs/fqdn at REALM.

I can see the entries in the computer accounts servicePrincipalName
field, but the various UNIX systems can't find them -- either on service
initialization, or attempting kinit from commandline with the system keytab.


klist -ke /etc/krb5.keytab | grep host

2 host/ at EXAMPLE.REALM (DES cbc mode with CRC-32)

[root at kernelpanic ~]# kinit host/ -kt
kinit(v5): Client not found in Kerberos database while getting initial

(same results if I do host/ at EXAMPLE.REALM)

This behavior holds true for OS X kerberos clients, Red Hat 4 and 5
kerberos clients, and Solaris 10 kerberos clients. I can provide the
versions if required.

The AD server in question is Windows 2003 R2.

The only way I've found around this is to set the userPrincipalName in
AD to the service I really really need.

ie: in the case above, userPrincipalName is set to
nfs/ at EXAMPLE.REALM. After doing that, I can kinit
that service principal successfully, and the service dependent on it can
also initialize correctly.

>From my testing, using ktpass.exe to write a keytab file seems to pretty
much automatically set the userPrincipalName to the last entry created.
Unfortunately, if you have a multi-role server, this creates
difficulties. (ie: trying to use http/hostname and sql/hostname).

Is there a way around this that I've missed? An option either on the
client side or the server side that I've missed?

-- John E. Jasen (jjasen at
-- No one will sorrow for me when I die, because those who would
-- are dead already. -- Lan Mandragoran, The Wheel of Time, New Spring

More information about the Kerberos mailing list