Troubleshooting authentik LDAP sync: missing users and groups

Why authentik LDAP source syncs miss users and groups

This page covers how to find out why users or groups are absent from authentik after an LDAP or Active Directory source sync, and it is written for the platform, identity and directory engineers who run a self-managed authentik deployment and own that sync. When an expected account or group does not appear, the cause is almost always one of four things: the directory query that selects objects, the property mapping that turns directory attributes into authentik fields, the way groups are created and matched, or the bind account that authentik uses to read the directory. Treat the sync as a pipeline with four checkpoints and test them in that order rather than changing settings at random.

Start with a version check, because it changes what you see. Since authentik 2025.12, group names must be unique in the database, and that affects groups created by source syncs. If your deployment moved to 2025.12 or later and a group that existed before is now missing, duplicated or attached to the wrong members, check for two directory groups that share a name, including groups from different OUs or from a second source. Confirm your running version against the authentik 2025.12 release notes before assuming a directory-side fault.

Once the version question is settled, work through the sync task and its logs first, since they show which objects were read and which were rejected. The authentik LDAP troubleshooting guide is the reference for the specific messages and checks, so use it as your next read while you collect the sync logs. Keep one question in mind throughout: is the object never returned by the query, returned but failing a mapping, or created but not linked to the group you expect? Each answer points to a different owner, whether that is the directory team for the bind account and OU scope or your own team for mappings and group handling.

How to triage a missing user or group, in order

This sequence moves from the sync run itself to the source configuration, so you find out whether a user or group is missing because a sync never ran, failed on one object, or never matched the search.

Confirm the sync task ran and its result
Open the LDAP source in the authentik admin interface and check its most recent sync runs for each sync type, including users, groups and membership. Note the status, the start and end times, and whether the run finished or stopped early. A healthy result is a completed run with a recent timestamp and no fatal error. If no run appears, the schedule or the source itself is the problem, so fix that before reading any mappings.
Read the sync task logs for the failing object
Search the sync task logs for the distinguished name, the username or the group name of the missing object. Authentik's LDAP troubleshooting guide describes where these messages appear and which entries indicate a skipped object. A healthy log shows the object was read, mapped and created or updated. If the object appears with an error, the message usually names the cause, such as a mapping failure or a duplicate name, and tells you which step to check next.
Verify the base DN and filter cover the object
Compare the object's distinguished name with the source's base DN and the user or group object filter. The object must sit under the base DN, and the filter must match its object class and attributes. Use a directory query tool with the same service account to run the filter and confirm the object is returned. A healthy check returns the object with the attributes authentik expects. If the query returns nothing, the search scope is the cause, not authentik.
Confirm the service account can read the object
Check the bind account used by the source. It needs read access to the container holding the object and to the attributes you map, including group membership attributes. Confirm this with a directory tool run as that account, not as an administrator. A healthy result is the same query returning the object and its attributes under the service account. Missing attributes that appear only for administrators point to a permissions gap in the directory.
Check property mappings for the user
Review the user property mappings attached to the source and confirm that required fields such as username, email and name resolve from the directory attributes. A mapping that references a missing or empty attribute can stop the user from being created. A healthy check shows each mapped attribute populated on a test object, and the sync log shows no mapping exception for it. Fix the expression or the attribute in the directory, then rerun the sync.
Check group handling, duplicate names and nesting
For a missing group or missing membership, check whether the group already exists under the same name, since group names must be unique in the database from authentik 2025.12. Also confirm how nested groups are handled and whether the membership attribute is read on the group or the user object. A healthy result is a group created once, with the expected members listed after the sync. Rename or merge the conflicting group, then rerun the group sync and verify membership in the admin interface.

Five causes behind most missing LDAP objects

When an authentik LDAP source skips users or groups, the cause is usually in how the sync reads the directory rather than in authentik itself. The five causes below cover the search scope, attribute mapping, group naming, group nesting and bind permissions, and each has a first check you can run before changing anything.

Wrong search base or filter

The source only reads objects under its base DN and matching its user and group filters. An object in an OU outside the base, or one whose object class does not match the filter, never reaches authentik. Compare the base DN and filters on the source against where the missing account actually sits, and confirm the object appears in a directory query run with the same bind account. Check the sync task log for the number of objects it fetched, since a low count points here first.

