LDAP User: Option to Cancel or Notify Admin of LDAP Provisioned Drupal Users when no longer found in LDAP

This should be an option. I'm changing this to a feature request because that functionality doesn't exist yet.

This can't be implemented on user logon, because their LDAP account would be missing. I think the best way to implement this is:

- have cron query N accounts every time it runs, where N is roughly (number of accounts) / (frequency of cron in hours * periodicity of cleaning all accounts) or 50; whichever is higher. Where periodicity is chosen by the admin.
- when cron runs, query for all of the N ldap associated users in batches with the oldest last checked time. Mark the drupal user accounts that are have corresponding ldap entries with the run date.
- either delete or disable accounts that do not have corresponding ldap entries, depending on user preferences.

So the UI would look like:

Remember: This functionality only works if a service account or anonymous bind is used to query ldap groups.
Note: These settings are applied to all LDAP associated accounts; from all ldap servers.
[x] When cron runs, disable LDAP Associated acounts that no longer have corresponding LDAP entries.
[ ] When cron runs, DELETE LDAP Associated acounts that no longer have corresponding LDAP entries.
____ Number of hours to check all accounts. This will determine how many accounts are checked every cron run. For example, if your cron runs every .5 hour, and you have 1000 accounts, and you set this number to 24 hours: 1000/(24 * .5) = 83. accounts will be checked every cron run.

And a field user.field_ldap_user_last_checked would be added to have a unix timestamp on it.

Here's the status of this issue:

The UI is done and in 7.x-2.x-dev. It just mimicks the delete drupal account options with a non action of emailing sys admin.
-------------------------------------
[Action to perform on Drupal account that no longer has a corresponding LDAP entry
O Do not check for orphaned Drupal accounts.)
O Perform no action, but email list of orphaned accounts. (All the other options will send email summaries also.)
O Disable the account and keep its content.
O Disable the account and unpublish its content.
O Delete the account and make its content belong to the Anonymous user.
O Delete the account and its content.
These actions will only occur if the query to server is successful and does not return a user entry. If the ldap server is down, all LDAP associated users will not be deleted. When initially using this option, its best to simply check email and delete the accounts by hand. When you are happy with the behavior, switch to one of the automated options.

Number of users to check each cron run. __
-------------------------------------

To do:

• the code in ldap_user/ldap_user.cron.inc _ldap_user_orphans() is partially finished and completely untested. it needs to be finished and tested.
• it needs simpletest coverage. Not sure about simpletest coverage of cron driven code. May be adequate to simply call _ldap_user_orphans() in the simpletest and avoid cron context.

Yes. There is a thread just for the status of the module. Its #1115704: Drupal 7 Status Updates.

Because fieldOrderBy method doesn't work for nulls (see #1662942: Make EntityFieldQuery::fieldOrderBy include NULL field values), this cannot be implemented in an ideal way. I'm leaving the user->ldap_user_last_checked field, but not using it in the queries. The batch will just go through in order of UID regardless of when the user was last checked and I'll have a drupal variable to keep track of the last uid checked that rolls over to uid=2.

I think only "ldap_user_orphan_email" and "user_cancel_block" should be implemented. The rest of the user_cancel options seem dangerous to automate.

• ldap_user_orphan_email (sends list of orphans to sys admin)
• user_cancel_block
• user_cancel_block_unpublish
• user_cancel_rassign
• user_cancel_delete

This is a great feature request. Thanks for the work on it.

Per the OP and replies, I used them to set everything up to handle when a user's account gets removed from LDAP. Unfortunately, I'm getting an email about an orphaned account even though it does still exist in LDAP. It says: "The following 1 Drupal users no longer have corresponding LDAP Entries. Perhaps they have been removed from the LDAP and should be removed: username,mail,edit url,jdoe,jdoe@mysite.com,http://mysite/user/321/edit"

I have the following settings under admin/config/people/ldap/user:

How to resolve LDAP conflicts with manually created Drupal accounts. > Reject manual creation of Drupal accounts that conflict with LDAP Accounts.
LDAP Servers Providing Provisioning Data > SERVERNAME IP ADDRESS Status: Enabled
Drupal Account Provisioning Events:
- Create or Synch to Drupal user on successful authentication with LDAP credentials. (Requires LDAP Authentication module).: CHECKED
- Create or Synch to Drupal user anytime a Drupal user account is created or updated. Requires a server with binding method of "Service Account Bind" or "Anonymous Bind".: CHECKED
Existing Drupal User Account Conflict > Associate Drupal account with the LDAP entry. This option is useful for creating accounts and assigning roles before an LDAP user authenticates.
Application of Drupal Account settings to LDAP Authenticated Users > Account creation settings at /admin/config/people/accounts/settings do not affect "LDAP Associated" Drupal accounts.
Action to perform on Drupal account that no longer have a corresponding LDAP entry > Perform no action, but email list of orphaned accounts. (All the other options will send email summaries also.)

For some reason, even with this feature change, this module cannot find this account for me even when LDAP account does exists. I looked in Active Directory, and that user's account does in fact still exist. I also double-checked that with our Network Administrator.

Is there a setting that I'm missing or something that I can check using this feature?

I will issue a separate issue report for this. Thanks.

generalized feature summary.

No patch, so updating status

The orphan user processor is available. Please open new issues if there is something broken or missing in it.