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

Asp.net IIS将旧用户名返回到我的应用程序,asp.net,security,iis,authentication,kerberos,Asp.net,Security,Iis,Authentication,Kerberos,这是我的设想。我创建了一个应用程序,它使用集成的Windows身份验证来工作。在Application\u AuthenticateRequest()中,我使用HttpContext.Current.User.Identity获取我网站用户的当前WindowsPrincipal 现在是有趣的部分。我们的一些用户最近结婚了,他们的名字也变了。(即,用户的NT登录名从jsmith更改为jjones),当我的应用程序对其进行身份验证时,IIS将其旧登录名传递给我。我继续看到jsmith传递到我的应用程

这是我的设想。我创建了一个应用程序,它使用集成的Windows身份验证来工作。在
Application\u AuthenticateRequest()
中,我使用
HttpContext.Current.User.Identity
获取我网站用户的当前
WindowsPrincipal

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

有人知道这里发生了什么吗?有没有什么命令可以用来刷新缓存中出现的问题?我的服务器是否配置错误

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


渴望-

是的,他们的UPN随登录名一起更改。还有马克/尼克。。。这是一个生产企业服务器。。。它不能只是重新启动或让IIS重新启动


后续(为子孙后代):

格姆的回答恰到好处。这个问题在低容量服务器中会突然出现,在这些服务器中,您的应用程序没有很多人使用,但会发出足够的请求以将用户的身份保留在缓存中。其中的关键部分似乎描述了缓存项在默认值10分钟后不刷新的原因:

缓存条目确实超时,但这种情况可能会重复出现 应用程序的查询将使现有缓存项保持活动状态 缓存项的最大生存期


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

重新启动IIS,而不是整个机器,应该起作用。

当这些用户的名称被更改时,您是只更改了他们的NT登录名,还是也更改了他们的UPN名称?UPN名称是专有名称,由Kerberos使用,Kerberos是IWA的默认协议;但是,如果您只是在ActiveDirectory中单击以更改其名称,则只有NT登录名会更改,即使这是他们登录时使用的名称(使用默认的windows GINA)。在封面下,windows将把(新的)NT登录名转换为(旧的)Kerberos名称。这种情况持续存在,直到AD被迫根据NT登录名更新Kerberos名称…

如果不是仅更改NT用户名的问题,则验证服务似乎正在缓存旧用户名。
您可以将其定义为禁用,转到本地安全设置(在管理工具中),根据版本/版本/配置,可能相关的设置(从内存中)包括“要缓存的以前登录次数”和“不允许存储凭据…”

需要考虑的其他因素:

  • 域成员资格可能会影响这一点,因为成员服务器可能会继承域设置
  • 您可能仍然需要重新启动整个服务器一次,以使其生效(但这样您就不必担心将来的更新)
  • 登录性能可能会受到影响
因此,我建议您在将其部署到生产环境之前(当然)先进行测试。

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

缓存的方式取决于您在IIS上的身份验证方式。我怀疑可能是Kerberos造成的,因此要进行清除,如果是由Kerberos引起的,您可能希望尝试使用清除选项,该选项将清除Kerberos票据,这将在下次尝试时强制重新授权AD并更新详细信息


我还建议您考虑实现一个稍微复杂但不容易出错的方法。

我知道过去IIS中也存在缓存凭据问题,在谷歌搜索了几天之后,我们发现了一个模糊的(至少对我们来说)命令,您可以用它查看和清除缓存凭据

开始->运行(或WinKey+R)并键入控制键管理器.dll


这解决了客户端机器的问题。还没有在服务器上尝试过,但如果它是服务器缓存凭据,那么可能值得一试。我们的问题是我们得到了旧的凭证,但只是在客户端机器的基础上。如果用户登录到单独的客户端计算机上,一切正常,但是如果他们在办公桌上使用自己的计算机,他们通常使用的计算机具有缓存的旧凭据。

使用有问题的新登录名登录到运行IIS的服务器。这将刷新凭据,而无需重新启动IIS或重新启动服务器。

仅供参考,我们遇到了完全相同的问题。似乎对我们有效的方法是进入Active Directory并进行“刷新”。紧接着,我们不得不在出现此问题的intranet站点上回收应用程序池。

我最近也遇到类似问题,正如Robert MacLean的,
LookupAccountName()

LookupAccountSid()

LsaOpenPolicy()