Drupal Core Password Expiration and LDAP Authentication Interoperability

Answer

Drupal core does evaluate password expiration for accounts authenticated via LDAP or OAuth, but only if the external authentication module does not explicitly bypass the check. The core ‘user.reset password’ permission allows resetting any user’s password; there is no separate permission that lets a user reset only their own password without also being able to reset others. However, any user can change their own password using the ‘edit own account’ permission, which does not affect other accounts. The expired‑credential state is stored solely in the Drupal users table and is not shared with external auth sources; unless the LDAP/OAuth module writes to the password field (e.g., via LDAP Password Sync), the expiration timestamp remains independent of the external login.

Confirmed Facts

• Password expiration check runs after the user object is loaded during authentication, before login is finalized, and reads the stored password timestamp from the users table.
• Most contrib LDAP and OAuth modules load/sync the Drupal user account but do not update the password expiration timestamp, so core will still enforce a reset on expired passwords unless the module explicitly bypasses the check.
• The ‘user.reset password’ permission grants the ability to reset any user’s password; there is no granular permission to reset only one’s own password.
• Users can always change their own password via the ‘edit own account’ permission, which does not affect other accounts.
• Expired‑credential state (password hash, login timestamp, etc.) is stored exclusively in the Drupal users table; external providers that do not write to the password field cannot modify this state.

Likely Explanation

When LDAP or OAuth authentication succeeds, the module typically creates or updates a Drupal user object but leaves the pass and login fields unchanged. Consequently, the core expiration logic sees the same timestamp as before and may force a password reset. If the module implements a bypass (e.g., unsets $user->needs_password_reset or calls user_login_finalize() with a flag), the expiration check is skipped.

Steps to Verify (for your environment)

1. Enable core password expiration (Admin → Configuration → People → Account settings) with a short lifetime.
2. Create an LDAP user account, let the password expire in LDAP (or wait for the Drupal timestamp to age).
3. Attempt to log in via LDAP and observe whether Drupal redirects to the password reset page.
4. Assign a test role only the edit own account permission (no user.reset password). Log in as a user with that role and confirm they can change their own password via the account edit form but cannot access the password reset admin page for other users.
5. Inspect the users table (pass and login columns) before and after an LDAP login; if the timestamps remain unchanged, the external provider is not updating the expiration state.

Missing Diagnostic Detail

Whether LDAP Password Sync (or a similar feature that writes LDAP password changes into Drupal’s pass field) is enabled changes the outcome: if sync is active, password changes in LDAP will update Drupal’s expiration timestamp, potentially clearing the expired state. Please confirm if LDAP Password Sync is configured in your LDAP authentication module.