仅在服务器上查询Active Directory时出错

Question

I have the following block of code that queries Active Directory for users by Group Name using System.DirectoryServices.AccountManagement :

var domainContext = new PrincipalContext(ContextType.Domain, "company.container.internal");
var groupPrincipal = GroupPrincipal.FindByIdentity(domainContext, IdentityType.Name, "Lvl1Users");
if (groupPrincipal != null)
{
  //Read the values
}

Now the site uses the following:

• IIS7 on Win2k8
• Windows Authentication
• Impersonation = True
• App Pool on .NET 4.0 using 'NETWORK SERVICE' as the account

On my local machine (you know how this goes) it all works great. My peers that try it locally also it works well. However once deployed to the server it shows the following:

An operations error occurred.

Everything I research says it's a permissions issue. 1 thing to note, on my local machine I'm on the MainNetwork domain which is the parent to company.container.internal domain which I am querying. The IIS machine is on company.container.internal and is querying the same domain. So honestly, I would think the more challenging situation is reading AD on my local machine which is on a different domain, but it works. On the server which is querying the same domain, it fails.

Here is what I've tried, and none of these has worked:

• Change AppPool to 'LocalSystem'
• Change AppPool to use a static super-duper Admin account
• Used Impersonation in code to manipulate the context of the calls in a local block with an admin user on the MainNetwork domain.
• Used Impersonation in code to manipulate the context of the calls in a local block with an admin user on the company.container.internal domain.
• Adding in using (HostingEnvironment.Impersonate())

What gives here? I have tried impersonating every type of power admin on both domains, and used multiple AppPool settings, and I keep getting the same error. Is there anything that needs to change in the code with the declaration of the domains, or is there a permissions issue I'm missing?

Answer 1

I figured this out and it turned out that using HostingEnvironment.Impersonate() was still at the root to solve the problem. I had already tried this, but there was another issue with my code.

The issue is often that the context for which the Active Directory calls is made is under a user that does not have permissions (also can happen when identity impersonate="true" in ASP.NET, due to the fact that the users token is a "secondary token" that cannot be used when authenticating against another server from: http://bit.ly/1753RjA ).

The following code will ensures that the block of code running, is run under the context of say the AppPool (ie NETWORKSERVICE ) that the ASP.NET site is running under.

using (HostingEnvironment.Impersonate())
{
   var domainContext = new PrincipalContext(ContextType.Domain, "myDomain.com");
   var groupPrincipal = GroupPrincipal.FindByIdentity(domainContext, IdentityType.Name, "PowerUsers");
   if (groupPrincipal != null)
   {
      //code to get the infomation
   }

}

However, one super important detail is that all the code calling Active Directory must be in that block. I had used some code a team member of mine wrote that was returning a LINQ query results of type Users (custom class), but not evaluating the expression (bad practice). Therefore the expression tree was returned instead of the results.

What ended up happening is the calling code eventually evaluated the results and the An operations error occurred message still appeared. I though the code fix above didn't work. When in fact it did, but there was code evaluating the results outside the block.

In a nutshell, make sure all code to access Active Directory is inside that using block and the exception should be fixed one the service/app is deployed to the server.