After migrating a drupal site to a new install, existing users cannot login with LDAP auth!

I have had the same issue as of late. Mine have happened after upgrading a Drupal site from 4.6x to 4.73 and at the same time moving from an older version of the LDAP Integration module to the latest. I am working on figuring out a solution. If I find anything, I will post here.

Thanks,
Mark

I have the same error message in the log entries with HEAD version (updated the 2007-04-19):

LDAP user with DN cn=***,ou=***,ou=***,o=*** has a naming conflict with non-LDAP user *username*

and the error message for the user is:

* Another user already exists in this system with the same login name. You should contact the system's administrator in order to solve this conflict.
* user warning: Duplicate entry '' for key 2 query: INSERT INTO users (uid, created) VALUES (942, 1186041030) in ...../includes/database.mysql.inc on line 172.
* Sorry. Unrecognized username or password. Have you forgotten your password?

We run a cron job to update the Drupal Databases with all LDAP employees. We do that to user the usernode module to display list of all users.
The majority of user cannot connect, except some of them whom have connected during the development period.

I have really no idea where the problem come from, but my first guess is the wrong version of the module.
Any idea or suggestion to resolve this issue is welcome.

Damien

I'm working on migrating an existing site from webserver_auth to ldap_integration. I'm getting this same error message. The problem is that the existing users don't have the "ldap_authentified" information in the database. I'm working on a way to upgrade all accounts to work with ldap_auth after having used another method previously.

Here's a patch for Drupal 5 that should solve this issue. After configuring your LDAP server, go to the LDAP Integration settings page and choose the "Reset users" tab. On that page, press "Reset". You should be good to go.

The patch sets all users (except user #1 and those with status != 1) to authenticate via LDAP and imports their groups as roles if ldapgroups.module is enabled.

Note: It will always use the first LDAP server if multiple LDAP servers are configured.

Here's a patch updated for the 5.x-1.3 release.

Here are some bug fixes for the 5.x-1.3 update.

It works ok here.

a suggestion to improve the functionality provided by the patch is to allow to select which users to reset, with a form as the one in admin/user/user.

anyway, the patch could be commited at it's actual state!

Changed to feature request since it was not a bug - patch generally looks good and could be committed to head for next release though I didn't test extensively;

I have tried the junyor3 patch on two different instances, both configured similarly: both are running drupal-5.3 core with LDAP Integration 5.x-1.3, patched per http://drupal.org/node/171092 so groups appear on initial login. On one instance, the "reset users" tab shows up correctly and works as it should. On the other instance, the tab doesn't show up at all. I have checked the code in ldapauth.module to see what grants are required, and noticed that the required grant for the reset tab is 'access administration pages' instead of 'administer ldap modules' as is set for the other tabs. Changing the grant in the module does not change the behavior on the page, ie the tab still doesn't show up. On both instances, the users I'm logging in with have access to both grants I've tried in the module code, yet the tab still doesn't show up in one of the instances (which happens to be the instance where I really need it).

What am I missing? Sorry if this a noob mistake. I've been using Drupal for over 2 years now, and this problem is one of the few that has stumped me thus far.

@drcoachchris: Maybe it's something with the menu system. Try opening the Admin Menus page, then check if the tab appears. Sometimes that'll do it.

@Junyor: unfortunately, no dice on that one. If anything else comes to mind, please feel free to contact me. I'll keep plugging.

So, now we learn why garbage collection is important.

When I upgraded to the new version of ldap_integration, I kept an old version lying around in a directory under the module root. My instance was still pointing at the module from the old version (even though I had moved it into a subdirectory called "old") which didn't have the patch installed. Moving the old module code completely out of $DOCUMENT_ROOT solved the problem.

*sigh* I need to practice better version control in-house on my code.

Thanks for the help, Junyor.

I'm glad you got it working!

This is a great patch. Thank you.

I am wondering how we can "mass import" ldap users into Drupal. Damien, you mentioned you had a cron task - can you share?

Check out ldap_provisioning for lots of ldap user management, including mass imports - http://drupal.org/project/ldap_provisioning

Hi, thank you but I'm not sure that's what I need.

My situation is:

There are a bunch of active directory accounts out there
I need a way to mass import them as Drupal accounts

Will the module do that?

@mtndan: With the LDAP integration module, users with LDAP accounts will automatically be registered when they first access the Drupal site. This patch is needed if you have users in the Drupal site already and you want to switch them to use LDAP.

@mtndan - so just to be clear, the patch from #8 above will not do what you want. I'm not sure if ldap_provisioning will do it, but I believe it can do it. You will need to check it out since I haven't tried it yet.

Hi folks, I was able to accomplish this pretty easily. I'm planning to write it up and submit it as a handbook page.

@mtndan - did you post that write up?

I have tested the patch provided in http://drupal.org/node/80570#comment-440133 with Drupal 5.12 and LDAP Integration 5.x-1.3 and have found two bugs with the patch, of which one is really critical. I'm currently working on a patch for fixing both of the issues below and will upload it here asap.

1) Drupal users not existing in LDAP will be migrated with data from the last successfully migrated user (minus the username).
I happend to be in a situation in my development environment where not all of my Drupal accounts were existing in the LDAP directory. This caused all Drupal users not existing in LDAP to be migrated with data from the last successfully migrated user.

2) Incorrect user access requirements in ldapauth.module causes the "Reset Users" menu to not show up.
This was previously reported by drcoachcris in http://drupal.org/node/80570#comment-622175. The required user access requirement should be changed to "administer ldap modules" instead of "access administer pages".

Incorrect:

