Keycloak Active Directory Users Not Syncing

Test connection can succeed while Sync all users still reports 0 imported users. On Microsoft Active Directory, that usually means the bind account can reach the domain but the user search Keycloak runs does not return the accounts you expect.

Use ldapsearch on the RHEL host where Keycloak runs with the same base DN, scope, and filter to see whether Active Directory returns the user. Then adjust the lab-ad provider and sync again. This guide assumes the lab-ad provider from the Active Directory integration walkthrough already exists. If Test connection cannot reach the domain controller because of DNS, firewall, or StartTLS trust, fix that federation setup before you tune Users DN.

Keycloak AD Users Not Syncing or 0 Imported Users: Quick Fix

If Test connection succeeds but Sync all users returns 0 imported users, check these in order:

1. Users DN — does it actually contain the AD accounts you want?
2. Search scope — use Subtree when users sit under child containers or OUs below the base DN.
3. Custom user LDAP filter — temporarily clear it and sync again.
4. Import users — turn it on when you expect LDAP users to be imported into Keycloak’s local database.
5. Bind account — if LDAP returns error 49 / data 52e, fix bind credentials before you change the search base.

Use ldapsearch from the Keycloak host with the same bind DN, StartTLS trust, base DN, scope, and custom filter. If LDAP cannot return the user, Keycloak cannot import that user.

Password login and bulk sync share the same LDAP connection settings, but Sync all users only imports objects your configured search returns.

How Keycloak searches Active Directory users

Keycloak’s Active Directory preset searches from Users DN using Search scope and an optional Custom user LDAP filter. Sync all users imports directory users that search returns when Import users is enabled and mappers allow it.

        Keycloak lab-ad provider
                 |
     Users DN + Search scope
     + optional LDAP filter
                 v
        LDAP search on AD DC
                 v
   Sync all users → imported count

This guide assumes realm golinuxcloud and provider lab-ad from the integration chapter.

Diagnose Why Keycloak Imports 0 AD Users

Start with the settings that control which Active Directory objects Keycloak can see:

1. Check Users DN.
2. Check Search scope.
3. Check Custom user LDAP filter.
4. Verify the bind account with the same LDAP search from the Keycloak host.

If Test connection succeeds but Sync all users returns 0 imported users, the LDAP connection is usually fine. The next question is whether your configured search returns the users you expect.

If the search returns no matching users, Sync all users can finish with zero imported accounts even though bind and TLS succeed.

Starting point (lab)

Where to run LDAP commands

Run ldapsearch on the RHEL host where Keycloak runs, not on the domain controller and not inside the Keycloak container. Install clients if needed:

sudo dnf install -y openldap-clients

The Keycloak host must resolve win-8s0k67ep5eo.lab.example, reach port 389, and trust the DC certificate used for StartTLS (same trust as the integration guide). Set the trust file once per shell session:

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

Check Keycloak Users DN and Search Scope

Many domains keep built-in accounts under CN=Users, but application accounts often live in organizational units such as OU=Keycloak,DC=lab,DC=example. Keycloak only imports users its search can see.

The built-in AD Users container uses CN=Users, not OU=Users; custom organizational units use OU=.... Do not swap CN and OU when you copy a Users DN from documentation.

One level vs Subtree LDAP search

One level searches only objects directly below Users DN.

Subtree searches the configured Users DN and all child containers and OUs beneath it.

DC=lab,DC=example
├── CN=Users
└── OU=Keycloak
    └── kc-roleuser

If Users DN is CN=Users,DC=lab,DC=example, Keycloak never searches the sibling OU=Keycloak, even with Subtree. Subtree only walks children under CN=Users, not other branches at the domain root.

If Users DN is DC=lab,DC=example with Subtree, both CN=Users and OU=Keycloak are included.

Narrow base: CN=Users with One level

A frequent misconfiguration sets Users DN to CN=Users,DC=lab,DC=example and Search scope to One level. That finds users placed directly under CN=Users but not accounts under OU=Keycloak, which is a sibling of CN=Users at the domain root—not a child of CN=Users.

Test Users DN with ldapsearch

On the lab host, confirm with the bind account. This search uses the same base and one-level scope Keycloak would use (-W prompts for the bind password):

