感谢您的收看：希望这不仅对以后有所帮助，而且现在对我们有所帮助！ （并且请保持温柔，这是我的第一个堆栈问题，尽管我一直是长期的用户/贡献者）
情况（SNAFU）
一个AD网站感知应用程序正在从AD中提取一些信息。该应用程序只能连接到托管服务器的Active Directory站点内的控制器；如果找不到该站点的控制器，那么我们将遇到更大的问题，但是代码可以解决这一问题。
为此，我们打算：
获取托管Web应用程序的服务器所在的站点名称。
利用该站点名称信息查询DirectoryServices以获得站点内控制器的列表
遍历控制器，直到我们获得所需信息的有效响应。
因此，PSEDUO代码为：
System.DirectoryServices.ActiveDirectory.DirectoryServices.GetComputerSite().Name
获取服务器所在站点的名称...然后循环浏览
System.DirectoryServices.ActiveDirectory.DirectoryServices.ActiveDirectorySite直到找到与所获取名称匹配的网站。现在我们有了该集合，我们可以从服务器属性中请求特定的服务器。最后与服务器一起，请求所需的AD信息。
问题：
第一步
GetComputerSite().Name返回错误：ActiveDirectoryObjectNotFoundException在我们的开发环境中，这很好。在我们的生产环境中不会。
我们通过检查this other stack article中提到的注册表项来验证服务器是否在域中并具有定义的站点
更多的研究使我们得出了technet article描述类似问题的信息。我们利用提到的powershell脚本来查看Web服务器会发生什么：
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite()它返回了服务器以及我们希望找到的8个控制器的列表；以及正确的网站名称；与注册表中相同。因此，这导致我们在默认应用程序池NetworkServices与ApplicationPoolIdentity之间存在权限差异。正如我们现在所知道的，Web服务器可以看到站点和服务器...那么为什么Web应用程序不能？
我们发现，通过从ApplicationPoolIdentity切换到NetWorkServices，站点再次可以工作（这恰好是开发设置，并解释了为什么开发成功了，但生产却无法正常工作。但是，由于这不再是默认的IIS 7.5配置（ApplicationPoolIdentity是），并且我们倾向于尝试保留默认设置，因为补丁有时会将设置移回默认设置...
我们希望找到一个更稳健的长期答案，使其更接近MSFT方向。
问题：
是否有更好的方法来处理服务器站点内的活动/响应控制器并获得对用户部门信息的访问权？
需要向ApplicationPoolIdentity添加哪些权限才能允许该应用程序访问AD Services？
其他相关文章
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天之后，该补丁仍可以保留。标记问题已关闭。
最佳答案
根本原因：
Windows 30天内（在默认设置下）在30天之内从Web引用Active Directory以及此后的每个30 days时，应用程序池标识中的MSFT错误。
临时变通方案：
将应用程序工具设置为使用网络服务与身份。
重新启动Web服务器，强制应用程序池标识更新在OS级别控制的计算机ID /密码，以在AD控制器之间进行通信。
固定：
在Win 2008服务器上应用Microsoft Knowledge Base article KB2545850修补程序。