views:

272

answers:

1

I'm attempting to determine whether a user is a member of a given group using System.DirectoryServices.AccountManagment.

  • I'm doing this inside a SharePoint WebPart in SharePoint 2007 on a 64-bit system.
  • Project targets .NET 3.5
  • Impersonation is enabled in the web.config.
  • The IIS Site in question is using an IIS App Pool with a domain user configured as the identity.

I am able to instantiate a PrincipalContext as such:

PrincipalContext pc = new PrincipalContext(ContextType.Domain)

Next, I try to grab a principal:

using (PrincipalContext pc = new PrincipalContext(ContextType.Domain))
{
   GroupPrincipal group = GroupPrincipal.FindByIdentity(pc, "MYDOMAIN\somegroup");
   // snip: exception thrown by line above.
}

Both the above and UserPrincipal.FindByIdentity with a user SAM throw a DirectoryServicesCOMException: "Logon failure: Unknown user name or bad password"

I've tried passing in a complete SAMAccountName to either FindByIdentity (in the form of MYDOMAIN\username) or just the username with no change in behavior. I've tried executing the code with other credentials using both the HostingEnvironment.Impersonate and SPSecurity.RunWithElevatedPrivileges approaches and also experience the same result.

I've also tried instantiating my context with the domain name in place:

Principal Context pc = new PrincipalContext(ContextType.Domain, "MYDOMAIN");

This throws a PrincipalServerDownException: "The server could not be contacted."

I'm working on a reasonably hardened server. I did not lock the system down so I am unsure exactly what has been done to it. If there are credentials I need to allocate to my pool identity's user or in the domain security policy in order for these to work, I can configure the domain accordingly. Are there any settings that would be preventing my code from running? Am I missing something in the code itself? Is this just not possible in a SharePoint web?

EDIT: Given further testing, my code functions correctly when tested in a Console application targeting .NET 4.0. I targeted a different framework because I didn't have AccountManagement available to me in the console app when targeting .NET 3.5 for some reason.

using (PrincipalContext pc = new PrincipalContext(ContextType.Domain))
using (UserPrincipal adUser = UserPrincipal.FindByIdentity(pc, "MYDOMAIN\joe.user"))
using (GroupPrincipal adGroup = GroupPrincipal.FindByIdentity(pc, "MYDOMAIN\user group"))
{
   if (adUser.IsMemberOf(adGroup))
   {
       Console.WriteLine("User is a member!");
   }
   else
   {
       Console.WriteLine("User is NOT a member.");
   }
}

What varies in my SharePoint environment that might prohibit this function from executing?

A: 

I added the account used by the IIS Application Pool to the Administrators group and this issue was resolved.

antik
You should probably make a note that this is the "Iron Fist of Justice" approach, and not a recommended solution for a production or internet facing system.
Burly
@Burly - Good point. This works in my environments: an internal system on a disconnected network. It's not a solution I'm happy with but it is a solution so it will have do for now. I'm really hoping for some guidance one what privileges the Admins have that enable the code to execute without error. I'd love to remove the admin privilege from that user and grant something safer while continuing operation as I require.
antik