Property mapping errors

Property mappings translate directory attributes into authentik user and group fields. If a mapping expects an attribute that a given object lacks, or it raises an error on one value, that object can be skipped or created incomplete. Review the sync task logs for mapping exceptions, then check that the attributes your mappings read are populated on the missing objects. Testing the mapping against a single known-good and a single failing object usually isolates the fault quickly.

Duplicate group names after the uniqueness rule

Since authentik 2025.12, group names must be unique in the database, and this affects groups created by source syncs. If two directory groups from different containers or sources share a name, the second can fail to sync or collide with an existing group. Search the authentik group list for the name of the missing group, look for an existing group created by another source or by hand, and decide whether to rename, merge or scope the groups before rerunning the sync.

Nested group membership not expanded

Active Directory often grants access through groups nested inside other groups, so a user can be a member through a chain of groups rather than a direct link. A sync that reads only direct membership will show the user as missing from the group that matters. Confirm the user's effective membership in a directory tool that expands nesting, then check how your source and mappings handle group membership so the expected group assignments appear in authentik.

Bind account lacking read permission

The service account authentik uses to bind needs read access to every container and group the source must read. An account that can see some OUs but not others will return partial results with no obvious error. Test the bind account with an ordinary directory query against the missing OU or group, and ask your directory team to confirm it has read rights on the relevant containers, including any delegated or restricted OUs.

How the 2025.12 unique group name rule breaks syncs

Since authentik 2025.12, group names must be unique in the database, and that rule applies to groups created by LDAP source syncs as well as groups created by hand. Before the upgrade, a directory group called Finance-Users could sit alongside a local authentik group with the same name, because the two were separate records. After the upgrade, the sync cannot create a second group with that name, so it either fails for that group or skips it, depending on how the sync task handles the conflict. The effect is easy to miss: the sync task may report partial progress while members of the affected group lose access to applications that depend on it. Confirm the exact behavior on your version in the authentik 2025.12 release notes before you plan the upgrade window.

Find collisions before the upgrade rather than after it. Export the group list from the authentik admin interface and compare it with the group names the source returns, including groups pulled from nested membership paths. Check the sync task logs from the most recent runs for conflict or duplicate messages. Pay particular attention to short names such as Admins, IT or Helpdesk, which are common in both a directory and an authentik instance. Because the rule is enforced in the database, a sync run in a test copy of your instance is the most reliable check. Ask the reader's own team to record each collision, its owner and the applications that depend on it.

Each collision needs one of three fixes, and the choice should be made per group. Renaming the group in the directory is the cleanest option when the directory is the system of record and the local group is a leftover. Renaming the local authentik group is faster, but it changes the name that applications and policies may reference, so review those bindings first. Aligning the two, by merging the local group into the synced group and moving its memberships and application assignments, suits cases where both groups serve the same purpose. Whichever path you choose, rehearse it on a copy, record the decision, and rerun the sync to confirm that every expected member appears in the intended group.

Which sync settings fit which directory layout

Active Directory Domain Services stores users, computers and groups in one domain and replicates that data to every domain controller, so a single domain often holds everything an authentik source needs. The same tree also contains service accounts, disabled users, computer objects and groups that no application should see. Scope therefore depends on the base DN and filters together, and nested groups add a second question about how membership is resolved.

Base DN at the domain root: This gives the widest reach and catches every OU, but it also pulls in computer and service objects unless your filters exclude them. Confirm which object classes pass the filters before the first full sync.
User filter: Limit the user filter to person objects and exclude disabled accounts so that offboarded staff do not appear as active users.
Nested group membership: Test a user who belongs to a group only through another group. If your version does not resolve that path, access rules built on group names will miss this user.
Property mappings: Map the logon name, mail and display name explicitly. A mapping that reads an attribute the account does not populate fails for that user, so review the sync log for mapping errors after each run.
Broad versus narrow scope: A wide scope reduces the chance of forgetting an OU but increases the number of groups and objects to govern. A narrow scope keeps the source tidy but needs an update whenever the directory structure changes.

