IIS 将旧用户名返回到我的应用程序

Question

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

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

有谁知道这是怎么回事？ 我可以使用某种命令来刷新给我带来这个问题的任何缓存吗？ 我的服务器配置错误吗？

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

---

AviD -

是的，他们的 UPN 及其登录名已更改。 Mark/Nick...这是一个生产企业服务器...它不能只是重新启动或重新启动 IIS。

---

后续行动（供后代使用）：

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

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

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

Answer 1

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

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

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

您可能需要研究以下系统调用，例如以下系统调用：

LookupAccountName()

LookupAccountSid()

LsaOpenPolicy()

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

Answer 2

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

它的缓存方式取决于您在 IIS 上进行身份验证的方式。 我怀疑这可能是 Kerberos，因此如果是由 Kerberos 引起的，则要进行清除，您可能需要尝试 klist 带有清除选项，该选项应清除 kerberos 票证，这将在下一次尝试时强制重新验证 AD 并更新详细信息。

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

Answer 3

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

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

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

Answer 4

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

需要考虑的其他因素：

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

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

Answer 5

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

Answer 6

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

Answer 7

使用相关的新登录名登录到运行 IIS 的服务器。 这将刷新凭据，而无需重新启动 IIS 或重新启动服务器。

Answer 8

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