Our capacity planning team is locked out after we updated our Active Directory password policy last week. The LDAP sync job now fails with error “User locked - maximum password attempts exceeded” for about 15 planner accounts in S/4HANA 1909.
When I check SU01, these users show status “Locked by Administrator” even though no admin manually locked them. The LDAP connector log shows authentication failures, but the AD passwords are correct. I suspect the sync process is using cached credentials that don’t match the new AD policy requirements.
Has anyone dealt with LDAP sync issues after changing AD password policies? The planners can’t log in to update capacity models and we’re blocking production scheduling.
Your issue stems from three interconnected problems that need to be addressed systematically:
SU01 User Unlock Process:
First, immediately unlock the 15 affected planner accounts. In transaction SU01, select each locked user and click the “Unlock” button in the Logon Data tab. This removes the administrator lock status. However, this is just a temporary fix - if you don’t address the root causes, the users will get locked again during the next LDAP sync cycle.
AD Policy and LDAP Sync Alignment:
Your new AD password policy likely introduced requirements that broke the LDAP sync authentication flow. Common culprits include:
Minimum password length increased (e.g., from 8 to 12 characters)
Special character requirements added
Password history enforcement (preventing reuse of recent passwords)
Maximum password age reduced
The LDAP connector service account credentials are stored in SAP and authenticate against AD during each sync. If this service account’s password doesn’t comply with your new AD policy, AD rejects the authentication. After multiple failed attempts (typically 3-5 based on your AD lockout threshold), AD locks the service account. This prevents the LDAP sync from running, and SAP’s internal retry logic generates repeated failed login attempts for the synchronized users, triggering SAP’s login/fails_to_user_lock threshold.
To fix this:
In Active Directory, verify your LDAP service account (usually something like svc_sap_ldap) meets the new password policy
If not, reset the password to comply (use a strong password with required complexity)
Update the service account credentials in SAP using transaction LDAP
Navigate to Configuration > Service Account and enter the new password
Test the connection using the “Test” button before saving
LDAP Sync Configuration Optimization:
To prevent future occurrences, adjust these settings in transaction LDAP:
Set sync schedule to run during off-peak hours when failed attempts won’t impact users
Configure error handling to send alerts to administrators before lockout thresholds are reached
Review the authentication method - if you’re using simple bind, consider SASL/Kerberos which handles password changes more gracefully
Check profile parameter login/fails_to_user_lock and consider increasing it from default (typically 3) to 5 or 6 to provide more tolerance for transient authentication issues
Also coordinate with your AD team to exclude the LDAP service account from certain policy enforcements if possible, or at minimum, set up monitoring to alert before the account password expires. This proactive approach prevents the cascading lockout scenario you’re experiencing now.
This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Check your LDAP connector configuration in transaction LDAP. The service account used for synchronization might have an expired password or insufficient permissions after your AD policy change. Verify the connector can still authenticate to AD.
The ‘Locked by Administrator’ status in SU01 usually means the lock was triggered by failed login attempts reaching the threshold defined in login/fails_to_user_lock profile parameter. After your AD policy change, if the LDAP sync is trying to authenticate with old credentials, it’s triggering the SAP-side lockout mechanism. You’ll need to unlock the users in SU01 first, then fix the root cause in the LDAP connector configuration. Check if your AD policy now requires longer passwords or special characters that the LDAP service account doesn’t meet.
We experienced this exact scenario. The issue was that our AD policy change enforced password complexity that our SAP LDAP service account didn’t comply with. AD locked the service account after failed auth attempts, which cascaded to SAP locking the synchronized users. Update your LDAP service account password in AD to meet the new policy, then update it in SAP using transaction LDAP > Service Account Settings.
Tested this on S/4HANA 2021 SP03 — unlocking via SU01 Logon Data tab combined with resetting the LDAP sync service account password resolved all 15 planner lockouts immediately.
Beyond the service account password, check the LDAP sync schedule and authentication method. If you’re using simple bind authentication, consider switching to SASL with Kerberos which is more resilient to password policy changes. Also review your AD account lockout threshold - if it’s set too low (like 3 attempts), the LDAP sync retry logic might trigger lockouts before you can intervene. We increased our threshold to 5 attempts and added a 30-minute lockout duration instead of requiring admin unlock, which reduced these cascading lockout scenarios significantly.
Don’t forget to check the password policy mapping between AD and SAP. Transaction SECPOL allows you to define how SAP interprets AD password policies during LDAP sync. If there’s a mismatch, SAP might enforce stricter rules than AD, causing authentication failures even with valid AD credentials.