Kerberos SPN gets cached on Windows Servers?

Question

Been integrating Kerberos authentication in my SSO project. Came across a peculiar scenario.

I made a new user and attached an SPN to it. Followed steps on this question and got everything working. By everything I mean :-

1. kinit username - and then entering password gave me the message that ticket was saved.
2. kinit spn(int the format HTTP/FQDN) - and then entering password gave me the message that ticked was saved.

After some time I decided to try this over once again, and so I used the command

setspn -D spn username

to detach the spn from username. Then I deleted this user(username) from AD.

Next I created a new user say username1 and did as per this question to register the same spn as in above step for this new user.

Now kinit username1 - and entering password gave the message that ticket is saved, however kinit spn - and entering password gave me the error

client not found in Kerberos database.

Note that everything works fine if I use a different(new) spn.

So the question is, does Windows server have certain cache wherein some links are still present due to which I am not able to use this spn again? Or did I do some mistake while detaching the spn from user?

Thanks, Nikhil

Answer 1

After reviewing what you wrote in Chat, as well as the full problem history, the problem is actually two problems. (1) You need to always delete the in-use SPN before creating the keytab. (2) Inside the ktpass.exe keytab creation command, you will need to map the user using the SPN of HTTP/vinw12sec5225.eqsectest.local, instead of the short logon name krbspn. Also, I will just make an observation - you do not need to place the SPN in all caps. That makes it hard to read, though for sake of continuity, I did not change that. Only the Kerberos realm should be in all caps. Based on the information you provided, to resolve this case, you should perform the following commands:

1. setspn -D HTTP/VINW12SEC5225.EQSECTEST.LOCAL krbspn
2. ktpass /princ HTTP/[email protected] /ptype krb5_nt_principal /crypto All /mapuser [email protected] /out c:\ticket\krbspn.keytab -kvno 0 /pass eQ@12345
3. klist -e -k -t c:\ticket\krbspn.keytab

For a reference, I show an example of how to create a keytab when Microsoft Active Directory is in use as the Directory Service here: Kerberos Keytabs – Explained. I also provide an accompanying explanation of each ktpass.exe syntax parameter.

To help resolve what still could be wrong after the above steps, then using Notepad++ (not regular Notepad) right-click and edit your keytab file, simply copy the contents of the keytab file (don't make any changes) and then examine the results. The secret key inside will be encrypted - that's ok, look at how the SPN is formulated inside the keytab. It should match to what is shown for the SPN on the AD account. When these don't match you will get "client not found in Kerberos database" error. Also ensure the application server config is pointed to the right keytab file and restart the application service if anything is changed regarding the keytab.