Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make ldap eauth 2 factor compatible #42280

Closed
michaelgibson opened this issue Jul 12, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@michaelgibson
Copy link
Contributor

commented Jul 12, 2017

Description of Issue/Question

Our Authentication service utilizes 2 factor based tokens.
Consequently you can only submit the users' password once.
All subsequent auth requests using the same token will be rejected.

A common solution for this setup with LDAP is to utilize a dedicated bind user for all authenticated bind requests.
Assuming we have that, my expectation is that the binddn and bindpw specified in the config would override any user passwords sent for binding to LDAP(other than a 1 time auth user check).

In the _bind function:
You can see the binddn and bindpw are used only to search for the user's dn which is used to override the binddn and bindpw set in the config.

According to the documentation, this is actually by design.
I'm not familiar enough with all the use cases that are being addressed in this code so I apologize for my confusion.
Is there a reason not to do something like this instead:

There are two phases to LDAP authentication. First, Salt validates authentication by passing the user's credentials. If binddn and bindpw are specified in the config, all other bind requests will use those values.(authorization, searches, etc...)
If not specified Salt authenticates to search for a user's Distinguished Name and group membership. The user it authenticates as in this phase is often a special LDAP system user with read-only access to the LDAP directory. After Salt searches the directory to determine the actual user's DN and groups, it re-authenticates as the user running the Salt commands.

@gtmanfred

This comment has been minimized.

Copy link
Contributor

commented Jul 12, 2017

@cro when you get a minute, can you take a look at this and see if you can provide some information about why we did the ldap eauth module the way we did?

Thanks,
Daniel

@cro

This comment has been minimized.

Copy link
Member

commented Jul 26, 2017

Having reviewed this more carefully may I just restate the problem and the desired functionality to make sure I understand?

Currently the problem appears to be the fact that when using LDAP + Salt's eAuth, Salt authenticates with LDAP via the user's name and password at least twice since we use the user's name and PW to bind as well as authenticate. With some 2FA solutions, 2FA tokens may only be used once, so auth always fails.

The desire is to modify the auth process so that a dedicated bind user is used to validate and retrieve the user's DN and associated memberships. After these are verified, only then is the actual user authenticated via 2FA token.

Did I get this right?

@michaelgibson

This comment has been minimized.

Copy link
Contributor Author

commented Jul 27, 2017

Yup essentially. Also all subsequent LDAP connections(for that job) should use the bind credentials(if specified).
I noticed that if a minion is taking too long, the authentication will get re-attempted via a time_auth function.

I added a check here for the existence of the show_jid key in the payload :https://github.com/saltstack/salt/pull/42426/files#diff-8aa8a7beb3814d772c1830930f3927a9R393
This only gets passed through the initial payload for the job so I am keying off that to determine whether it's the first auth attempt or a later one.

cachedout pushed a commit that referenced this issue Jul 31, 2017

Mike Place
Merge pull request #42426 from michaelgibson/features/issue-42280
adding 2-factor auth capability to ldap eauth module - #42280
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.