![如果在 msDS-ManagedPasswordInterval 中的天数之后首次使用,则 IIS 应用池将不会以 gMSA 身份启动](https://linux22.com/image/709608/%E5%A6%82%E6%9E%9C%E5%9C%A8%20msDS-ManagedPasswordInterval%20%E4%B8%AD%E7%9A%84%E5%A4%A9%E6%95%B0%E4%B9%8B%E5%90%8E%E9%A6%96%E6%AC%A1%E4%BD%BF%E7%94%A8%EF%BC%8C%E5%88%99%20IIS%20%E5%BA%94%E7%94%A8%E6%B1%A0%E5%B0%86%E4%B8%8D%E4%BC%9A%E4%BB%A5%20gMSA%20%E8%BA%AB%E4%BB%BD%E5%90%AF%E5%8A%A8.png)
直到最近,我们一直在环境中使用组托管服务帐户 (gMSA),没有出现任何问题。我们将几个应用程序部署到生产环境中,其中 gMSA 大约在 60 天前创建,但尚未使用。在 gMSA 的属性中,msDS-ManagedPasswordInterval 的默认值为 30 天。
当 install-adserviceaccount 作为部署脚本的一部分运行时,pwdLastSet、msDS-ManagedPasswordId 和 msDS-ManagedPasswordPreviousId 属性已更新,但应用程序池仍然无法启动,并且我们看到每次尝试启动时 badPasswordTime 都会更新。通过再次运行 install-adserviceaccount 解决了此问题,这可能从 AD 中检索了正确的密码。我们在多个帐户中观察到了这种行为,这些帐户首次使用的天数超过 30 天。我们没有看到帐户在创建后 30 天内使用(超过 150 个帐户)时出现此问题。
另一个变量是我们正在部署到负载平衡环境,因此 gMSA 可以同时安装在多台服务器上。并非所有服务器都存在同一 gMSA 的问题。
除了运行脚本之外,我们无法通过手动测试重现此问题,因此我想知道在更改完全同步之前,更改的密码和从 Active Directory 检索的密码之间是否存在竞争条件。有什么方法可以检查是否存在这种情况?
还有其他人遇到过这种行为吗?
目标服务器和域控制器(5)均运行 Windows Server 2012 R2 并已完全修补。域功能级别也是 Windows Server 2012 R2。