Retrieve nested LDAP groups independent from the network env. (five different approaches)

Question

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

Answer 1

I want to write a tool that can answer questions like "what users from group ABC have delete permission in all the (sub)directories of server MyDataServer?". This results in a list of directories and users and includes nested group membership. So it's about
effective permissions. That's why I want all information in a SQL database so I can answer these questions with a single query in milliseconds. Otherwise, in order to answer these questions, I would have to get all members from group ABC and determine the
nested groups for all these members (which can be thousands) for every report. Using a SQL database I can retrieve this information once a night for all the members.
But I guess I will use the LDAP_MATCHING_RULE_IN_CHAIN syntax which gives me all nested groups for a member and should work for all AD installations from W2K3 SP2 and higher. When I want to support other LDAPs I will use another method for that specific
LDAP.
Again - note that this question has nothing to do with LDAP or AD.  It just asks what group has permissions on what resources.
I really think you would do well to spend time understanding the NTFS and its security along with how we sue security in Windows.  By assuming this has something to do with AD you are making it a bigger issue than needed.  AD is a repository for
accounts and trusts and manages authentication and security group membership.  All file security is managed by the OS that hosts the files and not by AD.  Users are not normally granted access to resources through direct inclusion in the DACL but
are given access through membership in one or more groups.  Loading AD into a SQLL database will not help you.
¯\_(ツ)_/¯