On Fri, May 8, 2009 at 4:26 AM, Markus Moeller <[email protected]> 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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
