Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
OpenLDAP directory: authentication bind uses empty DN instead of resolved user
-
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:
- 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).- 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.
- 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 clientIssue #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 -
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 -
-
Hi @sai.pabbareddy,
You will have to also set the Group Search Base as well. Can you test that and let me know if anything changes?
Also, what OpenLDAP server are you using to run these test with?
Thanks,
Rich
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login