![IIS 6 - 集成身份验证 - 需要每天重启才能识别额外的域用户](https://linux22.com/image/532507/IIS%206%20-%20%E9%9B%86%E6%88%90%E8%BA%AB%E4%BB%BD%E9%AA%8C%E8%AF%81%20-%20%E9%9C%80%E8%A6%81%E6%AF%8F%E5%A4%A9%E9%87%8D%E5%90%AF%E6%89%8D%E8%83%BD%E8%AF%86%E5%88%AB%E9%A2%9D%E5%A4%96%E7%9A%84%E5%9F%9F%E7%94%A8%E6%88%B7.png)
我们的子网页(经典 ASP)设置了 Windows 身份验证并且没有匿名访问。
对于域本地组,目标目录的权限设置为读取/执行。该组由我们具有信任关系的另一个域的成员组成。我们将其称为 GroupA
还为我们域的 IT 组设置了权限,我是该组的成员(GroupIT)。
一切都很顺利,直到一夜之间发生了一些事情......
每天早上 GroupA 成员都无法访问该网站,因为他们被要求输入登录名/密码。在这里输入他们的凭证(带域限定符)不起作用。GroupIT 访问正常。
Web 服务器日志显示“401 5”错误。事件查看器安全日志显示用户已成功通过服务器身份验证。
IIS 未完成身份验证过程。看起来 GroupA 对目标文件夹的权限已被删除。当然,它们仍然可见。
重新启动 IIS 可以解决问题,直到第二天早上。
我花了很多时间试图查明原因,包括使用 MS Auth Diagnostics,当我使用 GroupA 用户的凭据探测登录时,它确认存在身份验证 (401) 问题。Web 服务器或我们的域上没有运行任何任务显然会导致这种情况。我不认为这是缓存凭据的情况,因为我已向 GroupA 添加了新用户,发现他们也无法访问该网站。
我将非常感激任何想法。
答案1
想法:
回收包含经过身份验证的页面的应用程序池是否可以解决问题?
包含该页面的应用程序可以隔离到其自己的应用程序池中吗?
如果任何一个方法可以修复该问题,您可能能够通过为该应用程序池设置计划回收(比如说)每天凌晨 5 点来解决它(而不是实际修复它)。
凌晨 5 点之后,第一个传入的请求将启动一个新的应用程序池和工作进程,如果这能解决问题,它将使问题对用户透明。
没有足够的关于应用程序或应用程序池(以及它正在使用的其他应用程序、ISAPI 过滤器等)的信息来提供更准确的信息。