5

I don't know much about LDAP so I apologise in advance.

I am looking at a bug in an application that does some authentication using LDAP.

The LDAP directory structure set up by the client contains nested groups and looks like the following:

UAT Group
    DEV Group
         portfolio_mangers

Under the DEV Group we have some users:

DEV Group
     jsmith
     cwilson
     plo

The user requires that authentication will recursively traverse the input group to determine if the user is directly or indirectly (nested) a member of the input group.

So if we start our traversal at either the UAT Group or the DEV Group, users jsmith, cwilson and plo would be authenticated.

This is possible, correct? From my reading I believe I have to specify a base name and scope. And since I want to search an entire subtree, I would specify a scope of SUBTREE. Does this make sense? Are there alternatives?

Advice from LDAP experienced folks would be tremendous. Thanks.

Tim
  • 51

2 Answers2

2

What application are you trying to configure.

There large majority of application that have some level of LDAP support as an LDAP client, simply have no support for nested groups.

Short of modifying the software, you may be out of luck.

If your LDAP server happens to be Microsoft Active Directory, then there is a non-standard search filter, that may help you.

See: - http://support.microsoft.com/kb/914828 - http://msdn.microsoft.com/en-us/library/windows/desktop/aa746475(v=vs.85).aspx

The LDAP_MATCHING_RULE_IN_CHAIN is a matching rule OID that is designed to provide a method to look up the ancestry of an object. Many applications using AD and AD LDS usually work with hierarchical data, which is ordered by parent-child relationships. Previously, applications performed transitive group expansion to figure out group membership, which used too much network bandwidth; applications needed to make multiple roundtrips to figure out if an object fell "in the chain" if a link is traversed through to the end.

Zoredache
  • 131,987
0

If you know which specific group is authorized, start with that.

You'll get a reference to that object's LDAP distinguished name, and enumerate the member attribute of the object. That'll contain more distinguished names.

Check each of those objects. If it's a user, then they're a member of the group, add them to the list of authorized users. If it's a group, enumerate their member object as you just did to the 'base' group, adding users to the allowed list and enumerating groups.

I'd advise putting a limit on recursion (or better, a list tracking which objects have been checked to avoid checking them twice), as infinite loops are possible in group membership relationships.

You'll build a list of all user objects authorized, then compare the distinguished name of the authenticating user to see if it's in the authorization list.

Search base and scope are for limit the scope of attempted object lookups; you'll want to use a location that contains everything that you're looking at.

Shane Madden
  • 115,228