I have had 3 incidents of this kind, with 3 different users. Here is the long story: Our ID management team (that runs the directory service) called me up saying a user was blocked in the directory -- our enterprise policy is that if one fails 3 times to enter a password, that ID is disabled for 15 minutes or until manually re-enabled in the directory -- and there were large numbers of the user's bind attempts coming from the web app that I built running Drupal 6, with the ldap_integration module for user authentication.
Here is what I found in Drupal's "watchdog" table for the user in concern:
message = LDAP Bind failure for user %user. Error %errno: %error
variables = { "%errno"= 53; "%error" = "Server is unwilling to perform"; } -- %user removed
That was repeated every 3 seconds or so. So the effect was that the user was locked out of the system.
I contacted the user and was told that the he did login to my app once but never typed the password wrong or anything.
I did change the ldapauth.module, moved lines to create 2 new functions -- I will attach the diff.
I wonder if anyone else has seen anything like this? All help appreciated!
--
Wei
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | ldapauth.module.diff.gz | 2.18 KB | ww9rivers |
| ldapauth.module.diff | 5.41 KB | ww9rivers |
Comments
Comment #1
ww9rivers commentedForgot to add: Restarting the apache2 service on the host (SUSE Linux Enterprise Server 10.2 x86_64) that Drupal 6 runs under stops the repeated (and failed) LDAP bind attempts.
Comment #2
ww9rivers commentedI made a workaround of the problem by adding an __ldapauth_connect() function. The diff against the original ldapauth.module file is attached.
But the problem seems to be around still. When a password is wrong, instead of returning an error message to the user, the Drupal login process would seem to hang from the browser's stand point.
Comment #3
johnbarclay commentedAre you binding a "DN for non-anonymous search" in the server configuration?
Do you have "Do not store users' passwords during sessions" checked?
Comment #4
johnbarclay commentedComment #5
cgmonroe commentedClosing due to lack of further reports / information.