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
Comment #1
gwfran CreditAttribution: gwfran commentedMore 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.
Comment #2
johnbarclay CreditAttribution: johnbarclay commentedDo 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?
Comment #3
gwfran CreditAttribution: gwfran commentedUser 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!
Comment #4
gwfran CreditAttribution: gwfran commentedUsing 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)."
Comment #5
nlozovan CreditAttribution: nlozovan commentedI 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.
Comment #6
gwfran CreditAttribution: gwfran commentedComment #7
johnbarclay CreditAttribution: johnbarclay commentedI 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...
?
Comment #8
johnbarclay CreditAttribution: johnbarclay commentedComment #9
gwfran CreditAttribution: gwfran commentedTried 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
Comment #10
gwfran CreditAttribution: gwfran commentedOkay, 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.
Comment #11
johnbarclay CreditAttribution: johnbarclay commentedCan someone try to replicate this on the current 7.x-2.x-dev?
Comment #12
johnbarclay CreditAttribution: johnbarclay commentedComment #13
u.kurilla CreditAttribution: u.kurilla commentedI 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.....
Comment #14
u.kurilla CreditAttribution: u.kurilla commentedThe 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.
Comment #15
johnbarclay CreditAttribution: johnbarclay commentedI 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.
Comment #16
u.kurilla CreditAttribution: u.kurilla commentedI 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......
Comment #17
u.kurilla CreditAttribution: u.kurilla commentedI 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. :-)
Comment #18
johnbarclay CreditAttribution: johnbarclay commented#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.
Comment #19
johnbarclay CreditAttribution: johnbarclay commentedCan someone try to replicate this in 7.x-2.x-dev? I cannot even using "dn" as puid.
Comment #20
johnbarclay CreditAttribution: johnbarclay commentedComment #22
pabloroberto27 CreditAttribution: pabloroberto27 commentedI am having the same problem in my site.
When two users log in, the second overrides the first user Drupal account. I'm working with the 2.x beta 5 version, maybe the problem persist, but because of the little number of cases I think it belongs from my configuration.
To be sure, when using "dn" in the "Persistent and Unique User ID Attribute" field is it necessary to fill the field "Expression for user DN. Required when "Bind with Users Credentials" method selected."?
In the reports, the user module shows an error since it's enabled, maybe is related to this:
User Fields for LDAP User Module Missing
Fields are added to the Drupal User entity for LDAP User module functionality. These fields should have been created in LDAP User update 7203. The following userfields are missing:
ldap_user_prov_entries instance
ldap_user_last_checked
ldap_user_last_checked instance
ldap_user_ldap_exclude
ldap_user_ldap_exclude instance
Rerun update 7203 to correct this; it will not write over destroy existing fields.
Thank you.
Comment #23
johnbarclay CreditAttribution: johnbarclay commentedPlease only test against -dev; not beta versions.
Comment #24
chrowe CreditAttribution: chrowe commentedNo luck yet. I am working with an existing site and can't start from scratch though
Base Case
Test: 7.x-2.0-beta5
Result: same as reported in this issue
Test #1
Test: Using 7.x-2.0-beta5 I tried the solution from #17 and removed 'dn' from the 'Persistent and Unique User ID Attribute' field.
Result: The effect this had was to stop new users from being created. I could log in with existing accounts but accounts not already in Drupal where not recognized.
Test #2
Test: dev on top of beta5
$ drush dl ldap --dev
$ drush updb
ldap_authorization module : 7204 - make all schema field names lowercase in ldap server to deal with cronic case sensitivity issues
$ drush cc all
$ drush cron
Result: no change from Base Case
Test #3
Test: disable/enable
$ drush dis ldap_servers
$ drush en ldap_servers, ldap_user, ldap_authentication, ldap_authorization, ldap_authorization_drupal_role, ldap_test, ldap_help
Comment #25
JustJenFelice CreditAttribution: JustJenFelice commentedWe were still experiencing this issue with LDAP Authentication on our site as well. Removing the "dn" entry under Persistent and Unique User ID Attribute alleviated the problem with user accounts being overwritten, but we're still attempting to delve deeper into why this problem was happening in the first place. It doesn't seem reasonable that the settings under "Persistent and Unique User ID Attribute" should allow the partial overwrite of user accounts. In our case, when attempting to authenticate and create a second user account, the previously created Username (User1) was not being updated, only the associated email was changing from User1's email to User2's. Very weird.
Comment #26
johnbarclay CreditAttribution: johnbarclay commentedComment #27
johnbarclay CreditAttribution: johnbarclay commentedI ran across this in helping someone with their configuration. To create or update drupal entries, the server configuration needs to both derive a matching username and store a permanent user id. Test a sample user to make sure this is the case and that these derived values are unique. dn is not a good attribute for the unique attribute. cn may be if you never change them for users.
To continue on with this as a bug, the following is needed:
- mappings for username, authname, and permanent user id
- an example of two ldap entries where this conflict occurs (anonymized).
Comment #28
nielsvoo CreditAttribution: nielsvoo commentedThanks #17 fixed it for me.... just deleted "dn"
Comment #29
stevecory CreditAttribution: stevecory commentedHow to reproduce this problem:
1) An end user, Edgar Kelly, chooses a username of ekelly.
2) Edgar selects "Create new account” with Username: ekelly and Email address: edgar.kelly@nih.org
3) After being prompted by email, the administrator edits the user profile from Blocked to Active.
4) The Drupal server sends email to edgar.kelly@nih.org with a set password link.
Note: The LDAP User to Drupal User Relationship has:
Base DNs for LDAP users, groups, and other entries. ("ou=people,dc=unc, dc=edu")
AuthName attribute (uid)
Email attribute (mail)
Expression for user DN. Required when "Bind with Users Credentials" method selected. (ou=people,dc=unc, dc=edu)
Also, The Password Reset Landing Page (PRLP) module is installed and active
5) Edgar signs on with his password & confirmation.
6) The LDAP module checks the server in the configuration and matches the username.
7) The Firstname, Lastname and Email are modified to "Erin", "Kelly", " ekelly@unc.edu" which is what is on the server in the configuration.
What should the settings be to avoid the email with the change password link getting sent?
Comment #30
generalredneckSo I'm another one that has had this problem. If you want to team up, I can reproduce this issue on a site I'm working on for a client. If you want I can do evening and weekends for getting together and we can do a hangout or join.me or something. #17 worked for me too. I may take a crack at seeing what the down low is. Frankly the module only queries for dn mail samaccountname memberof (last one after a patch). So if you want an email with some of these items I can send it your way as I doubt you will got mailing these 3 test users that my client has. If you need other parameters, that's cool too. I can give you a list of what I have accessable and my settings and we can go from there. I'll give you a heads up if I find out the cause before then as well.
Comment #31
Satyanath Shankaran CreditAttribution: Satyanath Shankaran as a volunteer commentedI am facing the same issue. I have created 3 users in LDAP and only admin in Drupal. I have set the settings same as the first poster. When I login as one user it works fine. When I login as second user and go to My Account I get first users details. Now when I log out and login as third user and go to My Account I get the second user details. This continues. So the My account shows the previous user rather than the current one. I have also given dn as the puid. I have not yet changed it. But will try changing.
I am using LDAP authentication module version 7.x-2.0-beta8.
If you need any help in debugging this issue I can help. Unfortunately with this issue the LDAP module is unusable for me.
UPDATE: I am pasting some portion of the log which shows the username change. You can see in the log that the user name used to log in is mahesh (cn = mahesh). but later it changes to cn=satyanath and even the session is opened for satyanath. I further put in lot of debug messages and narrowed down the issue to the statement. In this the username changes to satyanath. The drupal account value at the time of this call is proper.
$drupal_account = user_save($drupal_account, $user_edit, 'ldap_user');
This is under section VI A in the code.
Log follows:
2015-07-15T06:14:06.396604+00:00 pfiserver slapd[10434]: conn=1210 op=1 SRCH base="ou=people,dc=pfiacademy,dc=net" scope=2 deref=0 filter="(cn=mahesh)"
2015-07-15T06:14:06.396766+00:00 pfiserver slapd[10434]: conn=1210 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
2015-07-15T06:14:06.401163+00:00 pfiserver slapd[10434]: conn=1210 op=2 BIND anonymous mech=implicit ssf=0
2015-07-15T06:14:06.401330+00:00 pfiserver slapd[10434]: conn=1210 op=2 BIND dn="cn=mahesh,ou=people,dc=pfiacademy,dc=net" method=128
2015-07-15T06:14:06.401469+00:00 pfiserver slapd[10434]: conn=1210 op=2 BIND dn="cn=mahesh,ou=people,dc=pfiacademy,dc=net" mech=SIMPLE ssf=0
2015-07-15T06:14:06.401602+00:00 pfiserver slapd[10434]: conn=1210 op=2 RESULT tag=97 err=0 text=
2015-07-15T06:14:06.401998+00:00 pfiserver slapd[10434]: conn=1210 op=3 UNBIND
2015-07-15T06:14:06.402151+00:00 pfiserver slapd[10434]: conn=1210 fd=17 closed
2015-07-15T06:14:06.404997+00:00 pfiserver drupal: http://www.pfiacademy.net/courses|1436940846|ldap_authentication|117.192.181.149|http://www.pfiacademy.net/courses/node?destination=node|http://www.pfiacademy.net/courses/|0||mahesh : Authentication result id=0 auth_result=6 (Success.)
2015-07-15T06:14:06.412058+00:00 pfiserver drupal: http://www.pfiacademy.net/courses|1436940846|ldap_server|117.192.181.149|http://www.pfiacademy.net/courses/node?destination=node|http://www.pfiacademy.net/courses/|0||ldap_search() call: base_dn: ou=people,dc=pfiacademy,dc=net,#012filter = (cn=satyanath),#012attributes: dn,mail,,cn,#012attrsonly = 0,#012sizelimit = 0,#012timelimit = 0,#012deref = ,#012scope = 3
2015-07-15T06:14:06.412643+00:00 pfiserver slapd[10434]: conn=1211 fd=17 ACCEPT from IP=[::1]:49529 (IP=[::]:389)
2015-07-15T06:14:06.413001+00:00 pfiserver slapd[10434]: conn=1211 op=0 BIND dn="cn=Manager,dc=pfiacademy,dc=net" method=128
2015-07-15T06:14:06.413324+00:00 pfiserver slapd[10434]: conn=1211 op=0 BIND dn="cn=Manager,dc=pfiacademy,dc=net" mech=SIMPLE ssf=0
2015-07-15T06:14:06.413471+00:00 pfiserver slapd[10434]: conn=1211 op=0 RESULT tag=97 err=0 text=
2015-07-15T06:14:06.413903+00:00 pfiserver slapd[10434]: conn=1211 op=1 SRCH base="ou=people,dc=pfiacademy,dc=net" scope=2 deref=0 filter="(cn=satyanath)"
2015-07-15T06:14:06.414059+00:00 pfiserver slapd[10434]: conn=1211 op=1 SRCH attr=dn mail 1.1 cn
2015-07-15T06:14:06.414192+00:00 pfiserver slapd[10434]: conn=1211 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
2015-07-15T06:14:06.463703+00:00 pfiserver drupal: http://www.pfiacademy.net/courses|1436940846|ldap_server|117.192.181.149|http://www.pfiacademy.net/courses/node?destination=node|http://www.pfiacademy.net/courses/|0||ldap_search() call: base_dn: ou=people,dc=pfiacademy,dc=net,#012filter = (cn=satyanath),#012attributes: dn,mail,,cn,#012attrsonly = 0,#012sizelimit = 0,#012timelimit = 0,#012deref = ,#012scope = 3
2015-07-15T06:14:06.464582+00:00 pfiserver slapd[10434]: conn=1211 op=2 SRCH base="ou=people,dc=pfiacademy,dc=net" scope=2 deref=0 filter="(cn=satyanath)"
2015-07-15T06:14:06.464766+00:00 pfiserver slapd[10434]: conn=1211 op=2 SRCH attr=dn mail 1.1 cn
2015-07-15T06:14:06.464911+00:00 pfiserver slapd[10434]: conn=1211 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
2015-07-15T06:14:06.496200+00:00 pfiserver drupal: http://www.pfiacademy.net/courses|1436940846|user|117.192.181.149|http://www.pfiacademy.net/courses/node?destination=node|http://www.pfiacademy.net/courses/|44||Session opened for satyanath.
2015-07-15T06:14:06.504182+00:00 pfiserver drupal: http://www.pfiacademy.net/courses|1436940846|ldap_server|117.192.181.149|http://www.pfiacademy.net/courses/node?destination=node|http://www.pfiacademy.net/courses/|44||ldap_search() call: base_dn: ou=people,dc=pfiacademy,dc=net,#012filter = (cn=satyanath),#012attributes: dn,mail,,cn,#012attrsonly = 0,#012sizelimit = 0,#012timelimit = 0,#012deref = ,#012scope = 3
2015-07-15T06:14:06.504781+00:00 pfiserver slapd[10434]: conn=1211 op=3 SRCH base="ou=pe
Comment #32
sashkernel CreditAttribution: sashkernel commentedRemoving "DN" fixed my issue. I had exact same problem as #5
Comment #34
khu CreditAttribution: khu as a volunteer commentedRan into same issue when entering dn as puid.
Upon investigation it turns out that the function responsible for retrieving puid from ldap entry assumes the attribute set is multi-valued, which then returns the first char of the DN string when DN is set as the puid attr.
This causes all ldap users to have the same puid ("c") which then overwrite each other's user account data.
Patch attached to account for single-valued ldap attr set as puid attr.
Comment #35
khu CreditAttribution: khu as a volunteer commentedComment #37
grahlComment #39
grahlWow, thanks for tracking that down khu.
Committing this without verification since the description is clear, problem is known and real and side-effects are basically non-existing.