We're using ldap authentication with authorization mapping ldap groups to roles, and stumbled on a strange behavior.

If you attempt to login with an incorrect password, it correctly rejects you and returns you to the login screen. However, if you attempt to login and leave the password blank, it triggers a different form error indicating the password may not be blank -- but it also successfully creates a user session -- which means you can navigate to pages as if you had logged in.

To make sure there wasn't something odd going on with our Drupal installation or core settings, I disabled ldap and logged in as a standard Drupal user -- it correctly redirects me to the login and prevents a session in either scenario. So something in the ldap config or code is causing this to happen. I've combed through the config but can't find anything that might cause this. Anyone else run into it?


lcdservices’s picture

I've traced the code, but get a little lost in the ldap authentication. What I see is that we reorder the validations in form_alter, so that the core user module validates first. With an empty password, that validation is completely skipped (it only processes validation if both name and password are not empty).

So then it validates with _ldap_authentication_user_login_authenticate_validate. I'm guessing that somewhere in there it's simply not accounting for an empty password, or our ldap server is passing back a success on the ldap username search alone...?

Anyway, Drupal disallows an empty password regardless (but the native form error on the password field is thrown after the session is created, so it's useless in this context) -- why can't we just check for the existence of the password at the beginning of _ldap_authentication_user_login_authenticate_validate and return false if it's empty? That saves us the expense of processing the rest of the code and is a safer solution.

johnbarclay’s picture

Priority: Normal » Critical

Your suggestion is right on. Check for empty password in the ldap code. We can't rearrange the order of the validation, because drupal core user module validation isn't implemented correctly.

johnbarclay’s picture

Status: Active » Postponed (maintainer needs more info)

I can't reproduce this. Can you do the following:

- give more details on your configuration and any other authentication modules in use.
- if you are able to trace php, see where in ldap_authentication.inc _ldap_authentication_user_login_authenticate_validate the function is exited that would help. Also check if $form_state['uid'] has a value going into the function.

If you can't trace php, you can enable ldap_help and detailed logging and attach the watchdog log from authentication, that would help.

Attached is a patch for 7.x-2.0-dev that could be hand applied to 7.x-1.x also. It has a couple more checks for empty passwords, for non sso cases. We can't just check for empty passwords because of sso.

johnbarclay’s picture

Title: login with empty password creates user session » LDAP Authentication: login with empty password creates user session
Status: Postponed (maintainer needs more info) » Closed (duplicate)

The patches to the 7.x-2.x-dev and 7.x-1.x-dev dealt with this. This was a result of a similar issue #1920094: ldap authentication: allow login with null byte - null byte attack which at its root was en empty password fooling ldap binding into using an anonymous bind. Please test, but continue on that issue.