Contrib.social

LDAP User: The OrphanProcessor deactivates/deletes users if the connection to LDAP fails

Open on Drupal.org →
Created on 11 March 2022, almost 3 years ago
Updated 4 October 2023, about 1 year ago

Problem/Motivation

We use the LDAP connection to generate and update Drupal user accounts. For users, who were kicked out of the LDAP server, the module provides a cron job to remove the orphaned Drupal accounts.
The cron job runs even if the connection to the LDAP server fails. Depending on the setting for the "Periodic orphaned accounts update mechanism" under LDAP User Settings, this might result in all user accounts with an LDAP connection being blocked or deleted.

Steps to reproduce

The setup should be quite common. I tested against a standard Drupal 9.3.7 and LDAP-Module 4.3.0. All submodules, except LDAP Authorization Provider, are active. There is 1 server and 1 query configured. LDAP accounts are synchronized from LDAP to Drupal but not back to LDAP. Obviously, the orphan processor is on and, in that case, set to "Delete the account and make its content belong to the Anonymous user.". After the configuration is set up correctly:

  1. Run cron to synchronize the accounts.
  2. Mess up the server connection to force a connection failure. Removing credentials works. Something on LDAP side should work too. The Server Configuration itself needs to stay active though.
  3. Run cron again.
  4. Check if the accounts are still existent and active or if the are blocked/deleted.

Proposed resolution

I'm afraid this can't be solved with "just configure your connection correctly". The connection to LDAP might fail unexpectedly due to some network failure or the bind account for the server getting blocked for example.
I propose to check the connection as soon as possible in the process and abort on failure: log the issue but don't change any account.
Doing that directly in the cron hook might be too early, since each user validation triggers another communication with LDAP and each of these might fail. The current check in
/ldap_servers/src/LdapBaseManager.php::searchAllBaseDns() runs too late since the function is meant to return an array. That array will be empty for "user not found" as well as "connection failed".
I applied a patch in /ldap_user/src/Processor/OrphanProcessor.php::ldapQueryEligibleUser() right after the check if the server (Drupal LDAP configuration) is enabled. However that required injecting another service which might be a bit heavy.

Remaining tasks

check proposed sollution

User interface changes

none

API changes

hopefully none

Data model changes

none

🐛 Bug report
Status

Fixed

Version

4.3

Component

Code

Created by

lars.stiebenz

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024