Bug 38515 - Dynamic LDAP Group Support
Summary: Dynamic LDAP Group Support
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_auth_ldap (show other bugs)
Version: 2.2-HEAD
Hardware: All All
: P1 enhancement (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate
Depends on:
Reported: 2006-02-05 04:38 UTC by Gregory Szorc
Modified: 2018-11-07 21:08 UTC (History)
0 users

Initial patch without caching support against 2.2.x branch (8.42 KB, patch)
2006-02-06 03:55 UTC, Gregory Szorc
Details | Diff
Continuation of previous patch (20.04 KB, patch)
2007-03-18 19:54 UTC, Gregory Szorc
Details | Diff
updated dynamic group patch (12.97 KB, patch)
2009-12-18 02:43 UTC, Joe Orton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gregory Szorc 2006-02-05 04:38:43 UTC
LDAP group records may have attributes "memberURL", which are LDAP URL's that
describe a search returning users in a group.  It would be helpful if Apache
could recognize these results and follow the links to obtain if a user is a
member in a dynamic group.
Comment 1 Gregory Szorc 2006-02-05 04:40:48 UTC
I intend to provide a patch that accomplishes the necessary functionality.  It
can then be fine-tuned by someone more adept with Apache module programming than I.
Comment 2 Gregory Szorc 2006-02-06 03:55:31 UTC
Created attachment 17599 [details]
Initial patch without caching support against 2.2.x branch

A first version of a patch against 2.2.x branch.  It has no cache support for
dynamic group lookup.  It also defaults to using the "uid" username attribute
for group membership.
Comment 3 Brad Nicholes 2006-04-18 18:53:56 UTC
The direction that the patch is taking seems reasonable but there appears to 
be some problems.  First, just adding a call to 
util_ldap_cache_comparedynamicgroup() in the ldap-group tag probably won't 
work.  ldap-group can take a number of groups and the patch doesn't seem to be 
able to handle a set of mixed static and dynamic groups.  You may need to have 
some way of detecting wheither a particular group is static or dynamic and 
then handle it from there.  Also since util_ldap is suppose to be a set of 
generic cross platform LDAP APIs, the function 
util_ldap_cache_comparedynamicgroup() seems a little specialized considering 
the scope of the other util_ldap APIs.

Obviously you will also have to fix the code in 
util_ldap_cache_comparedynamicgroup()to respect the search attribute and scope 
rather than hardcoding "uid" and "LDAP_SCOPE_SUBTREE".  You will also need to 
implement the caching somehow as well but that should be fairly similar to the 
way that user/group caching already works.  In fact you could probably just 
use the same cache but with a different attribute as the the key rather 
than "member" or "uniqueMember".
Comment 4 Gregory Szorc 2007-03-18 19:54:25 UTC
Created attachment 19734 [details]
Continuation of previous patch

The attachment is a patch I had against the 2.2.x branch.  I'm not sure if it
works, but it was hanging around my home directory and figured I should put it
up here.
Comment 5 Gregory Szorc 2007-03-18 20:10:34 UTC
I'd really like to get something incorporated into the tree.  However, I could
use some help formulating a proper solution.

I just sat down to create a new patch against the trunk.  Here are my initial
thoughts for the direction of the patch.

* Need 2 new config directives
 1) AuthLDAPEnableDynamicGroupLookups (defaults to off) - Determines whether
dynamic group lookup is enabled
 2) AuthLDAPDynamicGroupAttribute (defaults to "MemberURL") - Determines which
attributes can contain dynamic group LDAP URIs

* Dynamic group lookup is added to ldapgroup_check_authorization in
mod_authnz_ldap.c.  If enabled, we check dynamic group membership after regular
(static) group membership

Here is where it gets interesting.  Checking for dynamic group membership
involves the following steps:

1) Look for attributes in a group record that correspond to dynamic group LDAP URI's
2) Parse each result and perform a LDAP search to see if the current user DN is

