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
Comments
we definitely want the Bind operation to continue to support unauthenticated binds, but updating the example with an explicit |
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. |
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,
The text was updated successfully, but these errors were encountered: