I tried updating from beta2 to beta3 this morning, and after a few hours of testing I couldn't get any logins to work with beta3. Even users like "User 1" and static users were being blocked alongside all LDAP users.

I tried removing all modules that were related to user management to no effect. I still could not get any successful authentications.

Testing my LDAP connections in both the Data and LDAP Help portions did not show any errors. Connection tests ran fine.

The only message in the logs was "Login attempt failed for ." regardless whether it was LDAP or static.

Sorry for being vague, but I unfortunately do not have any more time to debug the issue this week.

Comments

cgmonroe’s picture

cgmonroe commented

Some quick thoughts / information needs:

Did you run update.php? There are a fair number of schema changes that need to be made before beta3 will work.

Were there any errors in the php error logs or the watchdog log?

What ldap_integration modules did you have enabled / configured? E.g. the ldapgroups module can deny access based on group membership. If this isn't set up correctly, you can get denied by this. See the Test Settings tab for some more tests you can run to verify it's set up correctly.

What type of DB are you using and version? This has been tested with MySQL but not PostGres.. or it could be an old/new SQL version problem. This may be related to the uid=1 not being allowed since one of the first things done is a query is used to determine if the user name on the login form is UID 1.

Please post the LDAPHELP status output... note: the errors about Object not being convertible to Strings can safely be ignored.

Are you using this with any other authentication modules like Webserver authentication or CAS?

What webserver are you using? Does it have any authentication modules enabled that might be causing problems?

cgmonroe’s picture

cgmonroe commented

FYI - The -dev version has a beta3 friendly version of ldaphelp now. See the comment/attached files about how to update beta3 to include this (without going to the dev version) here:

http://drupal.org/node/1475272#comment-6218078

jonathan_w’s picture

jonathan_w
he/him
Primary language English
Location Omaha, NE, USA
commented

We had this exact same problem. After redoing the Groups settings, the logins started functioning properly again.

cgmonroe’s picture

cgmonroe commented

FYI - The -dev version now has an option to output extra watchdog messages during user login. This should help point to the reason(s) a person is being denied... including by ldapgroups.

For full details see: http://drupal.org/node/1475272#comment-6231010

cgmonroe’s picture

cgmonroe commented
Status: Active » Postponed (maintainer needs more info)
cgmonroe’s picture

cgmonroe commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Closing this as "cannot reproduce" because of no additional details supplied in over a month... in addition, with over a 1000 sites using beta3, there should have been more comments if it was not a site specific problem.

Re-open if needed.

andrew.green’s picture

andrew.green commented

First off, I figured out the issue and fixed it.

Thanks for the tips and trying to determine the issue. It shows that you were really trying to assist me with my problem.

The blocked logins were being caused due to a conflict between the module No request new password, and the options in the UI for "Remove password change fields from user edit form".

I had previously had the NRNP module enabled and the UI option enabled with beta2. However, the more strict authentication checking of beta3+ was being trumped.

My solution was to disable NRNP and just use the LDAP UI option to block the link and form fields.