My Drupal Commons site authenticate users against 19 different Active Directory Domains and it works great.
But recently some users of domain xxxxxxx have been moved from a sub OU in the parent one i.e.:
From: CN=Name Surname,OU=Subunit,OU=Users,DC=xxxxxxx,DC=yyyyyy,DC=net
To: CN=Name Surname,OU=Users,DC=xxxxxxx,DC=yyyyyy,DC=net
And now the user is not able to login to Drupal again with the error: "another user already exists in the system with the same login name".

I tried to edit the data in the database modifying by hand the value of field [dn] in table [ldapauth_users] and the field [Data] in the table [Users] to reflect the change in the domain controller, but is not working.

Of course if I delete the user on Drupal, the user can login again (a new user is created on first ldap login), but the connection with the posts made with the previous user is lost.

Does anyone knows a workaround? Is there some other table I need to edit to fix the wrong DN after the change?
Thanks.
A.

Comments

cgmonroe’s picture

See this issue for details:

#1694726: Another user already exists in the system with the same login name

Summary:

Beta3 fixed a bunch of potential security holes. One of them was problems that could occur due to the assumption that user names were unique across OUs and servers. The solution to this was two fold:

First, support for Persistent and Unique IDs (PUID) was added. This allows drupal accounts to be tied to ldap objects using the "GUIDs" that most modern LDAP servers provide to track replicated users. E.g. the ObjectGUID operational attribute or perhaps a local employee number attribute. This lets Drupal user entries definitively get mapped to LDAP objects regardless of if they have been moved. See the README-PUID.txt file for more info. FYI - If you want to assume uids are unique, just use this as the PUID attribute.

If you are not using PUIDs, then the hole was plugged by only allowing users to be mapped if the Drupal stored dn matches the LDAP dn the person's uid and password mapped to.

However, this bring up "transition" issues. Where LDAP entries have been moved but the PUID info has not been set. The latest -dev version has some tools in the ldaphelp module to help you thru these. See the issue referenced above.

Oh, one thing that hasn't been mentioned in the issue listed above, if you have configured the module to sync the local passwords with LDAP, then converting the user to a local user will not work unless you change the local password to something different than the LDAP password. The code test for a valid local id/password first and only tries to look up stuff in LDAP if this fails. Changing the password will cause the LDAP entry to be found and the user re-mapped.

Note that the new ldapsync module can be configured to only sync "existing" accounts and will do the same thing that a user logging in does. So this is a way to "bulk add" PUID entries.

koglinjg’s picture

Just thought I would also comment here that I made a patch for this on the case mentioned above:

http://drupal.org/node/1694726#comment-6655266