32

这是我的场景。我创建了一个使用集成 Windows 身份验证的应用程序才能工作。在Application_AuthenticateRequest()中，我HttpContext.Current.User.Identity用来获取WindowsPrincipal我网站用户的当前信息。

现在这是有趣的部分。我们的一些用户最近结婚了，他们的名字发生了变化。（即用户的 NT 登录从 更改jsmith为jjones），当我的应用程序对其进行身份验证时，IIS 将他们的 OLD LOGIN 传递给我。我继续看到jsmith传递给我的应用程序，直到我重新启动我的服务器！注销客户端不起作用。重新启动应用程序池不起作用。只有完全重启。

有谁知道这里发生了什么？是否有某种命令我可以用来刷新任何给我这个问题的缓存？我的服务器配置错误吗？

注意：我绝对不想重新启动 IIS、我的应用程序池或机器。由于这是一个生产盒，这些都不是真正可行的选择。

狂热 -

是的，他们的 UPN 连同他们的登录名一起改变了。还有马克/尼克……这是一个生产企业服务器……它不能只是重新启动或重新启动 IIS。

跟进（为后代）：

Grhm 的回答很到位。这个问题出现在低容量服务器中，您没有很多人使用您的应用程序，但会发出足够多的请求以将用户的身份保存在缓存中。KB中似乎描述了为什么默认 10 分钟后不刷新缓存项的关键部分是：

缓存条目确实会超时，但是应用程序的重复查询可能会在缓存条目的最大生命周期内保持现有缓存条目处于活动状态。

我不确定我们的代码中是什么导致了这种情况（重复查询），但对我们有用的解决方案是将LsaLookupCacheExpireTime值从看似淫秽的默认值 1 周减少到仅几个小时。对我们来说，这将用户在现实世界中受到影响的可能性降低到基本上为零，但同时不会导致对我们的目录服务器进行极端数量的 SID-Name 查找。如果应用程序通过 SID 查找用户信息，而不是将用户数据映射到文本登录名，则 IMO 更好的解决方案是。（注意，供应商！如果您在应用程序中依赖 AD 身份验证，则需要将 SID 放入身份验证数据库中！）

4

8 回答 8

25

我最近遇到了类似的问题，正如 Robert MacLean 的回答中所述，如果您没有以用户身份登录，AviD 的组策略更改将不起作用。

我发现按照 MS KB946358的描述更改LSA 查找缓存大小无需重新启动或回收任何应用程序池或服务即可工作。

我发现这是对类似问题的答案：更改用户登录名后的错误身份验证。

您可能需要查看以下系统调用，例如以下系统调用：

LookupAccountName()

LookupAccountSid()

LsaOpenPolicy()

您可以使用它们编写 C++/CLI (/Managed-C++) 应用程序来询问 LSA 缓存。

于 2011-10-07T09:49:53.523 回答
4

AviD发现的问题是您可以通过注册表控制的 Active Directory 缓存。根据您的解决方案，Avid 的组策略选项将失败或起作用，具体取决于您是否实际登录用户。

它的缓存方式取决于您在 IIS 上进行身份验证的方式。我怀疑它可能是 Kerberos，所以如果它是由 Kerberos 引起的，你可能想尝试使用清除 kerberos 票证的清除选项的klist，这将在下一次尝试时强制对 AD 重新授权并更新详细信息。

我还建议考虑实现这一点，它稍微复杂一些，但更不容易出错。

于 2009-02-24T11:01:04.257 回答
4

我知道我们过去在 IIS 中也遇到过缓存凭据问题，在谷歌搜索几天后，我们遇到了一个晦涩的（至少对我们而言）命令，您可以使用它来查看和清除缓存的凭据。

开始 -> 运行（或 WinKey+R）并输入control keymgr.dll

这解决了我们在客户端机器上的问题。尚未在服务器上尝试过，但如果它的服务器缓存凭据可能值得一试。我们的问题是我们获得了旧凭据，但仅在客户端计算机上。如果用户在单独的客户端计算机上登录，一切都很好，但如果他们在办公桌上使用自己的计算机，他们通常在该计算机上工作，则缓存旧凭据。

于 2009-02-27T19:09:35.353 回答
3

如果仅更改 NT 用户名不是问题，那么似乎身份验证服务正在缓存旧用户名。
您可以将其定义为禁用，转到本地安全设置（在管理工具中），根据版本/版本/配置，可能相关的设置（来自内存）是“要缓存的先前登录次数”和“执行不允许存储凭据..."。

需要考虑的其他因素：

  • 域成员身份可能会影响这一点，因为成员服务器可能会继承域设置
  • 您可能仍需要重新启动整个服务器一次才能使其生效（但您以后不必担心更新）。
  • 登录性能可能会受到影响。

因此，我建议您在部署到生产环境之前先进行测试（当然）。

于 2009-02-23T13:13:14.790 回答
1

重新启动 IIS，而不是整个机器，应该可以解决问题。

于 2008-10-03T21:38:47.957 回答
1

更改这些用户的名称时，您是只更改了他们的 NT 登录名，还是也更改了他们的 UPN 名称？UPN 名称是专有名称，由 Kerberos 使用 - 这是 IWA 的默认协议；但是，如果您只是在 ActiveDirectory 中单击更改他们的名称，则只有 NT 登录名称会更改 - 即使那是他们用来登录的名称（使用默认的 windows GINA）。在幕后，Windows 会将（新的）NT 登录名转换为（旧的）Kerberos 名。这种情况一直存在，直到 AD 被迫根据 NT 登录名更新 Kerberos 名称...

于 2008-10-05T01:08:50.730 回答
0

使用相关的新登录名登录到运行 IIS 的服务器。这将在不重新启动 IIS 或重新启动服务器的情况下刷新凭据。

于 2009-03-20T18:05:43.113 回答
0

仅供参考，我们遇到了完全相同的问题。似乎对我们有用的是进入 Active Directory 并进行“刷新”。在此之后，我们必须立即回收存在此问题的 Intranet 站点上的应用程序池。

于 2011-06-02T12:36:58.457 回答