Keycloak Active Directory Login Fails After Sync

Sync all users can finish with a healthy import count while sign-in still fails for the same account. A successful sync proves the bind account can search Active Directory; it does not prove the user's own password works.

The goal is to determine whether AD rejected the password, blocked the account, or Keycloak is using a different username than you expect. This guide uses realm golinuxcloud, provider lab-ad, and federated user jane from the Active Directory integration walkthrough.

If Test connection fails, fix connection URL, bind DN, or truststore before you treat the problem as login-only.

Before you troubleshoot

This guide assumes:

• the lab-ad provider already connects and Sync all users works
• the affected AD user is already imported into Keycloak
• StartTLS trust is already configured on the Keycloak server
• ldapsearch commands run on the RHEL Keycloak host, not on the Windows DC or inside the container
• openldap-clients is installed on that host (sudo dnf install -y openldap-clients)
• you have the test user's current AD password for verification binds
• the Active Directory vendor preset created the MSAD User Account Mapper on lab-ad
• the jboss-logging event listener is enabled under Realm settings → Events → Event listeners if you want LOGIN_ERROR lines in podman logs (otherwise use saved events in the Admin Console when event storage is on)

Keycloak AD Users Sync but Cannot Log In: Quick Fix

Work through these checks in order:

1. Confirm the user exists under Users with Federation link lab-ad (sync succeeded).
2. Sign in with the username format that matches Username LDAP attribute (jane when the attribute is sAMAccountName, or jane@lab.example when it is userPrincipalName).
3. Test whether AD accepts the user's credential pair with ldapsearch on the Keycloak host (not the bind account).
4. Read userAccountControl, pwdLastSet, lockoutTime, and msDS-User-Account-Control-Computed when the password is correct but login still fails.
5. Inspect Keycloak for LOGIN_ERROR (invalid_user_credentials vs user_disabled) in server logs or Events.

Why Keycloak AD Sync Works but Login Fails

User sync and password login share the same lab-ad connection settings, but they do different work:

           Sync all users (bind account)
                     ↓
        Search Users DN + import attributes
                     ↓
        Federated user appears in Keycloak
                     ↓
      User submits username + password at login
                     ↓
     Keycloak resolves username to LDAP user entry
                     ↓
   Password validated against that AD account (LDAP bind)

The login name controls which user Keycloak resolves; the password is then validated against that AD user's LDAP entry (typically using the resolved DN). A healthy Sync all users count does not validate the end-user password.

Confirm the federated user imported from Active Directory

Open realm golinuxcloud → Users and search for jane. A synced AD account shows Federation link lab-ad, plus LDAP attributes such as LDAP_ID and LDAP_ENTRY_DN.

If the user is missing, fix sync first in Keycloak AD users not syncing. This page assumes the account is already in Keycloak.

Check Bind Credentials vs the AD User Password

Do not use the LDAP bind-account password to test an end-user login. Bind credentials on lab-ad authenticate only the service account (keycloak-bind), not jane.

Point OpenLDAP clients at the DC certificate Keycloak trusts:

export LDAPTLS_CACERT=~/keycloak-ad-lab/trust/lab-dc.pem

Verify the bind account can still search for the user (enter the bind password when prompted):

ldapsearch -x -ZZ -H ldap://win-8s0k67ep5eo.lab.example:389 \
  -D "keycloak-bind@lab.example" -W \
  -b "DC=lab,DC=example" -s sub "(sAMAccountName=jane)" sAMAccountName

Sample output:

dn: CN=Jane Admin,CN=Users,DC=lab,DC=example
sAMAccountName: jane

If the bind-account search succeeds, the provider can reach and search AD; test the user's own credentials next.

Test the AD User Password with ldapsearch

Test whether AD accepts Jane's credential pair directly. Active Directory accepts UPN as a bind principal; this is a useful check even though Keycloak resolves the user entry and validates the password against that LDAP account internally.

Use the same StartTLS URL and trust file as above, and enter the password you believe is correct:

ldapsearch -x -ZZ -H ldap://win-8s0k67ep5eo.lab.example:389 \
  -D "jane@lab.example" -W \
  -b "DC=lab,DC=example" -s base "(objectclass=*)" dn

If AD returns Invalid credentials (49) with extended data 52e, it rejected that bind identity and password pair. In the lab, a deliberate wrong-password test produced:

ldap_bind: Invalid credentials (49)
	additional info: 80090308: LdapErr: DSID-0C090549, comment: AcceptSecurityContext error, data 52e, v65f4

Keycloak surfaces the same underlying failure as Invalid user credentials on the login form.

If the command completes without ldap_bind: Invalid credentials, Active Directory accepted Jane's bind credentials. The search result itself is only used to confirm that the authenticated LDAP session can perform a request. If Keycloak still fails after a successful user bind, check username format and account state before you change provider settings.

Check the Keycloak Login Error

Direct Access Grants are useful here only for reproducing a simple success or failure response. They cannot complete interactive required actions such as UPDATE_PASSWORD, so use browser login when AD requires the user to change a password.

The integration lab client ad-login-test allows the password grant as a short diagnostic only (not a production pattern). In the lab, a wrong password returned invalid_grant:

curl -s -X POST 'http://127.0.0.1:8080/realms/golinuxcloud/protocol/openid-connect/token' \
  -d 'client_id=ad-login-test' \
  -d 'grant_type=password' \
  -d 'username=jane' \
  -d 'password=NotTheRightPassword'

