感谢您观看：希望这不仅能帮助别人后，但可以帮助我们吧！ （和请温柔，这是我对堆栈的第一个问题，虽然我已经很长一段时间的用户/贡献者）

Thanks for viewing: Hopefully this not only helps others later, but helps us now! (and please be gentle, this my first Question on Stack though I've been a long time user/contributor)

情况（SNAFU） 广告站点感知应用程序是拉动一些信息出来的AD。此应用程序只能连接到Active Directory站点的服务器托管在控制器;如果发现该网站没有任何控制器，我们有更大的问题，但code将处理这种可能性。

Situation (SNAFU) An AD Site aware application is pulling some information out of AD. This application must only connect to controllers within the Active Directory site the server is hosted; if no controllers are found for that site, we have bigger issues but code will handle that possibility.

要做到这一点，我们打算：

To accomplish this we intend to:

获取其中承载Web应用程序的服务器所在的站点名称。 在利用该站点名称信息的网站中查询的DirectoryServices为控制器的列表 迭代尽管控制器，直到我们得到的信息需要一个有效的响应。

所以PSEDUO code：

So the PSEDUO code:

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

通过

System.DirectoryServices.ActiveDirectory.DirectoryServices.ActiveDirectorySite

，直到我们找到一个网站获得相匹配的名称。现在我们有一个集合，我们可以从服务器的财产请求特定的服务器。最后用服务器，请求所需要的AD信息

until we find a site matching the name acquired. Now that we have that collection, we can request specific server from the servers property. finally with the server, request the needed AD information.

问题： 的第一步， GetComputerSite（）名称返回一个错误：ActiveDirectoryObjectNotFoundException

THE PROBLEM: The very first step, GetComputerSite().Name returns an error: ActiveDirectoryObjectNotFoundException

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

In our development environment, this worked fine. In our production environment it wouldn't.

我们验证了服务器是在域中，不得不通过检查this其他堆栈文章

We verified the server was in the domain and had a site defined by checking the registry keys mentioned in this other stack article

更多的研究带领我们到一个 描述类似的问题TechNet文章。我们利用提到看会发生什么，从我们的Web服务器是什么PowerShell脚本：

More research lead us to a technet article describing a similar issue. We utilized the powershell script mentioned to see what would happen from our web server:

[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite] :: GetComputerSite（），它返回服务器和8个控制器的列表中，我们希望能够找到;伴随着适当的站点名称;一样在注册表中。

[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite() it returned servers and the list of 8 controllers we expected to find; along with the proper site name; same as in the registry.

因此​​，这使我们的默认应用程序池网络服务VS ApplicationPoolIdentity之间权限的差异。正如我们知道，在这一点上的Web服务器可以看到网站和服务器...那么，为什么不能在Web应用程序？

So this led us to permissions differences between the default application pool NetworkServices vs ApplicationPoolIdentity. As we knew at this point the web server could see the site and servers... so why couldn't the web application?

我们发现，从切换到ApplicationPoolIdentity网络服务网站再次工作（这正好是开发设置，并解释为什么开发工作，但产量不会。但是，因为这不是默认的IIS 7.5配置了（ApplicationPoolIdentity是）;我们有一种倾向，试图留在默认的补丁有时回迁设置恢复到默认值... 我们希望找到一个更强大的长期答案对准接近MSFT方向。

We found that by switching from ApplicationPoolIdentity to NetWorkServices the site again works (this happened to be the development setup and explained why dev worked but production would not. However, as this isn't the default IIS 7.5 configuration anymore (ApplicationPoolIdentity is); and we have a tendency to try and stay with defaults as patches sometimes move back settings back to defaults... we wanted to find a more robust long term answer aligning closer to MSFT direction.

的问题（S）：

有没有更好的方法来获得一个句柄的主动/响应控制器的服务器的站点中，并获得了用户的部门信息？

Is there a better method to get a handle to an active/responsive controller within the servers' site and gain access to the user department information?

权限需要什么被添加到ApplicationPoolIdentity允许该应用访问AD服务？

What permissions would need to be added to ApplicationPoolIdentity to allow this application access to AD Services?

其他相关文章

How正确设置IIS 7应用程序池的身份呢？ IIS应用程序使用的应用程序池标识失去了主令牌？ http://serverfault.com/questions/81165/how-to-assign-permissions-to-applicationpoolidentity-account How to set up IIS 7 application pool identity correctly? IIS application using application pool identity loses primary token? http://serverfault.com/questions/81165/how-to-assign-permissions-to-applicationpoolidentity-account

不幸的是所有我们已经发现迄今联系，建立权限查看文件夹/文件系统，而不是利用AD serveries（或者是我们需要授予访问包含该DLL的为AD类是一个特定的文件夹使用？

Unfortunately all we have found thus far ties to setting up permissions to see folders/file systems, but not utilize the AD serveries (or is it that we need to grant access to a specific folder containing the DLL's for the AD classes being used?

更新： 我们认为，鉴于该问题可能归属于ApplicationPoolIdentity没有进入System.DirectoryServices.dll程序错误，所以我们明确授予的权限

Update: We thought given the error the problem may reside with ApplicationPoolIdentity not having access to the System.DirectoryServices.dll so we explicitly granted permissions

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

它开始工作！

It started working!!!

我们简直无法相信，所以我们解开了变化......并重新启动IIS .... 它仍然工作......

We couldn't believe it so we undid the change... and restarted IIS.... and it still worked....

所以看起来它神奇的固定本身。我们甚至试图在生产中只需切换回从网络服务到ApplicationPoolIdenity，一切​​都开始工作了......我们正处于一个损失，但没有进一步的字符串拖船进行调查。我们将监视暂时并希望这个问题不回来......不是最好的方法，但是，我们不能重现问题，我们可以更早些，我们不知道还有什么尝试。

So it appears it magically fixed itself. we even tried in production just by switching back from NetworkServices to ApplicationPoolIdenity and everything started working again... We're at a loss but have no further strings to tug for investigation. We'll monitor for the time being and hope the problem doesn't come back... Not the best approach but as we can't recreate the problem as we could earlier, we don't know what else to try.

的下一步将持续更新的 我们发现，KB的IIS应用程序使用的应用程序池标识失去了主令牌？的是，其实这个问题。我们

Next to last Update We found that the KB referenced in IIS application using application pool identity loses primary token? was in-fact the problem. We

验证的网站是在业务（这是） 使用该修复程序，迫使机密码引用的Nltest.exe实用程序更改 验证网站被爆出（这是） 重新启动 验证该网站再次被操作（这是）

我们的下一步是做同样的步骤，以确认此修补程序中，其实解决这个问题。我们会：  。

Our next steps are to do similar steps to confirm the hotfix does in-fact correct the problem. We will: .

验证网站的业务（是） 在部署修补程序（完成） 重新启动（完成） 验证网站的正常运行（这是） 使用该修复程序中引用的Nltest.exe实用工具来强制设备密码更改（做） 验证网站运营（这是!!!!!!!! ） 重新启动（完成） 验证网站运营（这是!!!!!!! ） Verify site is operational (Yes) Deploy hotfix (Done) Reboot (Done) Verify site is operational (it was) Use the Nltest.exe utility referenced in the hotfix to force the machine password to change (done) Verify site is operational (IT WAS!!!!!!!!) Reboot (Done) Verify site is operational (IT WAS!!!!!!!)

如果所有网站都运作那么我们将presume修补程序做了什么，它需要。在这个时候，这似乎适用于赢得2008年机上的Service Pack 1。

If all sites are operational then we will presume the hotfix did what it needed to. At this time this appears to apply to win 2008 machines on Service Pack 1.

因此​​，对于其他人谁遇到的问题，并希望移动到ApplicationPoolIdentity VS网络服务。如果您使用的是2008年的服务器上的Service Pack 1 ....请您看看这个：IIS应用程序使用的应用程序池标识失去了主令牌？的问题。给予信贷答案在这里... ...它帮助我们！

So for others who experience an issue and want to move to ApplicationPoolIdentity vs NetworkServices... If you're using a 2008 server on Service Pack 1.... I refer you to this: IIS application using application pool identity loses primary token? question. Give credit to the answer here... It helped us!

补丁已被证明持有计算机帐户的密码，即使经过30天自动循环。标记问题关闭。

Patch has proven to hold even after after 30 day automatic cycle of machine account passwords. Marking issue closed.

推荐答案

根本原因：

在应用程序池标识MSFT错误从网站引用Active Directory时30天之内，每一个的30天后出现在Windows 2008（假设默认设置）

MSFT Bug in Application Pool Identity when referencing Active Directory from web occurring within 30 days and every 30 days there after on Windows 2008. (assuming default settings)

的临时解决方法（S）：

设置应用程序的工具来使用网络服务VS身份。 重新启动Web服务器迫使应用程序池标识更新在操作系统级别AD控制器之间控制通信的计算机ID /密码。

FIX：

在应用 Microsoft知识库文章KB2545850补丁在Win 2008服务器。 Apply Microsoft Knowledge Base article KB2545850 patch on Win 2008 servers.