我有一个有关域成员服务器上的LSA SIDcaching的问题。 最近我遇到了这个问题，当他们的名字在AD后更改了一些用户访问应用程序我支持困难，他们也有旧的用户名显示在SharePoint网站上。
经过一些谷歌search/研究，我发现下面的微软KB 946358和我原来是原因。
这篇文章有点简单，只是说
caching条目超时，然而应用程序的循环查询可能会使caching条目的最大生存期保持现有的caching条目存活
并build议通过将LsaLookupCacheMaxSizeregistry项设置为0来closures成员服务器上的此caching，从而禁用LSA本地caching。
这有些奇怪的select，因为它可能会影响性能，看起来不是一个真正的解决scheme。 谷歌search使用LsaLookupCacheMaxSize作为关键字，许多人遇到这个问题，但我没有find任何最终解释如何正确解决这个问题。
因此，我确认禁用LSA本地caching有助于 – 但它不是真实世界生产环境的选项，服务器重新启动也会清除此caching – 每当用户重命名时，重新启动应用服务器也不是很好的解决scheme。 感谢这个博客文章，我发现可行的解决方法，但仍然有兴趣解决这个问题。
因为我只在应用程序中看到了这个问题，而在testing环境中的相同应用程序没有这样的问题（重命名用户工作，旧的入口不卡在caching中），而这两个环境属于相同域，并使用相同的用户进行testing。 这很符合MS KB的措辞，一些应用程序活动可能会导致永久保存在caching中的logging，但接下来呢？ 只有更多的问题…
我如何重现这一点？
LsaLookupCacheExpireTime 默认值为7天 ，所以即使不是非常活跃的应用程序会在这段时间触摸它不应该引起这样的问题，对吧？ 我的意思是应用程序查询后，它的成员服务器不应该再增加7天的caching项的TTL，对吧？ 否则每个logging都会永远存在caching中…然后又是什么阻止成员域服务器偶尔去DC，如果findlogging不匹配的话在cache中find错误logging？
看看有关类似问题（有没有最近的post/关于它的问题）的post的时间可能是它是由一些MS修补程序，或在较新的Windows Server版本（在我的情况下，我在Windows Server上看到这个问题2008 SP1标准，testing环境有2008 SP1企业版）。
我有一个想法，我可以使用Procmon来监视LSAcachingpath，并确定什么应用程序触摸caching项太频繁，但目前还不清楚我的下一步可能是什么，因为我不明白需要什么条件才能将此logging保存在caching永远…盲目减less这种活动/改变应用程序设置似乎不是很好的解决scheme太….
总之，我希望能够重现这一点，也就是理解什么情况会导致重命名用户在本地caching中“卡住”过时的caching条目。 如果有人能够在这里说明一下，我将不胜感激。