Determine if user is in AD group for .NET 4.0 application

Question

I am trying to determine if a user is a member of an Active Directory (AD) group for an internal ASP.NET 4.0 application. The code below throws an "Attempted to access an unloaded appdomain" exception error on the last line (return statement) in the case when the user is not a member of the AD group.

public static bool IsInADGroup(string userName, string groupName)
{
    var principalContext = new PrincipalContext(ContextType.Domain);
    UserPrincipal userPrincipal = UserPrincipal.FindByIdentity(principalContext, userName);
    if (userPrincipal == null)
        return false;

    GroupPrincipal groupPrincipal = GroupPrincipal.FindByIdentity(principalContext, groupName);
    if (groupPrincipal == null)
        return false;

      return userPrincipal.IsMemberOf(groupPrincipal);
}

Any ideas on how to fix or other workarounds?

Hypophysis

Can you show stack trace when the exception is thrown? – Mignonmignonette

Does this happen consistently? Tried this piece of code in both a ASP.NET 4.0 and Windows Form applications and I did not see this error. This might happen if your application pool is recycled and hence you would lose your appdomain. – Urgency

As soon as I get to work on Monday I am going to try out what you provided. In the mean time though, do you have access to your AD Admin (Or Equivalent)? I ask because I'd be curious to know if there is something on the Admin side that has to be enabled or disabled to allow for you to program against it. Second question, how are you running your application? Are you just pressing the play button or are you hosting your app in IISx and accessing it via the web browser, then attach to process for debug (I recommend trying that)? – Bowlin

Here is another suggestion, I tried your code in a ASP.NET v4.0 Web App hosting it in Casini (pressing play button) and directly in IIS7. I have no trouble in Casini, but in IIS7 my User Principal is null. I ran into a problem like this a while ago and I remember trying a lot of crazy stuff to get it to work on my local and it just wouldn't. The end solution was to put your application on the destination server that will be hosting it and it will work. Give that a shot and see what happens. Lastly, just to state it, I did not get that exception you reported. I am not sure how to break it. – Bowlin

Answer 1

Could this bug be your problem?

I've solved the same problems using this workaround:

           using (DirectoryEntry rootDse = new DirectoryEntry("LDAP://rootdse"))
        {
            var dnsName = rootDse.Properties["dnsHostName"].Value.ToString();
            using (PrincipalContext ctx = new PrincipalContext(ContextType.Domain, dnsName)) {}

Eyeglass

Thanks for your insights! I implemented your workaround and everything now works great. – Hypophysis

Yep, that was it for me as well. However, my rootDse.Properties["dnsHostName"] is null. I found that rootDse.Properties["fSMORoleOwner"] contains a clue as to the host name of the LDAP server. In my case, it was: CN=****,CN=<host name>,CN=****,CN=****,CN=****,CN=****,DC=<domain>,DC=<TLD> I've substituted **** for private information, but you will find the host name, domain and TLD of the LDAP server here. – Longwise

Answer 2

Same issue here.

It appears to be a bug in ADSI that was resolved with a hotfix. Windows 7 SP1 and Windows Server 2008 R2 SP1 don't include the fix, so it will need to be manually deployed on your development machines and server environments.

http://support.microsoft.com/kb/2683913

Masorete