Before go-live, compare a sample of users and nested groups in the directory with what authentik shows after one sync.

Sync problems mapped to the log evidence and the fix

This table pairs each common LDAP source sync symptom with its likely cause, the evidence to check first, and the direction of the fix. Read it from left to right, and confirm exact log messages against the authentik LDAP synchronization troubleshooting guide before changing configuration.

Symptom	Likely cause	Evidence to check	Fix direction
Users missing after sync	User filter or base DN excludes the accounts, or the sync task did not run	Sync task status and worker logs for the source; the search base and filter used in the source configuration	Correct the base DN and object filter, then rerun the sync and confirm the user count changes
Group memberships missing	Membership attribute is not mapped, or members are referenced by a DN the mapping does not resolve	Group sync entries in logs; the membership attribute configured on the source	Map the membership attribute the directory actually uses, then resync and spot-check one user
Nested groups not expanded	Nested group resolution is not configured for the directory layout, or the service account cannot read the nested objects	Logs showing groups synced without their child members; group objects found through the base DN	Enable nested group handling for the source if supported, and confirm the nested groups fall inside the search scope
Property mapping exceptions	A mapping expression references an attribute that is empty, multi-valued or absent for some objects	Exception traces in worker logs naming the mapping and the failing object	Guard expressions against missing attributes, handle multi-valued fields explicitly, then retest on a sample object
Duplicate group name errors	Two directory groups, or a group and an existing local group, share a name that must now be unique	Error text referencing a group name conflict in sync logs; authentik 2025.12 release notes on unique group names	Rename or consolidate the conflicting groups in the directory or in authentik, then resync
Permission denied on search	The bind account lacks read rights on the OU, groups or attributes being queried	Bind or search failure entries in logs; the bind DN and the OU where the user objects sit	Grant the service account read access to the required containers and attributes, then verify with a test search

Handling nested groups and membership in Active Directory

A direct membership check misses inherited access when the group that grants an application contains other groups instead of the user. In Active Directory, a user's account is listed as a member of the group they join directly, while a parent group lists its child groups. A user who belongs to a child group only appears as a member of the parent when something expands the nesting. Ask your directory team to confirm which membership attribute your LDAP source reads for groups (commonly member on the group and memberOf on the user), and whether the group filter in authentik expands nested groups or returns only direct members in your domain.

Confirm the behavior with one test user who should receive access only through a nested group. Run the source sync, then check the user's groups in authentik against the group chain you see in Active Directory's own tools. Review the sync task logs for the group and membership steps, and look for skipped groups or membership warnings. Also confirm that the bind account can read the user and group objects in every organizational unit that holds nested groups, since a read gap looks like missing membership. Microsoft's AD DS overview describes how directory data replicates to every domain controller and how it is indexed, which helps explain why the search base and the domain controller the source connects to both matter.

Change the group model only after the test shows the source cannot expand the nesting in your setup. One option is to adjust the source's group query so it returns the effective membership your applications need. Another is to create direct-membership groups in Active Directory for each application's access, which keeps the sync simple but adds ongoing work for the directory team whenever membership changes. Record the decision with its owner, because either path changes who maintains access. Use the troubleshooting guide for LDAP synchronization to confirm the source settings before you edit the directory design.

Service account permissions that cause silent gaps

Most LDAP sync gaps that look like authentik bugs come from the bind account, which reads what the directory lets it read and nothing more. The cards below cover the containers, attributes, account states and delegation settings to check before changing authentik's configuration. Confirm domain policy and Windows Server version details with your directory administrator before changing permissions.

Read access to user containers

The bind account needs read access to every OU that holds users you expect authentik to import, not only the default Users container. A user in a sub-OU that the account cannot see produces no error in authentik, the user just never appears. Compare the base DN in the source with the OUs where your users actually live, then run a limited search as the bind account against each one and confirm the expected entries come back.

Read access to group containers

Group visibility is separate from user visibility. If the bind account can read users but not the OU holding security groups, users sync while their group memberships and group-based access quietly stay empty. Run a limited query for a known group with the bind account and check that its member attribute is returned, because a group that is visible but whose members are hidden still produces an incomplete sync.

Attributes named in property mappings

