4

An AD setup I'm using has users that are stored as members of (multiple) security groups.

I am using software that reads the memberof property of a user to work out access permissions.

In AD Explorer I can see the memberof property of the user shows the immediate security groups they belong to say 'Course - English'. It does not show the parents groups, nested up to say 'ALL Students'.

Is there a reason for this or a way of ensuring all nested groups are shown in the memberof property?

user454322
  • 7,300
  • 5
  • 41
  • 52
user30803
  • 845
  • 2
  • 11
  • 25

2 Answers2

5

If you're on .NET 3.5 and up, you should check out the System.DirectoryServices.AccountManagement (S.DS.AM) namespace. Read all about it here:

Basically, you can define a domain context and easily find users and/or groups in AD:

// set up domain context
PrincipalContext ctx = new PrincipalContext(ContextType.Domain);

// find a user
UserPrincipal user = UserPrincipal.FindByIdentity(ctx, "SomeUserName");

if(user != null)
{
   var groups = user.GetAuthorizationGroups();

   // enumerate over groups
   foreach(GroupPrincipal gp in groups)
   {
      // do something here....
   }
}

The new S.DS.AM makes it really easy to play around with users and groups in AD!

The .GetAuthorizationGroups() method is the only one around that I know of that will do recursive searches, e.g. find groups that a user is member of by virtue of another group. The pre-.NET 3.5 DirectoryServices stuff doesn't do this - you would have to totally roll your own if you need that.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
  • Thank you very much for this - this may be the route we need to go down - is the underlying performance likely to be still slow as pre 3.5 methods such as multiple searches or LDAP_MATCHING_RULE_IN_CHAIN do you know? – user30803 Aug 21 '12 at 16:18
  • 1
    this worked and performance was in under a second - thanks again – user30803 Aug 24 '12 at 09:28
5

The probable reason that the memberOf attribute does not contain all the nested group information is that the value is computed when the attribute is loaded, as noted in this link:

Be aware that this attribute lists the groups that contain the user in their member attribute—it does not contain the recursive list of nested predecessors. For example, if user O is a member of group C and group B and group B were nested in group A, the memberOf attribute of user O would list group C and group B, but not group A.

This attribute is not stored—it is a computed back-link attribute.

Hence, to support this, your DC would be forced to load all nested groups every time a LDAP query returned the memberOf attribute, which could be a lot of excess work.

Depending on the technology you are using, there are almost certainly better ways to check group membership than loading all groups and listing them all. For example, ADSI has a pre-built function to check if a user is a member of the group.

However, for a pure LDAP solution, you could use the LDAP_MATCHING_RULE_IN_CHAIN as shown in this answer (assuming you have the DN for the user), e.g.,

(member:1.2.840.113556.1.4.1941:=CN=Administrator,OU=Users,DC=fabrikam,DC=com)

Which will get all the groups which Administrator is a member of. Note, however, that this query can be extremely slow. To speed up performance, consider paging results or restricting the search base to only the group you are interested in checking.

Community
  • 1
  • 1
ig0774
  • 39,669
  • 3
  • 55
  • 57