ldapsearch -x -ZZ -H ldap://win-8s0k67ep5eo.lab.example:389 \
  -D "keycloak-bind@lab.example" -W \
  -b "CN=Users,DC=lab,DC=example" -s one \
  "(sAMAccountName=kc-roleuser)" dn

Sample output:

# search result
search: 3
result: 0 Success

# numResponses: 1

No dn: line appears — kc-roleuser is not under CN=Users at one level. A subtree search from the domain root finds the 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=kc-roleuser)" dn

Sample output:

dn: CN=KC Role User,OU=Keycloak,DC=lab,DC=example

Fix: set Users DN to DC=lab,DC=example with Subtree, or set Users DN to OU=Keycloak,DC=lab,DC=example if all federated users live in that OU.

Check the Custom User LDAP Filter

A Custom user LDAP filter is added to Keycloak’s normal user search. If it matches no AD users, Sync all users can complete without importing the accounts you expect.

Example filter that matches no real lab user:

(&(objectClass=user)(sAMAccountName=__none__))

For troubleshooting, temporarily clear Custom user LDAP filter, save the provider, and run Sync all users again. If users appear, fix the filter before you re-enable it.

Test your custom LDAP filter with ldapsearch

Reproduce the relevant base DN, scope, and custom-filter conditions with ldapsearch. You do not need to recreate every internal Keycloak filter; the goal is to confirm that the AD search criteria you configured can return the expected account.

When you use a custom filter, include it in the command:

ldapsearch -x -ZZ -H ldap://win-8s0k67ep5eo.lab.example:389 \
  -D "keycloak-bind@lab.example" -W \
  -b "DC=lab,DC=example" -s sub \
  "(&(objectClass=user)(objectCategory=person)(sAMAccountName=kc-roleuser))" dn sAMAccountName

If ldapsearch returns the user but Keycloak still skips them, check Import users, mapper errors, and the server log.

Fix LDAP error 49 / data 52e bind failures

If the bind password or principal is wrong, LDAP returns ldap_bind: Invalid credentials (49) with Active Directory extended error data 52e. data 52e indicates that AD rejected the credentials supplied for the bind—check both the bind principal and password.

Test the same bind Keycloak uses before you spend time on Users DN:

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

If this returns Invalid credentials (49) / data 52e, correct the bind account or password in Keycloak before you troubleshoot Users DN. A successful bind returns the root DSE. In the Admin Console, fix Bind DN (DN form or user@domain UPN style), Bind credentials, and StartTLS trust, then run Test connection.

Sample bind failure:

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

Verify Active Directory user sync after the fix

1. Set Users DN, Search scope, and Custom user LDAP filter to values that ldapsearch confirms.
2. Ensure Import users is On when you expect users in Keycloak’s local database.
3. Run Test connection, then Sync all users. A healthy sync after you fix Users DN shows updated counts (not only 0 imported users, 0 updated users when accounts already exist from an earlier import).

4. Under Users, search for a known account (for example kc-roleuser) and confirm Federation link shows lab-ad.

On a realm that already imported users during integration, Sync all users often reports 0 imported users with a non-zero updated users count. That still means Keycloak refreshed LDAP-backed accounts from your corrected search base.

Troubleshoot Keycloak AD user sync

Summary

When Keycloak Active Directory sync imports no users, the bind account often reaches the domain while the configured user search does not. On AD, the usual gaps are Users DN that stops at CN=Users while accounts live in sibling OUs such as OU=Keycloak, Search scope that does not include the containers where those users are stored, and Custom user LDAP filter values that match nobody.

Use ldapsearch on the Keycloak host with the same bind DN, StartTLS trust, base DN, scope, and filter you configured. If the bind itself fails with error 49 / 52e, fix credentials before you change the search base. After Users DN and filters are correct, run Sync all users and confirm federated users under Users.

For username attribute choice after users import, see Keycloak sAMAccountName vs userPrincipalName. After accounts appear in Keycloak, map AD groups with Map Active Directory groups to Keycloak roles.

References

• Keycloak Server Administration Guide — LDAP user federation
• Microsoft Learn — LDAP error codes (bind error 49 / extended data such as 52e)
• Microsoft Learn — Active Directory naming contexts