1

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

Community
  • 1
  • 1
Nikhil L
  • 175
  • 1
  • 3
  • 16
  • I have found that there can be up to a 5 minute lag after linking a new SPN with a username via either _setspn_ or _ktpass_ commands before it succeeds. I think this is due to AD replication, rather than some caching mechanism. You did detach the SPN from the original username correctly using _setspn -D_. Go ahead and run kinit username1 with the SPN right now- does it succeed now or fail? Syntax is: kinit -k -t path\to\keytab HTTP/FQDN – T-Heron Dec 28 '16 at 12:49
  • Please also consider adding the additional tags of _spn_, _active-directory_, and _kdc_ to your question. – T-Heron Dec 28 '16 at 13:17
  • Hey, I did try kinit username1 - this works fine and kinit HTTP/FQDN fails with client not found, kinit -k -t path\to\keytab HTTP/FQDN fails with KrbException: Do not have keys of types listed in default_tkt_enctypes available – Nikhil L Dec 29 '16 at 06:45
  • Can you post the result of the following command: _setspn -L username1_. It appears that the mapping of the HTTP/FQDN SPN to username1 had a syntax error of some sort. Alternatively, you can just post a screenshot of the Account tab of AD user account _username1_ as an edit to your question. I am positive this will reveal the source of the error, and the next steps to resolve it will become evident. – T-Heron Dec 29 '16 at 12:35
  • C:\kerberos>setspn -L test225 Registered ServicePrincipalNames for CN=test225,CN=Users,DC=eqsectest,DC=local: HTTP/VINW12SEC5225.EQSECTEST.LOCAL – Nikhil L Jan 02 '17 at 06:01
  • For the AD account _test225_ in the AD domain _eqsectest.local_, go to the Account tab. At the very top, under _User logon name:_ does the SPN _HTTP/vinw12sec5225_ appear, or does it just show _test225_? – T-Heron Jan 02 '17 at 12:59
  • it shows the SPN there HTTP/VINW12SEC5225.EQSECTEST.LOCAL – Nikhil L Jan 03 '17 at 04:31
  • One more thing. Does it show _HTTP/VINW12SEC5225_ inside the _User logon name:_ field or does it show the full _HTTP/VINW12SEC5225.EQSECTEST.LOCAL_? And to the immediate right of the _User logon name:_ field, does it display _@EQSECTEST.LOCAL? Please try to be as specific as you can in the response, as it can reveal the error source. – T-Heron Jan 03 '17 at 04:38
  • under the user logon name is shows :- 1st box HTTP/VINW12SEC5225.EQSECTEST.LOCAL and 2nd box @eqsectest.local – Nikhil L Jan 03 '17 at 05:05
  • Where are you running kinit on - a Windows or a Linux machine? Try this: kinit -k -t path/to/your.keytab HTTP/VINW12SEC5225.EQSECTEST.LOCAL – T-Heron Jan 03 '17 at 05:17
  • I run kinit on the same windows server machine(2012 where KDC is also present). running the command kinit -k -t path/to/your.keytab HTTP/VINW12SEC5225.EQSECTEST.LOCAL gives the same error client not found in Kerberos database – Nikhil L Jan 03 '17 at 05:33
  • Using Notepad++ (not regular Notepad) can you right-click and edit your keytab file, simply copy the contents of the keytab file (don't make any changes) and then give the results here? The secret key inside will be encrypted - and that's ok, what I need to see is how the SPN is formulated inside the keytab. That will be the final clue to this. – T-Heron Jan 03 '17 at 13:08
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/132195/discussion-between-nikhil-l-and-t-heron). – Nikhil L Jan 03 '17 at 13:25
  • @T-Heron - I'll be testing this out in a day or 2 and updating you soon – Nikhil L Jan 25 '17 at 06:47

1 Answers1

0

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/VINW12SEC5225.EQSECTEST.LOCAL@EQSECTEST.LOCAL /ptype krb5_nt_principal /crypto All /mapuser krbspn@EQSECTEST.LOCAL /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.

T-Heron
  • 5,385
  • 7
  • 26
  • 52
  • Hi, So I have tried this and still get the error :-( Exception: krb_error 6 Client not found in Kerberos database (6) Client not foun d in Kerberos database KrbException: Client not found in Kerberos database (6) – Nikhil L Jan 30 '17 at 05:20
  • I am starting to believe this might be an issue with my Server VM itself.. do you suspect the same?? Should I give this a try on some different environment? – Nikhil L Jan 30 '17 at 05:21
  • I added more to the answer, regarding why the "client not found in Kerberos database" error could be coming. – T-Heron Jan 30 '17 at 09:39
  • I opened up the keytab file and checked the SPN - it's correct ... however I found another keytab file with a different username with this same spn - note - this SPN is attached to krbspn only right now and -X does not reveal any SPN duplications in the AD – Nikhil L Jan 30 '17 at 12:10
  • I have deleted the older keytab file and gone through all the above steps again - no change in the error message - should I delete every thing and reboot the server ?? will this help?? – Nikhil L Jan 30 '17 at 12:11
  • Yes, please restart the application service if anything is changed regarding the keytab. Rebooting the server would accomplish that as well of course. – T-Heron Jan 30 '17 at 14:14
  • This hasn't worked and I am not sure why. All my new SPNs are working except for this one. So I have stopped researching on this one now. I will accept this as an answer as it works in other cases (for all SPNs apart from this) – Nikhil L Feb 09 '17 at 04:21