.net - ..ActiveDirectory.ActiveDirectorySite.getComputerSite().name 返回错误 : ActiveDirectoryObjectNotFoundException

Question

感谢观看:希望这不仅可以帮助其他人，而且现在可以帮助我们! (请保持温和，这是我在 Stack 上的第一个问题，尽管我一直是用户/贡献者)

情况 (SNAFU)
AD 站点感知应用程序正在从 AD 中提取一些信息。此应用程序只能连接到托管服务器的 Active Directory 站点内的 Controller ；如果没有找到该站点的 Controller ，我们就会遇到更大的问题，但代码会处理这种可能性。

为了实现这一目标，我们打算:

获取托管 Web 应用程序的服务器所在的站点名称。

利用该站点名称信息在 DirectoryServices 中查询站点内的 Controller 列表

迭代 Controller ，直到我们得到包含所需信息的有效响应。

所以 PSEDUO 代码:

System.DirectoryServices.ActiveDirectory.DirectoryServices.GetComputerSite().Name 

获取服务器所在站点的名称...然后循环遍历
System.DirectoryServices.ActiveDirectory.DirectoryServices.ActiveDirectorySite
直到我们找到与获取的名称匹配的站点。现在我们有了这个集合，我们可以从 servers 属性请求特定的服务器。最后与服务器，请求所需的 AD 信息。

问题:
第一步， GetComputerSite().Name返回错误:ActiveDirectoryObjectNotFoundException

在我们的开发环境中，这工作得很好。在我们的生产环境中不会。

我们通过检查 this other stack article 中提到的注册表项来验证服务器在域中并定义了一个站点。

更多的研究使我们找到了 technet article描述一个类似的问题。我们利用上面提到的 powershell 脚本来看看我们的 Web 服务器会发生什么:
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite()它返回服务器和我们期望找到的 8 个 Controller 的列表；以及正确的站点名称；和注册表一样。

因此，这导致我们发现默认应用程序池 NetworkServices 与 ApplicationPoolIdentity 之间的权限差异。正如我们此时所知道的，Web 服务器可以看到站点和服务器……那为什么 Web 应用程序不能呢？

我们发现通过从 ApplicationPoolIdentity 切换到 NetWorkServices，站点再次工作(这恰好是开发设置并解释了为什么开发工作但生产不会。然而，因为这不再是默认的 IIS 7.5 配置(ApplicationPoolIdentity 是)；和我们倾向于尝试保持默认值，因为补丁有时会将设置移回默认值......
我们想找到更接近 MSFT 方向的更稳健的长期答案。

问题:

是否有更好的方法来处理服务器站点内的主动/响应 Controller 并访问用户部门信息？

需要向 ApplicationPoolIdentity 添加哪些权限才能允许此应用程序访问 AD 服务？

其他相关文章

How to set up IIS 7 application pool identity correctly?

IIS application using application pool identity loses primary token?

https://serverfault.com/questions/81165/how-to-assign-permissions-to-applicationpoolidentity-account

不幸的是，到目前为止我们发现的所有内容都与设置查看文件夹/文件系统的权限有关，但没有使用 AD 服务器(或者我们是否需要授予对包含正在使用的 AD 类的 DLL 的特定文件夹的访问权限？

更新:
我们认为考虑到错误，问题可能在于 ApplicationPoolIdentity 无法访问 System.DirectoryServices.dll，因此我们明确授予权限

cacls.exe %windir%/assembly/System.DirectoryServices /e /t /c /p “OurAppPoolIdentityAcct”:R

它开始工作了!!!

我们简直不敢相信，所以我们取消了更改...并重新启动了 IIS....
它仍然有效......

所以看起来它神奇地固定了自己。我们甚至通过从 NetworkServices 切换回 ApplicationPoolIdenity 来尝试在生产中，一切都重新开始工作......我们不知所措，但没有进一步的字符串可以进行调查。我们将暂时监控并希望问题不会再次出现...不是最好的方法，但由于我们无法像之前那样重现问题，我们不知道还能尝试什么。

最后一次更新
我们发现 IIS application using application pool identity loses primary token?中引用的KB实际上是问题所在。我们

经验证的站点可以运行(它是)

使用修补程序中引用的 Nltest.exe 实用程序强制更改机器密码

验证该站点已损坏(它是)

重启

验证该站点再次运行(它是)

我们接下来的步骤是执行类似的步骤以确认修补程序确实解决了问题。我们会:
.

验证站点是否正常运行(是)

部署修补程序(完成)

重启(完成)

验证站点是否正常运行(曾经)

使用修补程序中引用的 Nltest.exe 实用程序强制更改机器密码(完成)

验证站点是否正常运行 ( 它是!!!!!!!!! )

重启(完成)

验证站点是否正常运行 ( 原来是!!!!!! )

如果所有站点都可以运行，那么我们将假定修补程序已完成其需要的工作。目前，这似乎适用于使用 Service Pack 1 的 win 2008 计算机。

因此，对于遇到问题并希望迁移到 ApplicationPoolIdentity 与 NetworkServices 的其他人...如果您使用的是 Service Pack 1 上的 2008 服务器...我建议您引用: IIS application using application pool identity loses primary token?题。相信这里的答案......它帮助了我们!

事实证明，即使在机器帐户密码自动循环 30 天后，补丁仍然有效。标记问题已关闭。

Answer 1

根本原因:

从 Web 引用 Active Directory 时，应用程序池标识中的 MSFT 错误发生在 30 天内，并且每 30 days 发生一次在 Windows 2008 之后。(假设默认设置)

临时解决方法:

设置应用程序工具以使用网络服务与身份。

重新启动 Web 服务器，强制应用程序池标识更新在操作系统级别控制的机器 ID/密码，以便在 AD Controller 之间进行通信。

修复:

申请 Microsoft Knowledge Base article KB2545850 Win 2008 服务器上的补丁。