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
passwordless login! #37
Comments
This is very odd. I threw a quick test together which looks like this: ldap_user = Adauth.authenticate("administrator", "")
ldap_user.should be_false which passed no problem. then after adding a few more cases to to the test that first example failed giving me a successful authentication as administrator with no code change or anything... Something very odd is going on here its almost as if AD is allowing password less bindings which as far as I'm aware it shouldn't. More research is needed |
Is there anything I can do over here to provide some more data? You'll have to be be precise about what you want me to do though - I don't really know much at all about AD & it's configuration. Glad to help though, especially if it is something our AD is doing wrong (passwordless logins! Sounds bad...) |
Here's the log of a single login attempt, using username "james" and no password:
I've left my name in, but bodged out the others & replaced them with generic peeps. |
Just a question. Is the binding bit done by this user (set in adauth.rb)?
Because this user is a real user on our AD, ie I would be able to log in as this user & be authenticated. Because in the sessions controller I use (as per the doc):
Which would be the username & password that are typed into the login form correct? |
Ok, So I create a brand new AD account (called special). The account is bog standard: primary group is Active Directory/users I can still "Authenticate" a user without using a password, if I connect using the above account as the query user. I'm unsure of the internals of how AD/LDAP queries actually work, but could this possibly be something like:
So, is it a case the because we're already connected to AD using the query_user, we're not "authenticating" the user who is trying to log in, we're just trying to see whether they exist or not? And, could this be fixed by running the query using the supplied username & password rather than using a defined query_user? |
Query User us used to let Adauth query for information e.g. find the groups user X is in. Authenticate creates a new connection to AD using the supplied credentials to make sure that the details are valid. As far as I'm aware the only way Adauth would do this is if Net/LDAP returned a valid connection and again that should only happen if it gets a successful connection I've got some time today to test this so hopefully a solution will exist soon (Now that I've managed to replicate the issue my boss is happy for me to spend time looking at instead of doing other work) |
I've written up the case here: http://arcath.github.io/blog/2013/08/28/issue-37/ Basically the LDAPv3 Specification states that you need to make the rootDSE accessible anonymously which because we bind against it meant that Adauth would get a false positive. |
We've noticed that it's possible to login using adauth by supplying a correct username & a blank password. We've seen the following:
correct username & correct password -> login
correct username & incorrect password -> fail
correct username, & blank password -> login (as username)
incorrect username & [correct|incorrect|blank] password -> fail
This is even for users who are NOT currently in the users table (ie have never previously logged in).
Currently using the latest git master branch (pulled from git today using bundle update):
https://github.com/Arcath/Adauth.git
Setup is like this (boring bits omitted):
We added the begin/rescue/end in the create session because we encountered an error when giving incorrect usernames/passwords (ldap_user was true even for bad usernames - like logging in as asdf/crap_pass)
Removing the rescue still lets you log in without a password, and errors if the username or password is incorrect (but not blank), ie it being there has no effect on this issue, but it does prevent an error.
What's going on?
Oh, an excerpt from the users table:
Not sure whats going on with group_strings(!) or ou_strings, but I don't currently use them for anything.
This user logged on by providing username "james" and no password
The text was updated successfully, but these errors were encountered: