LDAPUsers top level query
Opened this issue · 2 comments
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>
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?
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.