I have a question about LSA SID cache on a domain member server. Recently I run into the issue when some users after their name was changed in AD has difficulties accessing application I support, and they also have old user name shown on SharePoint sites.
After some googling/research I found following Microsoft KB 946358 and I turned out to be the cause.
This article is a bit laconic and just telling that
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
and suggests to switch off this cache on a member server by setting LsaLookupCacheMaxSize registry key to 0 which disables LSA local cache.
This is slightly strange option as it may have performance impact and doesn't looks as a real solution. Googling using LsaLookupCacheMaxSize as a keyword that many people run into this issue but I didn't find any final explanation on how to address this properly.
So I do confirm that disabling LSA local cache helps - but it's not an option for real world production environments, also server restart will clear this cache - not very good solution also to reboot your app server each time user has been renamed. Thanks to this blog post I found viable workaround but still interested to address this properly.
As I saw this issue with the application in live environment only, whereas the same app in the test environment doesn't have such issue (renamed user works, old entry doesn't stuck in cache) whereas both of this environments belong to the same domain, and the same users were used for tests. This is well in line with MS KB wording that some app activity may cause holding the record in the cache forever, but what next? Only more questions...
How I can reproduce this?
LsaLookupCacheExpireTime has default value of 7 days, so even not very active app will touch it over this period an it should not cause such issue, right? I mean after app queries it member server should not increase the TTL of cache entry for 7 days again, right? Otherwise every record will be in the cache forever... And then again what prevents member domain server to go occasionally to DC and if record mismatch is found scavenge wrong record in cache?
Looking at the time of the posts about similar problems (there are no recent posts/questions about it) it could be that it was addressed by some MS patch, or in newer Windows Server versions (in my case I saw this issue on Windows Server 2008 SP1 Standard, test environment has 2008 SP1 Enterprise).
I have an idea that I can use Procmon to monitor LSA cache path and identify what app touched cache entry too often, but it's unclear what my next step could be as I don't understand exactly what conditions are required to keep this record in cache forever... Blindly decreasing this activity/changing app settings seems to be not very good solution too....
In short I want to be able reproduce this, i.e. understand what conditions cause obsolete cache entry for renamed user "stuck" in local cache. I will appreciate if somebody can shed some light here.
