我们有许多本地安装的 .Net 应用程序通过 Web 服务进行通信。IIS 中的身份验证由 Windows 身份验证处理，因此无需额外登录。我们最近开始发现一个问题，当用户的密码重置在密码过期通知期内（目前为 7 天）时，用户会收到 IIS 403 禁止错误。
由于这种情况有时会发生在中午（早上登录没问题，但白天密码已过期不到 7 天），这令人感到意外，因为他们没有收到更改密码的警告。当然，我希望他们能够工作到密码过期。
知道这里可能发生了什么吗？如果密码实际上尚未过期，IIS 为何会拒绝登录？我们可以改变这种行为吗？
谢谢
格雷格
答案1
您可能会在 Web 日志中看到 403.18 错误。您是否将错误页面配置为从其他应用程序池运行？请查看此处： http://blogs.msdn.com/b/rakkimk/archive/2006/09/01/735684.aspx
这里（描述了一个非常相似的问题）： http://social.technet.microsoft.com/forums/en-US/exchangesvrgeneral/thread/0f96332b-5b53-42f6-8f12-7d0b79a0a636/
答案2
鉴于解决这个问题的难度，我想用最终结果来回答我的问题。
该问题与 IIS 和 PasswordChange 通知有关。在所有服务器上，我们都删除了 /IISpwdadm。这是 IIS 内置的功能，允许交互式用户更改密码。
显然，当我们的用户密码进入通知期时，Web 服务会尝试将他们重定向到 /iispwdadm/anot.asp。由于这不在 Web 服务的路径中，并且位于不同的应用程序池中，因此生成了 403 错误。
解决方案是使用 adsutil 将 changepasswordflags 设置更改为 6，从而禁用 IIS 的通知和密码更改功能。
cscript adsutil.vbs set w3svc/passwordchangeflags 6
cscript adsutil.vbs set w3svc/1/passwordchangeflags 6
另外需要注意的是，我们的 Web 服务位于 BigIP 后面的池中。由于源地址是池地址，因此所有这些重定向都被集中到池中的单个服务器。这使得在日志中查找 403 事件变得有点棘手。
再次感谢 DmitryK 引领我们走向正确的道路。