Sample output:

{"error":"invalid_grant","error_description":"Invalid user credentials"}

Do not assume every invalid_grant means the password itself is wrong; must-change-password and other required actions need the Account Console or another interactive flow.

To inspect LOGIN_ERROR in container output, enable the jboss-logging event listener on the realm, then tail the log:

podman logs keycloak-podman 2>&1 | tail -20

Look for error="invalid_user_credentials" when AD rejected the password.

MSAD User Account Mapper in Keycloak

When the LDAP provider uses the Active Directory vendor preset, Keycloak creates an MSAD User Account Mapper on lab-ad. That mapper reads AD-specific fields including userAccountControl and pwdLastSet and translates account state into Keycloak behavior.

Documented mapper behavior includes:

• userAccountControl 514 (ACCOUNTDISABLE) — Keycloak user Enabled off after sync
• pwdLastSet 0 — can add the UPDATE_PASSWORD required action on the user

That is why disabling Jane in AD can flip Enabled off in Keycloak even though the username still appears under Users.

Check userAccountControl, Password Expiry, and Lockout in AD

userAccountControl stores persistent account flags such as ACCOUNTDISABLE. Password expiry and effective lockout are not always visible as a simple numeric userAccountControl combination; modern AD exposes computed state in msDS-User-Account-Control-Computed (for example UF_LOCKOUT 0x10 and UF_PASSWORD_EXPIRED 0x800000).

Query the affected user with the bind account:

ldapsearch -x -ZZ -H ldap://win-8s0k67ep5eo.lab.example:389 \
  -D "keycloak-bind@lab.example" -W \
  -b "DC=lab,DC=example" -s sub "(sAMAccountName=jane)" \
  userAccountControl pwdLastSet accountExpires lockoutTime \
  msDS-User-Account-Control-Computed

Sample output (enabled lab account):

dn: CN=Jane Admin,CN=Users,DC=lab,DC=example
userAccountControl: 66048
pwdLastSet: 134365038444463158
accountExpires: 9223372036854775807
lockoutTime: 0
msDS-User-Account-Control-Computed: 0

Common userAccountControl values for login troubleshooting:

When you set userAccountControl to 514 in AD and run Sync changed users, Keycloak can show Enabled off for jane.

After the disabled state has synchronized into Keycloak, login can fail as user_disabled before password validation becomes relevant:

podman logs keycloak-podman 2>&1 | grep 'user_disabled' | tail -1

Sample output (with jboss-logging enabled):

type="LOGIN_ERROR", realmName="golinuxcloud", clientId="ad-login-test", username="jane", error="user_disabled"

Re-enable the account in AD, run Sync changed users, and confirm Enabled is on before you test the password again.

pwdLastSet, password expiry, and must-change-password

pwdLastSet tells you whether AD expects a password change:

• A large non-zero value — password was set at that time; domain policy and msDS-User-Account-Control-Computed show whether AD currently treats the password as expired.
• 0 — AD requires a password change at next logon. The MSAD User Account Mapper can translate this into an UPDATE_PASSWORD required action in Keycloak.
• accountExpires at 9223372036854775807 — no account expiry in the sample above.

LDAP extended data can include 773 when a password change is required. Fix the account in AD (reset password, clear User must change password at next logon, or satisfy policy), then retry login in the browser so required actions can complete.

A non-zero lockoutTime indicates AD recorded a lockout event. For the effective current state, inspect msDS-User-Account-Control-Computed for the lockout bit or check the account in AD administration tools—not lockoutTime alone.

Match the username format Keycloak expects

Username LDAP attribute on lab-ad decides what users type. With sAMAccountName, sign in as jane. With userPrincipalName, use jane@lab.example.

Using the wrong login format can prevent Keycloak from resolving the intended LDAP user, which often appears to the user as a generic invalid-credentials error. See Keycloak sAMAccountName vs userPrincipalName for mapper checks and login examples.

Troubleshoot Keycloak AD login after sync

Summary

When Active Directory users sync into Keycloak but cannot sign in, treat sync and login as two LDAP operations. Sync uses the bind account to search and import users; login resolves the submitted username to an AD entry and validates the password against that account. A healthy Sync all users count does not validate the end-user password.

Use ldapsearch on the Keycloak host with StartTLS and -W to separate bind failures from user failures (52e). Read userAccountControl for persistent flags such as ACCOUNTDISABLE, and pwdLastSet plus msDS-User-Account-Control-Computed for must-change-password, expiry, and lockout. The MSAD User Account Mapper maps those signals into Keycloak Enabled and required actions. With jboss-logging enabled, server logs distinguish invalid_user_credentials from user_disabled.

After login works, map groups with Map Active Directory groups to Keycloak roles. For TLS-only connection errors, see Connect Keycloak to Active Directory with LDAPS.

References

• Keycloak Server Administration Guide — LDAP user federation
• Keycloak Server Administration Guide — MSAD User Account Mapper
• Keycloak Server Administration Guide — Event listeners (jboss-logging)
• Microsoft Learn — LDAP error codes (bind error 49 / extended data)
• Microsoft Learn — userAccountControl attribute
• Microsoft Learn — msDS-User-Account-Control-Computed attribute