0

I've been exploring Kerberos Single Sign On (SSO) to replace NTLM for a Web Application hosted internally within a Windows Domain.

After creating Service Principal Names (SPN) for a test service (setspn -s) I can clearly see - using Fiddler or WireShark - that authentication has switched from NTLM to Kerberos.

Having a cautious infrastructure team I'd like to prove that the change can be backed out quickly and easily. I do not wish to force NTLM through Web Server configuration. Correspondingly the SPNs are deleted (setspn -d) and their deletion is confirmed (setspn -q).

I run the following command to remove all Service Tickets on the client:

C:\>klist purge

Current LogonId is 0:0x521ac
        Deleting all tickets:
        Ticket(s) purged!

C:\>

When further interaction takes place with the Web Application another Service Ticket is created and Kerberos continues to be the SSO authentication mechanism. This holds true for users that had not previously used the service. This is even the case the following day after all interaction has been idle overnight (12-14 hours).

Although I've made repeated searches to find an explanation for the observed persistence I've come up empty handed. However I think I've found a clue in the article; The LsaLookupSids function may return the old user name instead of the new user name if the user name has changed:

The local security authority (LSA) caches the mapping between the SID and the user name in a local cache on the domain member computer. The cached user name is not synchronized with domain controllers. The LSA on the domain member computer first queries the local SID cache. If an existing mapping is already in the local SID cache, the LSA returns the cached user name information instead of querying the domain controllers. This behavior is intended to improve performance.

The cache entries do time out, however chances are that recurring queries by applications keep the existing cache entry alive for the maximum lifetime of the cache entry.

Can anyone confirm if the Key Distribution Center (KDC) caches SPN entries in a similar manner (or provide an alternative explanation)? If so what are the cache entry's maximum lifetimes?

Community
  • 1
rtev
  • 101
  • 2

1 Answers1

0

I discovered the problem. The DNS record for the service was not an "A" record but actually a "CNAME" record. This means that the browser was creating a key for the service account. This is related to the setting "useAppPoolCredentials" on the site/server which was set to "False" (the default). The SPNs to which I was making changes were not taking part in the Kerberos authentication that was taking place.

rtev
  • 101
  • 2