$items[] = array(
      'path' => 'admin/settings/ldapauth/reset',
      'title' => t('Reset Users'),
      'callback' => 'drupal_get_form',
      'callback arguments' => array('ldapauth_admin_reset'),
      'type' => MENU_LOCAL_TASK,
      'weight' => 2,
      'access' => user_access('access administration pages'),
      );

Correct:

$items[] = array(
      'path' => 'admin/settings/ldapauth/reset',
      'title' => t('Reset Users'),
      'callback' => 'drupal_get_form',
      'callback arguments' => array('ldapauth_admin_reset'),
      'type' => MENU_LOCAL_TASK,
      'weight' => 2,
      'access' => user_access('administer ldap modules'),
      );

Here is a updated patch based on the latest version of the patch provided by Junyor in http://drupal.org/node/80570#comment-440133. This patch will fix the following:

1) Drupal users will now only be converted to use LDAP authentication if the user actually exists as a LDAP user. If it doesn't exist, it will be reported and logged instead of conveted incorrect. (As previously reported in #23 above.)

2) Fixed incorrect user access requirements for the "Reset Users" menu item causing it to not show up. (As previously reported in #23 above.)

3) Moved the help message entered as $form['markup'] in ldapauth_admin_reset() to ldapauth_help() to follow Drupal dev standards. Also, the help message has been changed to give some more information about what will happen when pressing the "Reset" button. There is a minor flaw with this, and that is the duplicate output of the link "more help" at the bottom of the help message. I don't know how this should be fixed or why it happens. It has something to do with line 43 case 'admin/help#ldapauth':.

4) Updated some set_drupal_message() messages not using t() or using the function incorrect.

By the way, shouldn't the "Reset" button and "Reset Users" menu item be called something else giving a better description?

This patch should work for both 5.x-1.x-dev and 5.x-1.3.

O_o: Nice work! It's been a while since I've looked at this code, but here are a couple of comments based on skimming your patch:

1) The variable $result_output doesn't appear to be used (line 68 in your patch).
2) Use spaces instead of tabs. I know there are a lot of existing tabs, but when we're changing lines, we might as well do the correct thing.
3) Yes, the "more help" link is a side-effect of using hook_help().
4) I'm a bit confused how data is reused when users cannot be found via an LDAP search. The scoping of the variables should prevent that. However, it does make sense to only attempt user_save() if the DN lookup was successful.

In any case, I've updated my original patch to take your comments into consideration. I also removed an unneeded query, as user_save() can take care of updating the authmap. I've done a minimal amount of testing.

Glad to see you liked the updates!

The variable $result_output doesn't appear to be used (line 68 in your patch).

Ah... yeah, I must have forgotten to remove it. It belongs to a first try with a different solution. I'll remove it.

Use spaces instead of tabs. I know there are a lot of existing tabs, but when we're changing lines, we might as well do the correct thing.

Will fix.

I'm a bit confused how data is reused when users cannot be found via an LDAP search. The scoping of the variables should prevent that. However, it does make sense to only attempt user_save() if the DN lookup was successful.

If you refer to the previous solution, before my patch update, the problem was that the check for existing users in LDAP did not protect the $dn and $change variables so they could be used from previous succesful LDAP lookups.

I have just one thing that I would suggest as an improvement to the patch now, and that is the use of drupal_set_message() to show the exact same information that is logged into the Drupal log when a user can't be found in LDAP. It is not needed in my opinion. If some users fails to be converted to LDAP authentication we don't need to show the same message for each failure, creating a sort of duplicate "error log" with drupal_set_message(). It's a bad error message and drupal_set_message() is not meant to be used that way. It makes more sense (and are more user friendly) to show a clear and descriptive error message and then refer to the Drupal log for error details. See the example below:

drupal_set_message(t('@count of @total user accounts were successfully updated.', array(
      '@count' => $count,
      '@total' => $total)).($count < $total ? t(' <a href="@url">@users were logged as not updated</a> since no matching user in the LDAP directory could be found.', array(
      '@users' => format_plural($total - $count, '1 user', '@count users'),
      '@url' => url('admin/logs/watchdog'))) : ''));

This could be put after the line $ldapauth_ldap->disconnect();. Have a look at my patch again to see what I mean.

Edit: Corrected some spelling.

O_o: Yes, that makes sense. The format of the @total line is a bit confusing. Is it not possible to format the whole string into one t()?

@Junyor: I divided them into two separate t()'s because I don't wan't the line "@users were logged as not updated since no matching user in the LDAP directory could be found." to be printed if all users was successfully converted to LDAP authentication. The last t() will only be shown if there are at least one user who was not converted.

I'll post an update of your patch with this update within some days.

Almost a year later I found out that this patch might have come back to bite me in the hand. Today I found out that some users could not update their own LDAP data. They can read it, but not update it. The bug is caused by missing data in table authmap. If you use this patch, make sure to compare the user table with authmap afterwards. You can use the SQL script below.

SELECT u.*
FROM {users} AS u
WHERE u.name NOT IN (SELECT authname FROM {authmap})
ORDER BY u.uid;

Any users found by the query above must manually be added into the authmap table, or else those users won't be able to update their LDAP data. You can add those users using:

INSERT INTO {authmap} (uid, authname, module)
SELECT u.uid, u.name, 'ldapauth'
FROM {users} AS u
WHERE u.name NOT IN (SELECT authname FROM {authmap})
AND u.uid > 1
ORDER BY u.uid;

Sorry, changed the title of the issue by mistake. Changed it back.

Closing 5.x issues to clean out issue queue.