kerberos tickets and the SPNs

[Ravi Channavajhala]

On Fri, May 8, 2009 at 4:26 AM, Markus Moeller <huaraz at moeller.plus.com> wrote:

>> Interesting.  This means, I need to have all the SPNs included in the
>> keytab?  Do you see an inherent problem with deleting the existing
>> SPNs on windows KDC and adding only one SPN of the form host/fqdn and
>> generating the keytab?
>>
>
> The best would be to have one entry in AD with the host/fqdn syntax. If you
> have clients requesting HOST/fqdn just use the above method to add a second
> entry with the same key. AD will handle HOST/fqdn and host/fqdn in the same
> way as it is case insensitive, so no need to add a second entry to AD.

I deleted the computer object in AD, waited for the replication to
complete and then re-added the AD object.  Now the SPN appears as

host/host.fqdn

Which is good.  I ran the ktpass to generate the new keys for this
host using the SPN created with the correct realm.  Now, when Solaris
is trying to authenticate a AD user, I still get the server not found
in kerberos database, modifying the keytab manually with ktutil on
solaris gives me PAM-KRB5 (auth) the key table entry not found.  If it
is of any academic value, in the -mapuser switch I used is an ordinary
AD user (not even a service account) whose name is same as the
computer name.  One is cn=users, the other cn=computers, so I dont
believe this could be the problem. For the kicks, I created another
user whose name is not the same as the host and tried...no luck.  So
having distinct SPN, UPNs also didnt work.

As a last desperate measure, is there any elegant way to examine the
kerberos database to see if a sticky reference to the host principal
is lingering around and forcibly delete it?  This is really getting a
bit vexing