Every attribute referenced in an authentik property mapping must be readable by the bind account, or the mapping evaluates to an empty value. Mail, department and custom extension attributes are the usual casualties, since directory administrators often restrict them. Compare the attribute list in your mappings with the attributes your bind account returns in a test search, and treat any missing attribute as a source of blank fields rather than a sync failure.

Disabled and locked accounts

Disabled and locked accounts behave differently from missing ones, and the answer depends on how your source filter and your policies treat the account control attributes. Decide whether disabled users should sync and be deactivated in authentik, then test one disabled and one locked account in a non-production source to confirm the state matches your intent. Do not assume the filter excludes them without checking the result.

Delegated OU permissions

Delegation granted on a parent OU does not always inherit as expected into child OUs, especially where administrators block inheritance or apply deny entries. A bind account can look correct at the top of the tree and still miss users in a restricted sub-OU. Ask the directory administrator to confirm the effective permissions on each OU in scope, and verify with a limited read query from a sub-OU where users are known to exist.

Limited test queries

Test the bind account with a narrow read query before blaming the sync. Search one OU, one known user and one known group, requesting only the attributes your mappings use, and record what comes back. Repeat the same query after any permission change. Keep the bind account's password out of shared logs and tickets, and confirm the test with the directory administrator, because the Windows Server version and domain policy can change how delegation behaves.

Securing the LDAP bind and the sync logs

The LDAP source runs with a bind account that can read the whole directory, and its sync logs record every object it touches. The cards below cover how to scope that account, protect the transport, keep credentials out of logs and tickets, and review sync changes afterward.

Scope the bind account narrowly

Create a dedicated service account for the authentik LDAP source and grant it read access only to the OUs that hold users and groups authentik needs. Avoid Domain Admins or accounts shared with other applications. When a sync misses objects, check first whether the bind account can see them, because a restricted account often explains a partial import without any error. Record which OUs the account can read so a later permission change can be traced.

Encrypt the directory connection

Point the source at LDAPS on port 636 or use StartTLS so the bind password and directory attributes do not cross the network in clear text. Confirm the domain controller certificate chain is trusted by the authentik server and worker containers, not only by your workstation, since both perform syncs. A certificate error on the worker often looks like a sync failure rather than a TLS problem, so test from inside the container network.

Keep passwords out of logs and tickets

Enter the bind password only in the authentik source configuration and rotate it on the directory side when staff with access change. When you share a failing sync in a support ticket or chat, redact the bind DN password field, any copied connection strings, and user attributes that contain personal data. Ask colleagues to avoid pasting raw container logs from the worker without review.

Review sync changes in the audit trail

Treat each change made by a source sync as an event you can check. Use the authentik audit log to see which users and groups were created, updated or deactivated, and compare those entries with the directory change record for the same window. An unexpected deactivation of many accounts after a bind account change is a signal to pause and investigate before the next sync runs.

Limit who can edit the source

Restrict the permission to change LDAP source settings, property mappings and sync schedules to a small administrator group. A changed search base or filter can silently widen or narrow what authentik imports. Log these edits in the audit trail and require a second person to review changes to the search base, bind account or mappings before they go live.

Confirm the sync log retention

Find out how long your deployment keeps sync task output and where it is forwarded, since the evidence you need after an incident may already be gone. Ask your team to confirm local retention settings and whether worker container logs are shipped to a central store. Agree on who can read these logs, because sync output can include usernames, group names and directory paths.

Questions teams ask before fixing LDAP sync themselves

How long does it usually take to fix an authentik LDAP sync problem?

Duration depends on the cause, and no supplied figure sets a standard length, so treat any single number with caution. A missing user caused by a filter or a permission gap can often be confirmed from the sync task log in one session. Duplicate group names, property mapping errors and nested group logic take longer because each fix changes what the sync writes and needs a test run against a controlled set of objects before production. The bigger drivers are the size of the directory, how many sources and property mappings are involved, whether Active Directory administrators must make changes, and how many change windows are available. Ask any provider to split the estimate into diagnosis, fix, test and cutover so you can see where the time goes.

Can our own team fix LDAP sync in authentik without a partner?

