..ActiveDirectory.ActiveDirectorySite.getComputerS

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)

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:

Get the site name in which the server hosting the web application resides.
Utilize that site name information to query DirectoryServices for a list of controllers within the site
Iterate though the controllers until we get a valid response with the needed information.

So the PSEDUO code:

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

to get the name of the site the server resides within... and then loop through

System.DirectoryServices.ActiveDirectory.DirectoryServices.ActiveDirectorySite

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.

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.

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

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() it returned servers and the list of 8 controllers we expected to find; along with the proper site name; same as in the registry.

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?

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.

The Question(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?
What permissions would need to be added to ApplicationPoolIdentity to allow this application access to AD Services?

Additional Relevant articles

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

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?

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

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

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.

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

Verified site was operational (it was)
Used the Nltest.exe utility referenced in the hotfix to force the machine password to change
Verified the site was broke (it was)
Rebooted
Verified the site was again operational (it was)

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

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!!!!!!!)

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.

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!

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

Root Cause:

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)

Temporary Work around(s):

Set Application tool to use Network Services vs Identity.
Reboot webserver forcing Application Pool Identity to update machine id/passwords controlled at OS level for communications between between AD controllers.

FIX: