[Geoserver-devel] LDAPBaseSecurityService deletes userSearchBase during DN lookup

Hello developers.

I am analysing my troubles while connecting a GeoServer’s (2.19.0) LDAP User Group Service against a big and complex Active Directory and started to dive into the code a few days ago.

In method org.​geoserver.​security.​ldap.​LDAPBaseSecurityService.lookupDn(String username) I see that the LDAP context is searched for a given username with a specific userNameFilter. Unfortunately, whatever userSearchBase I specify in my User Group Service configuration is overwritten by an empty string as the first parameter of searchForSingleEntry(“”, userNameFilter, new String {username}). Especially strange because the Web UI forces me to specify a user search base even if I wanted to leave it empty. This is one reason why my already authenticated user is not correctly bound and the GeoServer group lookup fails for him. If I change this sub-method call to include the userSearchBase, it works! Is the userSearchBase deleted/omitted intentionally? If not, should I open a new issue and supply a patch?

Background: Our users are organised in many different OUs. Because the Web UI forces me to specify a user search base, I have to create an individual User Group Service per OU. But then some user/group mappings do not work anymore for users belonging to a different OU than the specified one! (An LDAP group can contain users from different OUs.)

To avoid this I wanted to create just one generic User Group Service. For that I would have to omit the user search base in order to root the search at the Domain Component (DC). But omitting is forbidden in the UI. Thus, I tried a workaround by moving the DC from the “Server URL” field into the “User search base” field. This works in theory, but not having the DC as part of the server URL makes it invisible to GeoServer’s LDAP context and with the above described “parameter skipping” in searchForSingleEntry(…) it gets completely lost. Thus, DN lookup for a user stops working correctly.

Hopefully someone can understand my problem. GeoServer’s LDAP implementation is pretty complex and in conjunction with ancient Active Directory setups it produces chaos. Difficult for an uninvolved individual to precisely pin down a problem :slight_smile:

Thanks a lot! Michi