..ActiveDirectory.ActiveDirectorySite.getComputerSite（）。name返回错误：ActiveDirectoryObjectNotFoundException

Question

感谢您的观看：希望这不仅可以帮助其他人，而且可以帮助我们！ （请保持温和，这是我在Stack上的第一个问题，尽管我已经是很长时间的用户/贡献者）

情况（SNAFU） AD站点感知应用程序正在从AD中提取一些信息。此应用程序只能连接到托管服务器的Active Directory站点中的控制器;如果没有找到该网站的控制器，我们有更大的问题，但代码将处理这种可能性。

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

1. 获取托管Web应用程序的服务器所在的站点名称。
2. 利用该站点名称信息在DirectoryServices中查询站点内的控制器列表
3. 通过控制器进行迭代，直到我们获得包含所需信息的有效响应。

所以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个控制器的列表;以及正确的网站名称;与注册表中的相同。

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

我们发现通过从ApplicationPoolIdentity切换到NetWorkServices，该站点再次起作用（这恰好是开发设置并解释了为什么dev工作但生产不会。但是，因为这不是默认的IIS 7.5配置了（ ApplicationPoolIdentity是）;我们倾向于尝试保持默认值，因为补丁有时会将设置恢复为默认值... 我们希望找到一个更加强大的长期答案，更接近MSFT方向。

问题：

• 是否有更好的方法来获取服务器内的活动/响应控制器的句柄＆＃39;站点并获取用户部门信息的访问权限？

• 需要向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服务器（或者我们需要授予访问包含DLL的特定文件夹的权限）正在使用的AD类？

更新 我们认为给出错误，问题可能在于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实用程序强制更改（完成）计算机密码
• 验证网站是否正常运营（ IT WAS !!!!!!!! ）
• 重启（完成）
• 验证网站是否正常运营（ IT WAS !!!!!!! ）

如果所有站点都可以运行，那么我们将假设此修补程序执行了所需的操作。目前，这似乎适用于在Service Pack 1上赢得2008年的机器。

因此对于遇到问题且想要转移到ApplicationPoolIdentity和NetworkServices的其他人...如果您在Service Pack 1上使用2008服务器....我建议你这样做：IIS application using application pool identity loses primary token?题。在这里给出答案......它帮助了我们！

经过30天自动循环的机器帐户密码后，补丁已被证明可以保留。标记问题已关闭。

Answer 1

根本原因：

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

临时工作：

1. 将应用程序工具设置为使用网络服务与身份。
2. 重新启动Web服务器，强制应用程序池标识更新在操作系统级别控制的计算机ID /密码，以便在AD控制器之间进行通信。

FIX：

1. 在Win 2008服务器上应用Microsoft Knowledge Base article KB2545850补丁。