LDAP auth backend does not return groups when authenticated user cannot search

[blalor]

I'm attempting to use JumpCloud as an LDAP provider for Vault. They allow the creation of a binding user that can bind to and search the directory, but users themselves are only allowed to bind; they cannot search. To determine if the user's password is valid during authentication, Vault re-binds the connection, and then performs the search. But since the authenticating user doesn't have permission to search, the search returns no results. (I spent a lot of time trying to chase this down; no error is returned by the server, which seems wrong, but ¯\_(ツ)_/¯.)

I would like for Vault to have the option to perform the search while (re)bound using the credentials provided to the auth backend.

[dteleguin]

+1. We are using corporate LDAP directory, where users live in ou=People,o=Company, and groups in ou=Groups,o=Company. Users are restricted to ou=People, and cannot access anything else, which is a pretty sane (and widespread I think) security policy.

In my case, diagnosing the problem was a bit easier. Attempt to authenticate a user gave the following:

URL: PUT http://localhost:8200/v1/auth/ldap/login/myuser
Code: 400. Errors:

* LDAP search failed: LDAP Result Code 32 "No Such Object":

This immediately made me think I was dealing with a LDAP permission problem.

@blalor, you are proposing the following flow:

• bind as binddn;
• search for user entry;
• rebind as userdn;
• (if successful) rebind as binddn;
• search for groups.

Am I right? I think we can save one rebind (step 4) if we search for groups before authenticating:

• bind as binddn;
• search for user entry;
• (if found) search for groups;
• rebind as userdn.

However, this will come at a cost of group search performed even in the case of authentication failure.

As for making it optional, I think either variant could be safely turned into a default behavior.

[blalor]

@dteleguin yep, that's exactly the flow I'm proposing; it's super pedantic, but avoids Vault retrieving more information than it needs, at the expense of an additional bind. I don't see any harm in performing the search before testing the user's password, however. In the case of a user logging into a Linux server and using an SSH key for authentication, the password is never even tested.

[jefferai]

Just want to note here that implementation of this is unlikely to come from the Vault team anytime soon due to too much existing workload, so if you want to see traction you may want to look at implementing yourself!