LDAPUsers top level query

[nasjomach]

In our LDAP env we have several top levels OU for storing different type of users.

com
   -- example
       -- One
           -- UserOne
       -- Two 
          -- UserTwo

With mod_ldap LDAPUsers an OU must be specified which blocks from being able to query all required users at once.

Right now, I need to configure 2 different VHOSTS, 1 for OU 1 and 2nd for OU 2 to be able to resolve both types of users I need.

This is really tedious and requires a lot of extra configuration, more vhosts config.

<VirtualHost one>
...
LDAPUsers "OU=One,DC=example,DC=com"
...
</VirtualHost>

<VirtualHost two>
...
LDAPUsers "OU=Two,DC=example,DC=com"
...
</VirtualHost>

[workuser002]

I too am experiencing this issue and looking for support of multiple base DNs, or multiple LDAPUsers entries, or something similar.

There's this forum topic (caution, old/broken TLS) where the poster said they successfully created a patch, but it's old and I wasn't able to find out if anything came of it.

Any news on this issue?

[workuser002]

I've found a fix to my specific issue and I'm going to add some details in case others run into it.

TL;DR for hitting Active Directory is to try port TCP:3268 for the Global Catalog (or possibly disabling LDAPAuthBinds)

I'm looking to have proftpd authenticate users in Active Directory that are members of a specific group. These users exist in multiple OUs, so I can't have an OU as first entry in the search base. I'm not able to find out where I first saw that the search base couldn't start with an OU, but thought I had seen it mentioned somewhere else as well, and indeed using my version of DC=example,DC=com as my search base failed. But why?

I used tcpdumps of the LDAP port to confirm that the bind is successful, the query for the user happens, and gives a result. Then I think the next query is to bind as the user (vs the bindDN) but that doesn't happen right as far as I can tell. This second bind request (for me) shows the following in tcpdump:

LDAPMessage bindRequest(4) "<ROOT>" simple

which the server doesn't like and responds with:

LDAPMessage searchResDone(3) operationsError (000004DC: LdapErr: DSID-0C090A71, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v3839) [0 results]

Some things I tried that didn't fix it:

• Setting LDAPQueryTimeout
• Using OR syntax in the LDAPUsers search base
• Using LDAP URL syntax for the LDAPServer and following it with a path some OUs

Changing to port 3268, which is for Global Catalog in Active Directory resulted in successful queries. Why? I'm not super sure, but I don't plan to dig at it any more unless it breaks again. Hope this helps others.