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

User Bind to AD with zero length password succeeds using example #93

Closed
oldCoderException opened this issue Oct 24, 2016 · 2 comments · Fixed by #317
Closed

User Bind to AD with zero length password succeeds using example #93

oldCoderException opened this issue Oct 24, 2016 · 2 comments · Fixed by #317

Comments

@oldCoderException
Copy link

Probably not a bug in the code itself, but the bind example is misleading when using Active Directory.

We are essentially using the code from https://godoc.org/gopkg.in/ldap.v2#ex-package--UserAuthentication to authenticate users. We loop through multiple LDAP and AD servers that may be used for authentication in our application. If we enter a valid username (login) but a zero length password, during the final bind operation as the user, the LDAP servers return an LDAP Result Code 53 "Unwilling To Perform" error, which is good. But on Active Directory 2012, the final user bind simply succeeds. If the wrong password is given, both the Active Directory and LDAP servers fail with a code 49 (invalid credentials), which is good. With a zero length password the AD will subsequently not let that unauthenticated but bound user see anything, but in the example as is, you have successfully authenticated so the user can then do whatever your application code allows her/him to do. We do check for zero length passwords as part of our own checks so this should never happen, but just in case we have further added a second search AS the user. That second search as the user then fails on AD with LDAP Result Code 1 "Operations Error": 000004DC: LdapErr: DSID-0C090752, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580

Just thought you should know, and maybe fix or change the example. Also here in case other folks using the library against AD get confused by this behaviour.

cheers,

@liggitt
Copy link
Contributor

liggitt commented Oct 24, 2016

we definitely want the Bind operation to continue to support unauthenticated binds, but updating the example with an explicit len(password) == 0 failure and a comment (even though the password is hard-coded in the example) would be fine with me

@oldCoderException
Copy link
Author

I totally agree that unauthenticated binds are desirable. Just as a point of interest, the old netscape Java libraries I've used for years have a separate "Authenticate" method which isn't a bad idea to clearly differentiate between simply binding and actually authenticating. Not sure what they do "under the covers" but it could be as easy as checking for zero length password before a bind. Just a thought.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants