Problem/Motivation
I’m unsure whether this is a bug or if we’ve made a configuration mistake.
The observation has shown that users are neither updated nor deactivated when their LDAP group memberships, which are specified as filters in the LDAP query, are removed.
What we aim to achieve is that users are deactivated when they no longer meet the filter criteria in the query used to create them. One use case is that users may change departments or roles within the company, which should also update their access rights or access levels for specific systems. The LDAP system should take the lead in this process. The assignment is typically managed via group memberships defined by "memberOf" attributes.
Debug Report
We have configured the LDAP module to create users in Drupal using the query. Additionally, role assignments are managed through the LDAP Authorization Provider, which grants administrative rights.
There is only one query configuration, which is used both for creating and updating users. It seems there is no way to differentiate between the two processes, which might be part of the issue.
The query uses an LDAP filter in the form of: "(|(memberOf=DRUPAL_USER)(memberOf=DRUPAL_ADMIN))"
When a user no longer belongs to any of the specified LDAP groups, the following occurs:
- The user is not deactivated by the OrphanProcessor (via cron) and retains access to Drupal.
- The user is no longer updated by the GroupUserUpdateProcessor (via cron), meaning that authorizations are also not updated.
- The user is updated but not deactivated when they log in to the system again.
The lack of role updates via cron is less critical, though it is inconvenient and causes confusion because users retain outdated role assignments in Drupal until they log in again. More concerning, however, is that users are not deactivated and can still authenticate. Depending on the configuration, content may remain associated with these users and is not updated according to the settings.
Proposed resolution
I believe the OrphanProcessor should be adjusted to apply the same filter when checking a user against LDAP as is used when creating the user.
The patch illustrates the intended functionality. However, an additional option may need to be added to the LDAP User module to make this behavior configurable.
Remaining tasks
User interface changes
API changes
Data model changes