LDAP User: Getting notified of orphaned account that *does* exist

Does any of the functionality of this work for you:
- do you get emails of actual orphaned users
- do other users besides this one NOT get emails (that is are you testing with multiple users or just this one)

Are you using a service account to bind to the ldap server?

Hi there,

We're having the same issue. However, for us it seems to be always the most recently created user in Drupal for whom this alert is given, rather than simply being any one of the existing users.

The same answers to your questions apply. Are there any other suggestions you'd make? Perhaps a setting I've missed somewhere?

As yet I've not had a chance to do any debugging, but if I do I'll certainly feed back anything coming out of that.

Thanks

Has this issue ever been resolved? We're experiencing exactly the same issue, though it only started happening after switching to a new LDAP server. We're getting it with several users, but always the newest ones.

I believe this occurs when users are provisioned from another server. We've moved our LDAP server recently and added the new one, we've disabled the old one.

However most of the 'ldap_user_puid_sid_valus' in 'field_data_ldap_user_puid_sid' were still pointing to the old server. There were some new ones too that didn't show up in the mail. So it made me assume the issue was here.

It made the mails stop, but I'm waiting to hear from the user if login works as expected.

@Neograph734

We're having the exact same issue. We recently moved our LDAP server and it seems users are still connected to the old one in field_data_ldap_user_puid_sid.

How did you solve it?

The design is to have the puid fields represent permanent ids. That way if a username changes, the account still remains in tact and associated with content and permissions. Just don't use those fields if you can't keep the puid_sid and user puid consistent/permanent. You will lose the ability for the users ldap derived username to change, but that may not be a big deal for you.

So, either:

- use the same sid for the old and the new server, provider the user puid is consistent.

Or
- empty out those puid fields in the configuration
- set all instances of field_data_ldap_user_puid_sid to null

Hi all,

Experiencing similar issue in my implementation. A few accounts are being reported that the Drupal user no longer has corresponding LDAP Entries. Here is what I see under these users with the test utility (admin/config/people/ldap/user/test) set to On synch to Drupal user create or update using Service Account Bind:

Section - User Object Before Provisioning or Synching
->ldap_user_puid_sid, ldap_user_puid, and ldap_user_puid_property all contain data

Section - User Authmap
->empty

whereas when I test user accounts not being reported as orphaned they show:

Section - User Object Before Provisioning or Synching
->ldap_user_puid_sid, ldap_user_puid, and ldap_user_puid_property all empty

Section - User Authmap
->1 element with data(aid,uid,module, and authname)

This is the only discrepancy I see between these good/bad accounts. Everything else seems to be identical.

I am thinking maybe my setup under the User section Provisioning from LDAP to Drupal Mappings is wrong, at least with these first four entries:

server 1 ->Field: sid providing PUID
[dn]->Field: PUID
dn->Field:PUID Attribute
[dn]->Field: Most Recent DN

Under my server configuration LDAP User to Drupal User Relationship:

Persistent and Unique User ID Attribute->dn

I am running Drupal on LAMP and using winbind to pass SSO authentication against Microsoft Active Directory. If there is any other information I can provide to help resolve this issue, don't hesitate to ask.

I am not sure the role Cron plays in all this, or the settings on the first page, but under development section I do have the following turned on:

Discard and ignore user authorization data stored by ldap module in user records data before 2015-04-07 10:27:08. This is useful for implementers of development versions of the module that may have corrupt user data from the past.

---edit
Looking at the logs from my testing above and i see messages of: multiple user (list of all uids) with same puid (puid=C, ...). I am guessing a puid of "C" is not right.

Removed dn from server configuration's persistent and unique user ID Attribute, which in turn removed the first three entries listed above found under the User section Provisioning from LDAP to Drupal Mappings. Going to do some more testing see what gets reported by watchdog.

--edit 4/15/15
Still getting orphaned account emails... so yesterday under User >> Action to perform on Drupal account that no longer have a corresponding LDAP entry changed the setting to: Do not check for orphaned Drupal accounts.

I am not sure why these accounts are being reported as orphaned, so for now just turning off the check.

(At least part of) the problem ya'll are experiencing is a bug in ldap_user.cron.inc line 170 (line numbers in here apply to 7.x.-2.x-dev and 7.x-2.0-beta8) where a variable is used after its intended scope has ended. The email notification's edit URL always uses the last $uid from the loop that ended on line 109, instead of using the UID of the $account it's talking about. So the link goes the wrong place, but the rest of the account information supplied should be correct. I'm looking around to see how to submit a patch.

