views:

451

answers:

2

hi guys,

I have an ASP.NET 3.5 application using Windows Authentication and implementing our own RoleProvider.

Problem is we want to restrict access to a set of pages to a few thousand users and rathern than inputing all of those one by one we found out they belong to an AD group.

The answer is simple if the common group we are checking membership against the particular user is a direct member of it but the problem I'm having is that if the group is a member of another group and then subsequently member of another group then my code always returns false.

For example: Say we want to check whether User is a member of group E, but User is not a direct member of *E", she is a member of "A" which a member of "B" which indeed is a member of E, therefore User is a member of *E"

One of the solutions we have is very slow, although it gives the correct answer

using (var context = new PrincipalContext(ContextType.Domain))
  {
    using (var group = GroupPrincipal.FindByIdentity(context, IdentityType.Name, "DL-COOL-USERS"))
    {
      var users = group.GetMembers(true); // recursively enumerate

      return users.Any(a => a.Name == "userName");
    }
  }

The original solution and what I was trying to get to work, using .NET 3.5 System.DirectoryServices.AccountManagement and it does work when users are direct members of the group in question is as follows:

public bool IsUserInGroup(string userName, string groupName)
{
  var cxt = new PrincipalContext(ContextType.Domain, "DOMAIN");
  var user = UserPrincipal.FindByIdentity(cxt, IdentityType.SamAccountName, userName);

 if (user == null)
  {       
    return false;
  }


  var group = GroupPrincipal.FindByIdentity(cxt, groupName);

  if (group == null)
  {        
    return false;
  }

  return user.IsMemberOf(group);
}

The bottom line is, we need to check for membership even though the groups are nested in many levels down.

Thanks a lot!

+1  A: 

Solution 1: Use web.config to restrict access

Since you are using ASP.NET, a lot simpler solution to restrict access is by setting it up in web.config, example as follows:

<configuration>
  <location path="protected/url/path">
    <system.web>
      <authorization>
        <allow roles="DOMAIN\group"/>
        <deny users="*"/>
      </authorization>
    </system.web>
  </location>
</configuration>

For more info: http://msdn.microsoft.com/en-us/library/wce3kxhd.aspx and http://msdn.microsoft.com/en-us/library/b6x6shw7.aspx.

Solution 2: A faster implementation of IsUserInGroup

A code I used in a .NET 2.0 application, works well in a big forest comparable to yours.

static bool IsUserInGroup(DirectoryEntry user, string groupName)
{
    user.RefreshCache(new string[] {"tokenGroups"});
    for (int i = 0; i < user.Properties["tokenGroups"].Count; i++) {
        SecurityIdentifier sid = new SecurityIdentifier((byte[]) user.Properties["tokenGroups"][i], 0);
        try {
            NTuser nt = (NTuser) sid.Translate(typeof(NTuser));
            if (nt.Value.ToLower().EndsWith("\\" + groupName.ToLower())) {
                return true;
            }
        } catch (IdentityNotMappedException) {
            continue;
        }
    }

    return false;
}
Amry
Amry, thanks for your answers,however solution 1 didn't work since I'm implementing my own RoleProvider. I think you solution will work is we use WindowsTokenRoleProvider. Solution 2 I tried and it didn't work. However thanks for your time.
elsharpo
@elsharpo: Can you retry again using the Solution 2 I provided. I mistakenly copied the wrong code, the correct one should use nt.Value.ToLower().EndsWith() instead of nt.Value.ToLower().Equals() that I provided before.Also may I know what's your reason for implementing your own RoleProvider? Since it seems to me that you are checking against AD and the builtin provider should work just fine.
Amry
Hi Amry. Sorry for the delay in getting back to you, but it didn't work. However I'm happy to say that we found a solution by looking directly in AD and looking at the employee's job title and is very very fast.
elsharpo
Too bad it didn't work for you as it worked for me. Maybe something different in the AD infrastructure settings. Anyway, good that you found something that worked.
Amry
A: 

Well, I had to think outside the square with this one and fortunately by looking into AD we discovered that all the 3000+ people that had to see the pages share a keyword in a custom AD property. So all I had to do is load the object from AD and look this up. End result client is very happy! It seems like a bit of a dirty solution at the moment but as always this is working perfectly and we have to move on onto other things!

At the moment we are going on with this with a pilot program and any errors that we get we want them to bubble up and be notified so we can act on it.

public static bool IsEmployeeCoolEnoughToSeePages(string userName)
{
  if (string.IsNullOrEmpty(userName))
  {
    throw new ArgumentNullException("Current user's Username cannot be null");
  }

  using (var searcher = new DirectorySearcher(("LDAP://YOURDOMAIN.com")))
  {
    searcher.Filter = string.Format("(&(objectCategory=user)(samAccountName={0}))", ariseUserName);
    SearchResultCollection searchResultCollection = searcher.FindAll();

    if (searchResultCollection.Count == 1)
    {
      var values = searchResultCollection[0].Properties["title"];

      if (values.Count == 1)
      {
        return values[0].ToString().StartsWith("_COOLNES_");
      }
    }

    return false;
  }
}
elsharpo