OpenLDAP directory: authentication bind uses empty DN instead of resolved user

[sai.pabbareddy]

Continuing our Enterprise trial evaluation — this time on the "OpenLDAP/Generic LDAP" user directory type. We stood up a real OpenLDAP server (Docker, osixia/openldap), created a real user, and confirmed that user could bind successfully outside of ProGet (ldapwhoami succeeded). We were never able to get ProGet to authenticate that same user, and traced it to three separate issues, each confirmed against the LDAP server's own connection log:

1. Auto-derived search base is wrong when left blank

With the "User Search Base" field empty, ProGet derived a search base by treating our "Host" field's IP address as if it were a dotted domain name:
Host: 172.17.0.1
Derived base: dc=172,dc=17,dc=0,dc=1
Every search failed with LDAP error 32 ("no such object") until we set "User Search Base" explicitly to our real directory root (dc=progetpoc,dc=local).

2. The %s username placeholder in the "Users:" filter isn't substituted

The "Users:" field ships pre-filled by ProGet itself with (&(objectClass=inetOrgPerson)(uid=%s)). With a correct search base in place, the query actually sent to the LDAP server was (&(objectClass=inetOrgPerson)(?uid=)) — the %s collapsed to a literal ?, and the submitted username never made it into the filter. This matched zero users regardless of who was authenticating.

3. The credential-verification bind uses an empty DN instead of the resolved user

To isolate #2, we temporarily hardcoded the filter to (uid=ldapuser1). The search then correctly found the user (nentries=1). But the very next operation — presumably meant to verify the submitted password by binding as that user's DN — was instead BIND dn="" method=128, which succeeded trivially (an anonymous bind checks no password). ProGet then failed the overall request with an internal "No Such Object" error, surfaced to the client as a 500.

Full log excerpt:
SRCH base="dc=progetpoc,dc=local" filter="(&(objectClass=inetOrgPerson)(uid=ldapuser1))"
SEARCH RESULT tag=101 err=0 nentries=1
BIND dn="" method=128
RESULT tag=97 err=0
ProGet: "No Such Object" -> HTTP 500 to the client

Issue #3 is the one that actually blocks things — even a hand-corrected configuration that resolves the right user can't complete authentication. Is this a known issue, and is there a recommended workaround, or is this expected to be fixed in an upcoming build?

Thanks,
Sai

[rhessinger]

Hi @sai.pabbareddy,

Thanks for the details here. For 1, looking at the code, this is to be expected. We wrote this with the expectation the host would be a DNS name and we used that to build the search base for users and groups. The trade off is that if an IP address is used, then you will need to manually specify the search bases. WE will update our documentation to reflect this.

As for 2 and 3, I'm unable to recreate what you are seeing. Could you please provide screen shots with the values you have configured for the OpenLDAP User Directory?

Thanks,
Rich

[sai.pabbareddy]

@rhessinger

Please find the below screenshots.