The NT Token Cache

The NT Token cache on the web server – Maybe you didn’t know this even existed…

Consider this scenario:

You are setting up ADFS in a federated scenario with SharePoint configured as a token based application. 

The initial setup has miscellaneous configuration errors that you correct along the way.  You test again and find some more configuration issues further down the line.  Each time you correct something – you try to get to the web site with your client machine and your test account.  Each time – you are getting closer and closer. 

Sound familiar? 

You finally make it to the SharePoint page and you are happy…No errors from the Federation Servers and things went as expected.   Maybe not 100% the way you expected – but you just need to make some minor changes with the SharePoint permissions, then you are ready to test out some different claims and other items you have on your list.

OK – careful right here.  Something happened under the hood here – and it’s important!

Let’s talk about what just happened when you finally made it to SharePoint error free.  The ADFS token based web agent wrote a NT token on the web server and this user (identified by their identity claim) will find and use this same token on subsequent requests to applications on this box for the next 60 minutes.

See where you can run into trouble during initial setup and testing?  Let's continue with this example…

Let's assume that when you first accessed the site (successfully) – you had a UPN identity claim and Group Claim A (which mapped to Windows Group A).  The agent wrote a token with the SID of Windows Group A on the web server.  You then realize you need to test Group Claim B which is associated with Windows Group B.   You take all the correct steps necessary – add him to a different group on the account side, log off/log on, test again. 

 Hmmm – you are still getting the permissions associated with Group Claim/Windows Group A.   You start checking your configuration - looking at logs – you see the Group claim B getting passed as it should from the FS-A to the FS-R – but when the user gets to the Web Server – you don’t have the permissions you associated with group claim B. 

Now the doubt starts to creep in…Just when you thought you had the hang of this claim thing 😉 

You check/double/triple check your configuration – maybe you configure group claim C – same thing!  What changed you ask yourself? Trying a different user on the account side probably never occurred to you (I know it never does to me when I’m in this place).

Hopefully you read this (and remember about the NT Token Cache) before you spin your wheels too long with a scenario as I described here.   The example I gave above is not the only way you can get in trouble here – It’s just one of the ways.

If you enable debug logging on the web server, you will see a message indicating that a cache entry has been found

When  you are in the lab and are going to be making changes, testing, then more changes, and more testing – You may want to consider reducing the CacheEntryLifetime to the minimum (1 minute)  from the default (60 minutes).  To do this – add the following registry values to the web server at this location:


CacheEntryLifetime – dword – 60 decimal

CacheScavengeInterval – dword – 60 decimal

Reboot the server for these changes to take effect. 

Now – you can continue your testing without hitting this type of problem.  Keep in mind – this is for lab environments only.  I have no idea what this would do to a busy production web server from a performance standpoint.

A complete list of all the cache settings is located here

This blog certainly raises some questions (for me anyway) - when I tried to test things to verify and provide more detailed information, I got into a major rat hole…

I’ll follow up with more detailed information like:

  1.  How the debug logs look – how to verify this is what you are hitting

  2. Shadow account existence – and the account partner “ resource account” setting

I think more detailed items on the subject are needed here.  I’m going to put this out for now and build on it later.








Comments (2)
  1. Scott Goad says:

    You just saved me a lot of time — thank you.

  2. MDordoy says:

    I was experiencing the same issue as detailed in this blog. I suspected this was the case but wanted to find some evidence that supported this. I then found this blog and the following: which also support this evidence. Thanks for this, the blog was very helpful. To be clear to others reading this, the web server is the ADFS

Comments are closed.

Skip to main content