Jump to:
| Project: | Lightweight Directory Access Protocol (LDAP) |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
User A logs in successful against the AD server. User B then logs in successfully on a separate computer. User A looks at his account via the "My Account" link and is now logged in as User B.
Under Servers, we are using a Service Account Bind, AuthName/AccountName is "SAMAccountName", Email Attribute is "UserPrincipalName", Unique User ID Attribute is "dn", Expression for user DN is "cn=%username,%basedn".
Under User, we "Show option on user create form to determine how account conflict is resolved", "Create or Sync to Drupal user anytime a Drupal user account is created or updated. Requires a server with binding method of "Service Account Bind" or "Anonymous Bind", "Associate Drupal Account with the LDAP entry", "Account creation settings at /admin/config/people/accounts/settings do not affect LDAP Associated Drupal accounts", "Do not check for orphaned Drupal accounts".
Authentication settings are "Only LDAP Authentication is allowed except for user 1", "Show disabled email field on usr forms...", and "Update stored email if LDAP email differs at login but don't notify user."
Thanks for any help you can lend!
Comments
#1
More info: In the Admin section, it looks like User 2 in the People list changes from User A to User B any time a new user successfully logs in.
#2
Do user A and B have different Drupal UIDs, LDAP PUIDs, and different Drupal usernames?
What happens if you convert user A and user B to drupal accounts and repeat the same process with LDAP disabled?
Can you test against 7.x-2.0-dev please also?
#3
User A was created in Drupal and was then matched up to the corresponding LDAP user entry. User B was never created in Drupal but exists in the LDAP. User A and B have different PUIDs within LDAP. I'll load 7.x-2.0-dev ASAP.
Thanks for your rapid jump on this!
#4
Using the 7.x-2.0-dev did not help. I get the following error now: "Notice: Undefined variable: ldap_authentication_authmap in _ldap_authentication_user_login_authenticate_validate() (line 507 of /usr/share/drupal7/modules/ldap/ldap_authentication/ldap_authentication.inc)."
#5
I also have this problem. Let's say I have only the admin drupal account. When I am trying to log in with an LDAP testing account, it goes in with no problems. When I log out and try to log in with a second LDAP testing account, it logs in, but the username of the first testing account overwrites the second one. The email stays the same. And the error with "Undefined variable: ldap_authentication_authmap" prints out.
#6
#7
I refactored the ldap authentication validation function completely to get more insight into this. It was unwieldy in length and branching. See http://drupalcode.org/project/ldap.git/commitdiff/048aa7423a085548261c7f...
The undefined variable issue is fixed. I still can't reproduce the error. It may be solved, maybe not.
Do you mind trying to reproduce again with http://drupalcode.org/project/ldap.git/snapshot/048aa7423a085548261c7f29...
?
#8
#9
Tried the variable fix - that definitely removed the error message. However, the user issue remains. Here's a list of all the modules I have installed in case there might be a conflict...
Hide Core
Hide Chaos tool suite
Hide Date/Time
Hide Fields
Hide Lightweight Directory Access Protocol
Hide Mail
Hide Other
Hide Panels
Hide Printer, email and PDF versions
Hide Rules
Hide User interface
Hide Views
Hide Webform
Hide XML sitemap
#10
Okay, what I've done is uninstall 2.x-dev and install 1.0-beta12. Now the creation of users works perfectly, but downgrading has resulted in an issue where logging in takes the user to a blank page (500 error). I think I've got a better chance of troubleshooting this error than the other one. Not sure if that analysis helps, but it's another benchmark...
[UPDATE] The 500 error was stupid. Checked the logs and it was a conflict between the ldap directory and a backup I had. Removed the backup and no error. Everything is working fine in 1.0-beta12 for me.
#11
Can someone try to replicate this on the current 7.x-2.x-dev?
#12
#13
I have tried and could replicate this on the current 7.x-2.x-dev (and on 7.x-2.0-beta3)
There is only one ldap generated drupal user possible. Every new login overwrites previous user data, apart from data not triggered from ldap (e.g. group, which is not in ldap).
In this context i found, that setting "AccountName attribute" in the server settings to a different value than default (e.g. "uid", which exists in ldap) causes a php error message:
Notice: Undefined index: uid in LdapServer->userUsernameFromLdapEntry() (line 965 of /var/www/drupal-sites/drupal7/panda/modules/ldap/ldap_servers/LdapServer.class.php).
Anyhow, the user is generated and logged in.
I am not sure, if there is a relationship between the routines.....
#14
The issue makes the ldap module not usable for me, due to functional, but also for security reasons. Therefore i have changed the prio and the status.
#15
I see an obvious bug, that might cause this or at least obfuscate the issue. I've committed the fix: http://drupalcode.org/project/ldap.git/commitdiff/4e4f4b28e57506bc73a901...
And some more checks for unresolved usernames:
http://drupalcode.org/project/ldap.git/commitdiff/e7310d04c9e3b089951661...
Additional checks could be made after any calls to LdapServer::entryToUserEdit() that return conflicted username conditions such as both $account->name and $edit['name'] being empty.
Please try this out; its committed to 7.x-2.x-dev.
#16
I have rechecked with a fresh drupal installation using only ldap module (+ctools +entity) and no problems occured! I will try to find out which combination cause the trouble......
#17
I found the reason for the problem and it is - like in most cases - a layer 8 problem. So the user - ME! - was too stupid. During ldap server module config i came along the parameter:
Persistent and Unique User ID Attribute
The description is:
In some LDAPs, a user's DN, CN, or mail value may change when a user's name changes or for other reasons. In order to avoid creation of multiple accounts for that user or other ambiguities, enter a unique and persistent ldap attribute for users. In cases where DN does not change, enter "dn" here. If no such attribute exists, leave this blank.
And i misunderstood the advice and entered "dn" here. If you do so, you will only get one ldap generated drupal user. Leave that parameter blank and everything is okay (tested with 7.x-2.0-beta3+80-dev)!
So if that is the planned behaviour i suggest to change the ticket status to fixed and close it. :-)
#18
#17. Using dn should not create a problem except if an individual's DN changes. So if using "dn" creates the problem, its still an issue. Thanks for narrowing it down. I will try to replicate it with dn.
#19
Can someone try to replicate this in 7.x-2.x-dev? I cannot even using "dn" as puid.
#20
#21
Automatically closed -- issue fixed for 2 weeks with no activity.