In my configuration I use the LDAP_FIRST_LDAP setting, and can log on to ldap using only the username. I have registered a user account with drupal, which at that time did not exist in LDAP. Later on, the same user name is added to the LDAP database (or the drupal user changes it's username to one also present in LDAP).
When logging on with the drupal password, he logs on as drupal user, when using the ldap user's password, he logs on to ldap but still has the properties as if he logged on as a drupal user.
What would be preferable is to update the user data as 'ldap_authentified'.
The _ldap_integration_ldap_login function could be modified as:

....
if( !$user->uid ) {
// new user
...
}
else {
// update current drupal user as ldap_authentified
$mail = $ldap->retrieveAttribute($dn, LDAP_EMAIL_ATTRIBUTE);
$user = user_save($user, array('name' => "$name$at$server", 'pass' => $pass, 'mail' => $mail, 'init' => $mail, 'status' => 1, "authname_ldap_integration" => "$name$at$server", 'roles' => array(_user_authenticated_id()), 'ldap_authentified' => TRUE, 'ldap_dn' => $dn));
watchdog('user', t('User %user is now ldap authentified.', array('%user' => theme('placeholder', $name .'@'. $server))), WATCHDOG_NOTICE, l(t('edit'), 'user/'. $user->uid .'/edit'));
}

Comments

pablobm’s picture

I see your solution as a security breach, as usually admins will not want some users to take over others that way.

I think an error message should be issued saying something like: "There's a conflict there and the admin should fix it" (in a different phrasing, of course).

Besides, a solution might be having the system to allow conflicting users to use "user@server" login strings. Admin could set the "LDAP login pattern" to something like: /(\S+)(@(\S+))?/i . With that expression, the "@server" part would be optional and only users with conflicts would use it, rendering them unique.

But now, checking the code, I've realised the old "avoid user@server logins" setting is not working anymore. I should make it work again then. Probably it left in some code cleaning (too much cleaning may hurt you :P ).

Waldemar’s picture

In my porting to drupal 4.7 I had to implement an extra block to make that user@server setting work. However I see how one can get around it using hook_form_alter. I should get that done tomorrow.

pablobm’s picture

Status: Active » Closed (fixed)

I presume this is solved now.