Hi all,
I want to retrieve a list of nested LDAP groups per user from the Active Directory. I have been searching google for half a day now, but I'm still not sure what approach to use. I have the following requirements:
* The script/program must run in different network environments (I can't be sure if there is a global catelog or AD DS or AD LDS, etc). I will write my own program.
* The membership info will be used in combination with directory ACL's and must be as complete as possible (global groups, universal groups, local groups, perhaps different domains). Distribution groups are not really necessary, because they are not used in
the directory ACL's.
* It would be nice to support other LDAP implementations than Active Directory using the same code, but that not a hard requirement. I could use another approach to support a different LDAP.
Now I have figured out five possible approaches (info comes from different sites, please correct me if I'm wrong):
1) tokengroups attribute:
- The attribute contains Univeral groups of the forest, global groups from the local domain, domain local groups from the local domain (assuming native mode) and local groups from the local machine.
- Returns a list of SIDs which will have to be translated to group names
- The tokenGroups attribute exists on both AD DS and AD LDS
- For AD DS, the tokenGroups attribute is not present if no GC server is available to evaluate the transitive reverse memberships.
- quote from site "Now that I have had a chance to test it though I can definitely say that tokenGroups WILL get the Universal groups from the other domains even if is NOT a GC. I just did it in my test lab."
- Token Groups cannot be retrieved if no Global Catalog is present to retrieve the transitive reverse memberships.
2) tokenGroupsGlobalAndUniversal
- A subset of the tokenGroups attribute. Only the global and universal group SIDs are included.
- If you want consistent results, read tokenGroupsGlobalAndUniversal that will return the same result no matter which DC you are connected to. However, it will not include local groups.
- other source says "tokenGroups will give you all the security groups this user belongs to, including nested groups and domain users, users, etc tokenGroupsGlobalAndUniversal will include everything from tokenGroups AND distribution groups". Not
sure if this is correct, I think it doesn't contain local groups.
- The tokenGroupsGlobalAndUniversal attribute exists on AD DS but not on AD LDS.
3) LDAP_MATCHING_RULE_IN_CHAIN / 1.2.840.113556.1.4.1941
- Use a recursive search query which returns all nested groups for user at once.
- Returns all groups except for the primary group
- It's a fast approach, see performance test from Richard Mueller:
http://social.technet.microsoft.com/Forums/fr-FR/f238d2b0-a1d7-48e8-8a60-542e7ccfa2e8/recursive-retrieval-of-all-ad-group-memberships-of-a-user?forum=ITCG
- It only works on Active Directory, not for other LDAP implementations
4) Recursive retrieval of the memberOf attribute
- Retrieves all groups except the primary group. (also local groups from other domains??)
- works for all LDAP implementations
- executes a lot of queries to the LDAP, especially if you want to scan all users/groups (perhaps limited on OU, but still)
5) Store memberOf attribute in local database and calculate the nested groups using recursive queries to the local database
- No heavy load to the LDAP
- Needs space to store the user/group info locally (embedded Derby database perhaps)
- Performs fast since the queries are executed locally
- Works for all LDAP implementations
My thoughts on these different approaches:
* appreach 1) I understand that the tokengroups attribute is not present if no GC server is available. In how many network environments is this the case? This option won't work because I want to support different network environments.
* approach 2) The tokenGroupsGlobalAndUniversal attribute exists on AD DS but not on AD LDS. Same here, in how many network environments is this the case? I don't think I can rely on this approach.
* approach 3) Seems to be a good option. How will it perform compared to approach 5 (local recursive queries)? Won't work for other LDAP implementations
* approach 4) I don't think I want to execute that many queries to the LDAP. I can limit the scan on OU, but still companies can have thousands of users and groups.
* approach 5) Perhaps the best approach. I want to store user/group info locally for fast filtering / reporting (only group DNs, user names, databse id's and membership info as id-id pairs). I only need the memberOf attribute of users and groups, recursive
loops are done locally. It will work for all LDAP implementations.
What do you guys think? I'm not a network admin, but a programmer, so I'm no expert in network setups and when to use AD DS or AD LDS. The thing is I want to use this code at different customers without knowing their network setup (except for the domain name(s),
LDAP host/port and bind user to connect to LDAP).
Thanks a lot!
Paul
