我对域成员服务器上的 LSA SID 缓存有疑问。最近我遇到了一个问题，有些用户在 AD 中更改了姓名后，无法访问我支持的应用程序，而且 SharePoint 网站上还显示了旧用户名。
经过一些谷歌搜索/研究，我发现以下内容Microsoft 知识库 946358 而我才是罪魁祸首。
这篇文章有点简洁，只是说
缓存条目确实会超时，但应用程序的重复查询可能会使现有缓存条目保持活动状态，直至达到缓存条目的最大生存期
LsaLookupCacheMaxSize并建议通过将注册表项设置为来关闭成员服务器上的此缓存0禁用 LSA 本地缓存。
这是一个有点奇怪的选项，因为它可能会影响性能，而且看起来并不是一个真正的解决方案。使用LsaLookupCacheMaxSize关键字谷歌搜索时，许多人都遇到了这个问题，但我没有找到关于如何正确解决这个问题的最终解释。
因此，我确实确认禁用 LSA 本地缓存会有所帮助 - 但这不是实际生产环境的选项，而且服务器重启也会清除此缓存 - 每次用户重命名后都重启应用服务器也不是很好的解决方案。感谢这个博客文章我找到了可行的解决方法但仍然有兴趣正确解决这个问题。
我发现这个问题只出现在实时环境中的应用程序上，而测试环境中的同一个应用程序没有这样的问题（重命名的用户有效，旧条目不会滞留在缓存中），而这两个环境都属于同一个域，并且测试使用的是同一个用户。这与 MS KB 的措辞完全一致，即某些应用程序活动可能会导致记录永远保留在缓存中，但接下来该怎么办？只有更多问题……
我怎样才能重现这一现象？
LsaLookupCacheExpireTime有默认值为 7 天，因此即使不太活跃的应用程序也会在这段时间内触及它，它不应该导致这样的问题，对吧？我的意思是，在应用程序查询它之后，成员服务器不应该再次增加 7 天的缓存条目 TTL，对吧？否则每条记录都会永远留在缓存中……然后，是什么阻止成员域服务器偶尔前往 DC，如果发现记录不匹配，则清除缓存中的错误记录？
查看有关类似问题的帖子的时间（没有最近的帖子/问题），可能是某个 MS 补丁解决了该问题，或者在较新的 Windows Server 版本中解决了该问题（就我而言，我在 Windows Server 2008 SP1 Standard 上看到了这个问题，测试环境有 2008 SP1 Enterprise）。
我有一个想法，我可以使用 Procmon 来监视 LSA 缓存路径并识别哪个应用程序过于频繁地触碰缓存条目，但不清楚我的下一步应该做什么，因为我不明白到底需要什么条件才能将此记录永远保存在缓存中...盲目减少这种活动/更改应用程序设置似乎也不是一个很好的解决方案......
简而言之，我希望能够重现这种情况，即了解哪些情况会导致重命名用户的过时缓存条目“卡”在本地缓存中。如果有人能在这里提供一些信息，我将不胜感激。