..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

在我们的开发环境中,这很好用.在我们的生产环境中它不会.

我们验证了服务器在域中并通过检查此其他堆栈文章中提到的注册表项来定义站点

更多研究引导我们阅读描述类似问题的technet文章.我们使用上面提到的powershell脚本来查看我们的Web服务器会发生什么:

[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite()它返回了服务器和我们希望找到的8个控制器的列表; 以及正确的网站名称; 与注册表中的相同.

因此,这导致我们在默认应用程序池NetworkServices与ApplicationPoolIdentity之间存在权限差异.正如我们在此处所知,Web服务器可以看到网站和服务器......那么为什么无法使用Web应用程序呢？

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

问题:

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

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

其他相关文章

• 如何正确设置IIS 7应用程序池标识？
• 使用应用程序池标识的IIS应用程序丢失主令牌？
• 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应用程序中引用的KB 会丢失主令牌？实际上是问题所在.我们

• 已验证的网站正在运营(它是)
• 使用此修补程序中引用的Nltest.exe实用程序强制更改计算机密码
• 验证该网站已被破坏(它是)
• 重新启动
• 验证该网站再次运营(它是)

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

• 验证站点是否正常运行(是)
• 部署修补程序(完成)
• 重启(完成)
• 验证网站是否正常运行(它是)
• 使用此修补程序中引用的Nltest.exe实用程序强制更改(完成)计算机密码
• 验证网站是否正常运营(IT WAS !!!!!!!!)
• 重启(完成)
• 验证网站是否正常运营(IT WAS !!!!!!!)

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

因此,对于遇到问题并希望转移到ApplicationPoolIdentity和NetworkServices的其他人...如果您在Service Pack 1上使用2008服务器....我将引用您:使用应用程序池标识的IIS应用程序丢失主令牌？题.在这里给出答案......它帮助了我们!

事实证明,在30天自动循环机器帐户密码后,补丁程序仍然可以保留.标记问题已关闭.

Answer 1

根本原因：

在 Windows 2008 上，从 Web 引用 Active Directory 时，应用程序池身份中的 MSFT 错误在 30 天内以及此后每30 天发生一次。（假设默认设置）

临时解决方法：

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

使固定：

1. 在 Win 2008 服务器上应用Microsoft 知识库文章 KB2545850补丁。