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.
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.
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.
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".
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.
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 returned. 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?
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.
[hit submit too soon] Any comment, feedback from testing, or review of the patch is very welcome.
There is an existing implementation of dynamic group support for the (httpd 1.3 only) mod_auth_ldap which I've been comparing against: https://its-services.case.edu/middleware/docs/mod_auth_ldap/ 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.
+1 on the latter base and filter from this LDAP pretender
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.
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);
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.