Yes, if your team has administrator access to authentik and to the directory and can read the sync logs. The authentik troubleshooting guide for LDAP sources is the starting point for checking sync tasks, logs and common causes. Most in-house efforts stall on Active Directory knowledge: nested group membership, how group objects are scoped in the search base, and which attributes a service account can read. Teams that own the directory and have time to test in a non-production copy often finish alone. A partner adds value when the sync is tied to access decisions for many applications, when the fix touches several sources, or when your staff cannot run tests without disrupting users.

What access and preparation does an LDAP sync fix need from us?

The work needs read access to the relevant directory scope, a service account that authentik uses for binding, and a clear view of how that account is permitted to read users and groups. Plan for a test organizational unit or a small set of test accounts and groups, so changes can be verified without affecting production users. Log access matters as much as directory access: you need the authentik sync task logs for each run and the directory change history for the objects in question. Confirm with your directory team whether they can provide a schema or attribute list, and whether any changes must go through their change control process. Also record which applications depend on the synced groups, since a group rename can break authorization in those applications.

Does the open source edition of authentik cover LDAP sources?

The open source edition is licensed under the MIT license for most of the code, and the LDAP provider and sources are part of that codebase outside the enterprise directory. The enterprise directory uses a separate license, so check the license file and the directory layout for the exact version you run before assuming a feature is included. The pricing page lists Enterprise features such as Microsoft Entra ID and Google Workspace integrations, mTLS client certificate authentication and enhanced audit logging, but it does not list LDAP source synchronization as an enterprise-only feature. Confirm the feature matrix for your version with authentik before you design around it, and remember that the open source edition offers community support only, while ticket-based support is part of paid subscriptions.

How is a fixed-scope LDAP sync engagement priced and scoped?

Most DeployOpen engagements are fixed-scope, meaning the scope, deliverables and timeline are agreed in writing before work starts, and a quote follows from that written scope. DeployOpen does not publish a price list, so ask for a quote tied to named deliverables such as diagnosis of sync failures, correction of property mappings and group logic, verification in a test directory and a cutover plan. Cost components usually include analysis time, change design, testing, and cutover support. Ask whether the quote covers the Active Directory side, the authentik side, or both, and whether handover documentation is included. Ongoing support or continuous checks are separate retainers, so ask whether they are recurring costs and what they would cover after the fix.

What should we prepare before calling a partner about LDAP sync?

Gather the authentik version you run, since release behavior changes between versions. For example, authentik 2025.12 made group names unique in the database, which affects groups created by source syncs, so a duplicate-name error may point to an upgrade. Export or copy the sync task logs for the failing runs, the LDAP source configuration with secrets removed, and the property mapping definitions. List the users or groups that are missing, with their distinguished names and the expected group membership. Note the directory layout, including whether group membership is nested, and which Active Directory domain controllers and forests are involved. Finally, record which applications depend on the synced groups and who must approve a test or production change.

How DeployOpen diagnoses and fixes authentik directory syncs

DeployOpen approaches LDAP source synchronization in authentik as an engagement with a written scope, so the directory, the authentik configuration and the reasons users or groups go missing are examined before anything is changed. Work is carried out in infrastructure you control, and the findings and changes are documented for your own team to run afterward.

How we scope

We confirm which directory or Active Directory domain feeds authentik and which users and groups should appear.
We review sync task logs, source settings and property mappings against the objects that are missing.
The written scope states which sync problems are covered, which systems are touched and what deliverables follow.

How we build

We test the bind account and its read permissions against the search base and the group objects in question.
We correct property mappings, group handling and nested group settings, then rerun syncs in a controlled way.
We check duplicate group names, since unique group names are required from authentik 2025.12, and document how conflicts are resolved.

How we hand over

You receive a written record of the causes found, the configuration changes made and the verification results.
Runbook steps cover where sync logs are read, how to rerun a sync and what to check after directory changes.
We walk your team through the handover so the sync can be monitored and adjusted without us.

How we support

Fixed-scope engagements are agreed in writing before work starts, with pricing set from that written scope.
Ongoing support, upgrades and continuous testing are available as a retainer for sync configurations that change often.
Ask us to confirm which authentik release your deployment runs and which upgrade steps apply before any change.