Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 149905 - When using "subtree" for UserScope option, module only searches one subtree depth from base OU
When using "subtree" for UserScope option, module only searches one subtree d...
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: mod_authz_ldap (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
Depends On:
  Show dependency treegraph
Reported: 2005-02-28 13:26 EST by Darryl Carden
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-03 12:34:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Darryl Carden 2005-02-28 13:26:21 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:

 - 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):

How reproducible:

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:
Comment 1 Darryl Carden 2005-02-28 14:03:57 EST
Afterthought.  May or may not be important, but the LDAP being bound to in my 
case is Microsoft AD.
Comment 2 Joe Orton 2005-03-03 06:30:26 EST
Subtree scope should certainly be searching the whole subtree, yes; otherwise
it's exactly equivalent to onelevel.

Can you post the entire config fragment?
Comment 3 Joe Orton 2005-03-03 06:54:38 EST
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

Comment 4 Joe Orton 2005-03-03 08:31:17 EST
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?

Comment 5 Darryl Carden 2005-03-03 12:27:41 EST
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


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. :)
Comment 6 Joe Orton 2005-03-03 12:34:17 EST
No problem, glad to hear you got it working.

Note You need to log in before you can comment on or make changes to this bug.