TYPO3 backend password lifetime not enforced for LDAP-authenticated users

Answer first

Yes. In TYPO3 v12 LTS the password lifetime enforcement is intentionally scoped to TYPO3's own internal authentication service for backend users. It does not apply to users authenticated by an external service such as LDAP. LDAP-authenticated backend users will never be forced to change their password in the TYPO3 backend by the TYPO3 setting, because TYPO3 never validates the password itself.

Enforcement for externally authenticated accounts must live in the directory. Defense in depth is: TYPO3 lifetime for internal accounts, directory password policy for LDAP accounts.

Confirmed facts vs likely explanation

Confirmed: TYPO3 evaluates password age via fields on the be_users record and the internal auth service. The backend equivalent of the setting you referenced is [BE][loginSecurity][passwordLifetime] in TYPO3 v12. When the internal service authenticates, TYPO3 checks the user's last password change timestamp and redirects to the forced change form.

Likely explanation for your gap: The auth service chain runs in priority order and stops at the first service that successfully authenticates. An LDAP backend auth service authenticates the bind against the directory and returns success. The internal service, and therefore the TYPO3-side expiry check, is never reached for those accounts. TYPO3 cannot rotate a password it does not store.

1. Is the setting scoped to internal auth only?

Yes by design. External auth services replace or precede the internal service. Password lifetime is a TYPO3-side property, not a directory property.

2. Can LDAP sync overwrite expiration fields?

Yes. A sync extension that updates be_users on each login or scheduled run can overwrite or ignore the password/last-change fields. If it maps a directory attribute to password or pwd_change / password_change fields, expiry can be silently reset.

Verify this for your installation:

1. Pick a test LDAP-synced backend user.
2. Read the current values before sync:

SELECT uid, username, password_change, tstamp FROM be_users WHERE username = 'testldap';

3. Manually set password_change to an old date to simulate expiry.
4. Trigger the LDAP sync you use, then re-query the same row. If password_change or password changed back, your sync mapping overwrites TYPO3 fields.

3. Confirm LDAP policy governs TYPO3 logins

1. Identify the auth service priority. In TYPO3 v12 the backend auth services are configured via the LDAP extension. Confirm the LDAP service has higher priority than the internal DatabaseBackendUserAuthentication service.
2. Create a test directory account with a short max password age, e.g. 1 day, or use an existing account that is already expired.
3. Attempt a TYPO3 backend login with that account. A directory-enforced expiry will surface as a bind failure in TYPO3, typically a generic "Invalid username or password" rather than a TYPO3 password-change prompt.
4. Check TYPO3 logs and the LDAP extension debug log for the bind result. Successful login means the policy is not applied to the bind DN TYPO3 uses; failed login confirms directory enforcement.

Note: a directory expired password fails the bind. TYPO3 will not show its own password-change form. Users must change passwords via a directory-aware tool.

One diagnostic detail that changes the recommendation: which LDAP extension and auth service configuration are you using, e.g. TYPO3\CMS\Core\Authentication\AuthService priority and whether fallback to internal auth is enabled? The exact sync mapping and priority determine whether the internal service could ever run for LDAP users.