We have connections from Drupal to an AD and a LDAP for different user groups and different purposes. The AD is for employees and controls network access and all sorts of stuff, where their record is created by an admin. They can log into the Drupal site using their network password for authentication. When they log in, a Drupal account is created and synched, roles assigned, and it all works fine.

Then we have public access available for clients. They sign up on the Drupal registration form. When they do, an admin processes their request and approves the account in Drupal. As I understand it, when the account gets moved from 'blocked' to 'approved,' Drupal (LDAP module) provisions the account using Drupal data out to the LDAP. This also works, except for one point. That is that for some reason the user account has to be saved twice. The first time, you set the account status and user roles and save, and it doesn't actually save it in Drupal. The account shows the original values on those fields. However, the account is at that point provisioned out to LDAP. If you make the same updates and save the Drupal account again, it updates the LDAP record (if you made any changes) and saves the proper values in Drupal. This is a minor nuisance for the admin, but the problem is that the 'welcome' email is generated twice, with different single-use logins that both work, and has caused confusion for at least one customer who has reported it.

As I understand it, our setup and processes are fairly unique, and perhaps the LDAP module is not the issue here. However, I've traced out the Drupal account creation process as best I can and this is as far as I've gotten. Can anyone make a suggestion as to how the duplicate welcome emails might be solved, or, even better, how to the eliminate the need to save each new account twice? I'm not sure if something in LDAP is getting in the way of Drupal's saving the data, or why it would only happen the first time, but it seems to point to the provisioning happening between the account edit form being submitted and the actual save, at which point the process is stopped.

PS: I thought there was already an issue created on this topic, but can't find it; if anyone can find that thread, I'd appreciate it.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

darvanen’s picture

Version: 7.x-2.0-beta5 » 7.x-2.0-beta8
Component: User interface » Code
Category: Support request » Bug report

I am having the exact same issue and am working to resolve it ASAP. I will report any findings here but I think this should be a bug report as the LDAP module is definitely interfering with the proper saving of user data.

Update:

  • When the ldap_user_user_update function runs into errors, the user saves correctly.
  • When the issue is occurring, in user_profile_form_submit the $result returned by user_save (if requested) has status=1, but if you immediately do user_load($account) in the same function, the status is 0.

I think the LDAP module is re-writing the old values over the newly saved account during ldap_user_user_update, but I can't figure out when or how.

Update:
I found it.
public function provisionLdapEntryIn ldapUserConf.class.php line 616 reads:
$account = user_save($account, $edit);
Commenting out this line stops the behaviour described above.
Now I/we just have to figure out how to save the ldap_user_prov_entries in a different way...

darvanen’s picture

As provisionLdapEntry() is called via functions that are set off by hook_user_update(), and hook_user_update() is called by user_save(), using user_save() in the provisionLdapEntry() function was creating and endless loop.

Replaced user_save() with field_attach_update().

jay-dee-ess’s picture

Status: Needs review » Reviewed & tested by the community

Huge patch! Looks like this fixed an issue I was having where I needed to update a user field on first time login but couldn't due to sql errors related to the second user account.

Thank you!

larowlan’s picture

Status: Reviewed & tested by the community » Needs review
larowlan’s picture

Status: Needs review » Reviewed & tested by the community
queenvictoria’s picture

Status: Reviewed & tested by the community » Fixed

Committed thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.