Red Hat Bugzilla – Bug 149905
When using "subtree" for UserScope option, module only searches one subtree depth from base OU
Last modified: 2007-11-30 17:07:06 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: The subtree search only searches one level depth from the base/bind OU. As an example, our LDAP has the following configuration: base - CO - Users - CA - Users (sorry for the semi-poor illustration) If I set AuthzLDAPUserBase to the base OU, then even with AuthzLDAPUserScope set to 'subtree', I cannot authenticate. However, if I set AuthzLDAPUserBase to 'CO', then I can authenticate but only with CO users. From what documentation I found on what appears to be the mod_authz_ldap home page (http://authzldap.othello.ch/) it appears that the subtree search will take the input username and "add" it to any nodes it finds within the base to search them when 'subtree' is set as it's method of constructing the search. While this may be by design, it would not allow for LDAP OU structures more than one level deep being compatibile with mod_authz_ldap for authentication, and therefore something I would consider a defect. Version-Release number of selected component (if applicable): mod_authz_ldap-0.22-5 How reproducible: Always Steps to Reproduce: 1. Configure mod_authz_ldap for base OU. 2. Try unsuccessfully to log in using a test user account in a "third tier" OU. 3. Reconfigure mod_authz_ldap for OU that test user account is in, or one level about. 4. Are then able to successfuly authenticate using same test account. Actual Results: Could only log in when AuthzLDAPUserBase is set to an OU that is no more than one level higher than the OU containing the user account used to log into. Expected Results: mod_authz_ldap should be able to search all subtrees recursively from the base OU set in AuthzLDAPUserBase, regardless of depth of OU structure. Additional info:
Afterthought. May or may not be important, but the LDAP being bound to in my case is Microsoft AD.
Subtree scope should certainly be searching the whole subtree, yes; otherwise it's exactly equivalent to onelevel. Can you post the entire config fragment?
Subtree search seems to be working as expected here against an OpenLDAP server. What gets logged to the error log when auth is denied? Can you try reproducing this using the "ldapsearch" command-line tool, to verify that OpenLDAP is working correctly; e.g. $ ldapsearch -x -h the.ad.box.com -b base-DN uid=joebloggs
Further research: it appears this may be be related to use of referrals in AD. Further information would be useful: - is the AD on Win2K or Win2003? - given a working or not-working ldapsearch command as above; does also passing the -C option make a difference?
Looks like this one was my mistake. Was using your suggestions, and having trouble getting a bind to the ldap via the command line ldapsearch. When looking at the error log for Apache, was seeing mostly just "basic LDAP authentication of user 'username' failed. Not much usefull there. Then remembered that for other applications, we had used a different port than the default 389 to bind to AD. In a nutshell, it looks like AD doesn't like to be bound to on port 389 at the root of the domain. Changed the bind port in the authz_ldap.conf to 3268, and now all is working well. For reference, it is 2003 Active Directory, and this is the conf being used: ______________________________________________________________ LoadModule authz_ldap_module modules/mod_authz_ldap.so <IfModule mod_authz_ldap.c> <Location /portal> AuthzLDAPEngine on AuthzLDAPSetAuthorization off AuthzLDAPServer server.corp.mxtr.net:3268 AuthzLDAPUserBase dc=corp,dc=mxtr,dc=net AuthzLDAPUserKey sAMAccountName AuthzLDAPUserScope subtree AuthzLDAPBindDN username@corp.mxtr.net AuthzLDAPBindPassword password AuthType basic AuthName "Authorized Access Test" require valid-user </Location> </IfModule> _________________________________________________________ Issue resolved by changing bind port. Sorry for jumping the gun and jumping to the wrong conclusion on this issue. Please accept my apologizes for wasting your time. :)
No problem, glad to hear you got it working.