Now, I would love to incorporate this feature into uldap_cache_compare in
util_ldap.c, but I'm not sure if it will fit.  I will have to add at least one
argument to this function whose value dictates whether to invoke the special
dereference-attribute-value-as-LDAP-URI-and-search functionality. 
Realistically, I will have to add more arguments that control how the search is
performed (see the existing patch for what I mean).  Is it acceptable to add all
of these extra arguments, or should I just create a new function that handles
dynamic group lookups explicitly (as is the behavior in the current patches)?

Any comments from the peanut gallery?
Comment 6 Joe Orton 2009-12-18 02:43:19 UTC
Created attachment 24730 [details]
updated dynamic group patch

I've attached an updated patch based on Gregory's work above, against tip of 2.2.x.

Still to do:

a) caching the attribute values of the dynamic group (uldap_cache_getattrvals)
b) restoring the config option to specify the "memberURL" attribute name (or names)
   to use, and iterate through the names if >1
c) port to httpd trunk

In the new year I'll work through these and submit a patch to dev@httpd for review.
Comment 7 Joe Orton 2009-12-18 02:45:01 UTC
[hit submit too soon]

Any comment, feedback from testing, or review of the patch is very welcome.
Comment 8 Joe Orton 2009-12-18 04:36:11 UTC
There is an existing implementation of dynamic group support for the (httpd 1.3 only) mod_auth_ldap which I've been comparing against:


One key difference is in the handling of the group-membership test.

Given a dynamic group definition:

memberURL: ldap:///ou=Engineering,dc=example,dc=com?one?(l=Cambridge)

("engineering people in Cambridge)

and a user DN which we are testing for membership of the group, of say:

cn=Joe Orton,ou=Engineering,dc=example,dc=com

the case.edu mod_auth_ldap will (AFAICT) perform a membership test by searching for:

basedn => cn=Joe Orton,ou=Engineering,dc=example,dc=com
scope  => sub
filter => (l=Cambridge)

i.e. to compose the group-membership test by simply replacing the group's DN with the userDN.  I can see that this would work for some cases (and probably the above) but it doesn't seem to be correct in the general case.  e.g. a memberURL of:

memberURL: ldap:///ou=Sales,dc=example,dc=com?one?(l=Cambridge)

would degenerate to the same search as above, yet is not necessarily a correct test for group membership.

The way it works in Gregory's patch seems correct: compose the filter with the normal test for user existence, so giving a search in the latter case of:

basedn => ou=Sales,dc=example,dc=com
scope  => one
filter => (&((l=Cambridge)(uid=jorton)))

but I'm not an LDAP expert so comment from someone who is would be great.
Comment 9 Eric Covener 2009-12-18 06:20:49 UTC
+1 on the latter base and filter from this LDAP pretender
Comment 10 Gregory Szorc 2009-12-19 11:58:32 UTC
The similarity of this patch to Case Western Reserve University's mod_auth_ldap module referenced in comment #8 is no coincidence: I was working in that department at the time and this patch stemmed from our desire to port the feature to Apache 2.x.

While I would like to continue giving support for this feature request, I'm afraid that legal reasons stemming from my current employer preclude me from giving any assistance at this time.  I feel bad abandoning this feature, but I'm afraid I have little choice.

I look forward to seeing this functionality integrated into the tree.
Comment 11 jkaluza 2014-01-16 08:52:21 UTC
There's one bug in the "updated dynamic group patch" which can be fixed by following diff:

@@ -355,7 +355,7 @@ TODO:
 +    for (n = 0; n < count; n++) {
 +        (*values)[n] = apr_pstrdup(r->pool, vals[n]);
 +    }
-+    values[n] = NULL;
++    (*values)[n] = NULL;
 +    ldap_value_free(vals);
 +    ldap_memfree(res);
Comment 12 William A. Rowe Jr. 2018-11-07 21:08:31 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.