When we disable an account the profile and table under people shows that the user is blocked, however the user table in the database is still showing a 1 instead of 0, and any views created will show blocked users when you are just looking for active.

CommentFileSizeAuthor
#2 fix_filter_blocked_users.patch1.93 KB309saurabhd
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

John Franklin’s picture

AIUI, when AD disables a user, it moves the account to a different OU where Simple LDAP cannot find it. In Simple LDAP's world, the user doesn't exist in LDAP anymore, which means there is no password for them, no way for them to ever log in, so during user_load() they are marked as "blocked" in the user object. This status is never written to the database because they were not explicitly blocked in Drupal, they're just missing from LDAP. If they come back, they should be automatically set to their last status in the Drupal DB, active or blocked. Think of what Simple LDAP is doing as "soft blocking" the user.

Because the user is still listed as "active" (status = 1) in the database, Views (which knows nothing of LDAP) includes "WHERE status=1" to its query and the user is included in the result set. During user_load(), Simple LDAP soft blocks them, and the list shows a status of Blocked, even if you've filtered for active-only.

Should blocked in AD always map to blocked in Drupal? Are there times when a user should be blocked in Drupal but remain active in AD?

309saurabhd’s picture

The status can be changed to 0 for blocked users and back to 1 for unblocked users, everytime ldap is synced with drupal. This will help in consistency.
Patch is provided below.