The issue L7eslie3 highlighted was fixed in #2885873: User orphans cron email has wrong edit urls.

It's likely that this issue a duplicate of that and thus I'm closing this issue. Please reopen if you still have this issue with dev.

I tried applying patch in this thread, patch linked in #15, and switching to 7.x-2.3 dev, and I am still seeing this problem every time cron runs.

The links in the email are fixed now, but the "following 16 Drupal users [that] no longer have corresponding LDAP Entries" do in fact have active AD accounts. The users mentioned in the orphan notification are always the most recently added LDAP-authenticated Drupal users, but the number of orphans varies.

Reopening as requested.

Hi insignis

That patch is no longer relevant in 2.x-dev.

Your comment also seems cut off regarding the users, anything else you can share on that?

Can you please have a look in your database and confirm that those 14 users have a puid set correctly and it matches your current puid attribute configuration? If that's in any way inconsistent the orphan checking will not work correctly and most bugs I've seen stemmed from that problem.

I'm not sure what happened to that comment, but I fixed it. What got left out was that the orphaned users are always the last however many (varies) AD users that I've added to Drupal. The PUID we're using is dn, and it looks to be accurate, if what you're asking for is found in users.data. If it's somewhere else in the database, let me know where to look.

Edit: I just saw the hidden fields under user > manage display. "Property specified as user's puid: dn" "Value of user's permanent unique id..." is the correct distinguished name, for the orphaned users. So everything looks right there.

Also, the data in that field is in the same format on newer users as it was on older users which aren't declared to be orphans. What other info can I provide that might help?

Okay, that's odd. The only thing that comes to mind is a side-effect with pagination but that should also produce other errors.

Since two other issues in the orphan processor popped up in the queue I will look try to build a more useful test case to try and debug this when I next have some time but it doesn't sound like it's an issue with your setup per se.

After I switched AD servers and disabled the old one, I'm also getting the "orphaned ldap users" email notification - for the last 5 users I think.

Manually changing the users ldap server name inside ldap_user_puid_sid_value within the field_data_ldap_user_puid_sid table, from the old Ldap server name to the new one fixed that.

Perhaps this would require some feature built into the LDAP module to process that automatically when switching AD servers (or allow to do it manually in Drupal instead of having to go to the database).

The 8.x branch is refactored and should now be a lot easier to read. This could serve as a backport, if needed (and also if no bugs remain there).

For the 7.x branch the readability of the code is quite bad, which is why I just committed the glaring error I thought I'd seen (which it wasn't) in the first commit and followed it up with a general refactoring just now.

@insignis: I wasn't able to reproduce your behavior, the additional field checks might resolve a corner case, though I'm doubtful they will. Could you please set your site to check on every cron run with a size larger than your list of users? And then run two runs and compare the result? I'm not sure if I'm putting too much weight on your note that this happens with newly created users and batch processing but I want to exclude that from the list of causes.

Through debugging ldap_user.cron I came to realize that the filter it's applying returns no results. Turns out querying Active Directory with dn= doesn't return anything, but using distingishedName= does, at least in my testing.

As to why not all users are reported as orphaned, I overlooked the fact that the oldest users have puid=C, rather than CN=...,DC=...; just "C", and I'm not sure how that happened, or why they can log in with domain authentication fine. Those are not reported as orphans, though. I'm also not sure why puid is being correctly fetched at user creation with puid_attr=dn, but not in cron jobs.

After changing the puid attribute on ldap_server config from dn to distinguishedName, I created a user which gets the new puid_attr and correctly does not get identified as an orphan in cron batches. Is it possible to change the puid_attr and puid on my existing users?

I'm not surprised that the sign-in still works, if we can still get a consistent result per user in that configuration. The puid is not used for authentication directly (even though maybe it should) but rather only for matching updates to records which have changed (i.e. changes in usernames).

If you need to change the puid/puid_attr on existing users you are limited to direct database updates. If you need to switch from something such as a cn to a guid which isn't just a change in the attribute name I'm afraid you'll have to write a small script to query users and update the relevant database tables. It might be easiest to just adapt some code from the cron check and update that way.

I'm closing this issue due to solutions for the last reported issues. Feel free to reopen if someone else experiences problems again but it might be best to start as separate support requests now.