How authentik connects to Active Directory for user and group sync
authentik reads users and groups from Active Directory through an LDAP source, and that makes the connection a read path into authentik. Active Directory stays the system where accounts are created, changed and disabled, and authentik mirrors those objects so it can authenticate people against them. This page covers the prerequisites, the source setup, attribute and group mapping, the security choices around the bind account and transport, and the tests to run before users sign in. Treat the LDAP source as the only supported method on this page for pulling identities out of Active Directory.
Before you configure anything, decide which directory objects authentik should see. The LDAP source takes a base distinguished name, user and group search filters, and a bind account that authentik uses to query the directory. Create a dedicated, least-privileged service account for that bind instead of reusing an administrator or a person's account, and confirm with your directory team that it can read the user and group attributes you plan to map but cannot write to them. Ask them to confirm which organizational units hold application users, because a base DN set too high will pull in service identities, disabled accounts and computer objects you did not intend to sign in. Also confirm how nested group membership is resolved in your forest, since the source's group handling depends on it.
Plan the transport and the write-back question before the first sync. Plain LDAP sends bind credentials and directory data without encryption, so use LDAPS or StartTLS and confirm that the certificate chain authentik trusts is the one your domain controllers present. Password write-back, where a password change made in authentik must reach Active Directory, requires an encrypted connection, so treat LDAPS as a prerequisite if you need that behavior. Check the Windows Server 2025 LDAP signing default with your domain administrators, since unsigned binds may fail after that default applies. Verify these settings in your own forest and against the authentik LDAP source documentation for the release you run, and test with a non-production user first.
What you need in place before you create the LDAP source
An LDAP source only works when the release line, the deployment, the directory account and the network path are settled first. The cards below cover each prerequisite in the order a platform team usually checks them, along with the edition question to settle before purchase.
Confirm the authentik release line
Run a release line the project still supports. The security policy lists 2026.5.x and 2026.8.x as the versions receiving security fixes, and security releases are announced at least 24 hours in advance. Check the policy on the day you build, because the supported list changes over time. Record the exact version you deploy, since the LDAP source settings and sync behavior are tied to it. Plan your change window around that advance notice so a security patch does not land in the middle of a directory cutover.
Choose and size the deployment
Decide between Docker Compose and Kubernetes with Helm before you create the source. Compose suits test setups and small-scale production, and its guide calls for at least 2 CPU cores and 2 GB of RAM. The Kubernetes guide recommends a separately managed PostgreSQL for production, not the bundled one. The LDAP sync runs as background work on the worker container, so confirm the worker is running and can reach PostgreSQL before you start a first sync.
Create a read-only directory service account
Create a dedicated service account in the domain that authentik uses only to bind and read. Grant read access to the user and group objects inside the search base you plan to sync, and avoid Domain Admin or broad write rights. Keep the password in your secrets store and set a rotation process with a named owner. Test the bind with an LDAP client from the authentik host before you enter it in the source, because a bind failure and a filter failure look similar in the UI.
Open LDAP or LDAPS paths from the worker
The network path that matters is from the authentik worker container to the domain controllers, not from your browser. Open TCP 389 for plain LDAP or TCP 636 for LDAPS, and confirm the route through any firewall, host network policy or Kubernetes network policy. Name more than one domain controller where your design allows it, so a single controller outage does not stop syncs. Test from inside the worker's network namespace, since a host can reach a controller while the container cannot.
Prepare a trusted certificate chain for LDAPS
If you plan to use LDAPS, the domain controllers must present a certificate that chains to a root or intermediate authority that the authentik runtime trusts. Export the chain from your PKI, add it to the container trust store or mount it as your deployment expects, and confirm the hostname on the certificate matches the name you enter in the source. A self-signed or private-CA certificate that is not in the trust store causes TLS errors that look like connection failures. LDAPS is also the transport you will need later for password write-back, so settle it now.
Confirm the edition before purchase
The pricing page lists Enterprise-only features including the Microsoft Entra ID and Google Workspace integrations, along with mTLS, privileged access management and enhanced audit logging. The page does not name the LDAP source in that list, so confirm with authentik whether the LDAP source is included in the Open Source edition or requires Enterprise. Ask for the written edition-to-feature mapping, and check the LICENSE terms for the directory tree you plan to run, since code under the enterprise directory uses a separate license.
Configuration sequence for the Active Directory LDAP source
This sequence takes an Active Directory forest from a dedicated read-only bind account to an enabled authentik LDAP source, with a check at each stage so that sync errors surface before the full directory is in scope.
Agree a test OU and scope
Before any configuration, the directory owner and the authentik owner agree on a test organizational unit containing a small set of user and group objects, plus the list of OUs that will eventually be in scope. Start with the test OU only, so that a misconfigured filter or search base cannot pull in service accounts, disabled users or the wider directory. Done means both owners have signed off the test OU distinguished name and the expected user and group counts for it in writing.
Create a read-only bind service account
A directory administrator creates a dedicated service account in the domain and grants it read access to the search base only, not domain administrator or account operator rights. Set a long, non-expiring password held in your secrets store, and record which OUs the account can read. Done when a test bind from a host that can reach the domain controllers succeeds with that account, and a query for an object outside the search base returns nothing.
Create the LDAP source in authentik
An authentik administrator creates an LDAP source in the admin interface, entering the domain controller address, the base DN for the test OU, the bind account distinguished name and its password, and the user and group search filters. Confirm which connection type you are using, since LDAPS is needed later for password write-back. Done when the source saves without a connection error and the test connection option reports a successful bind.
Run the first sync from the source page
From the LDAP source page, the administrator triggers a sync and watches the task status until it finishes. Check the worker logs for mapping errors or skipped objects, because the worker container runs background sync tasks. Done when the sync task reports completion and the user and group counts shown in authentik are visible on the source page.
Compare counts and sample memberships with Active Directory
The directory owner exports or counts the user and group objects in the test OU using Active Directory tools, and the authentik owner compares those numbers with the counts from the sync. Pick several users, including one with nested group membership and one disabled account, and confirm their group memberships match in both systems. Done when counts match and the sampled memberships agree, with any gap traced to a filter or to a nested group that did not resolve.
Confirm computer account and service account filtering
Check that computer accounts and the service accounts created in step two are not imported as login users. If they appear, tighten the user filter so that only person objects in the intended groups match, then rerun the sync. Done when a query of the imported users returns only the test population and no computer or service identities.
Test a sign-in before enabling the source for login
Sign in with one test user from the synced population using a non-production application or the authentik login flow, and confirm the account maps to the expected name, email and groups. Only after this succeeds, enable the source for login and then widen the search base in controlled steps, repeating the count comparison after each change. Done when the test user signs in successfully and the wider scope has been verified against the same counts.
How Active Directory attributes map to authentik users and groups
This table compares common Active Directory attributes with the authentik user field, group name or identifier each one feeds, and the failure that follows if the attribute changes. Read each row as a starting point: the default mapping depends on your authentik release and your directory schema, so confirm each attribute name before you run the first sync.
| Active Directory attribute | What authentik uses it for | What breaks if it changes |
|---|---|---|
| sAMAccountName | Default username for the synced user, typically the value users type at login through LDAP-based flows | Login names change, existing local accounts may not match, and LDAP bind or search filters built on it stop finding users |
| userPrincipalName | Alternative login identifier when users sign in with a UPN format, and a common choice for a unique user identity across domains | Users created under the old UPN are treated as new accounts, and sessions or application mappings keyed to the old value lose their link |
| Email address field on the authentik user, used for notifications, recovery flows and matching to applications that expect email | Email-based matching and recovery stop working, and applications that key accounts on email may create duplicates | |
| displayName | Display name shown in the authentik interface and passed to applications that read the name claim | Display changes are cosmetic, but applications that copy the name at first login may keep the old value |
| memberOf | Source of group membership, which authentik maps to groups; nested membership depends on how the group lookup is configured | Users lose group membership, access granted through application bindings is removed on the next sync, and nested groups may not be expanded |
| userAccountControl | Used in filters to separate enabled accounts from disabled ones and to exclude computer objects from user sync | Disabled users may sync as active, or computer accounts may appear as users if the filter no longer applies |
| objectGUID | Stable unique identifier for the source object, used so authentik can recognize the same account across renames and moves | If the source identifier is changed to a mutable attribute such as a username, renamed users are duplicated and old accounts are orphaned |
| cn or distinguishedName | Group names and location in the directory tree, used when the source object is found by its DN | Moving an object to another OU changes its DN, which can break group mapping or source filters that rely on the path |
How nested groups and computer accounts change what authentik imports
The first decision for this section is whether authentik should resolve nested group membership when it reads from Active Directory. In an LDAP source, group membership is only as complete as the query that gathers it. If authentik reads each group's direct member attribute and stops there, a user who belongs to a group that is itself a member of another group will not inherit the outer group's access. That user may still sign in, but the application entitlement or group-based policy you attached to the outer group will not apply to them. Confirm in the authentik LDAP source settings how group membership is resolved, then test it against a real user. Do not assume that a group nested in a group produces the access your directory design implies, because Active Directory administrators often rely on nesting to model roles.
Computer accounts are the second import risk. In Active Directory, each joined workstation and server has an account that carries the computer objectClass, and these accounts sit in the same directory tree as users. A user search filter that matches on person or user alone may still be too broad if your domain uses objects that combine classes, so the safer approach is to filter explicitly for user objects and exclude computer objects in the user search. A broad filter can import machines as users, creating accounts that look valid in authentik but have no real owner. Those accounts can then receive group membership, appear in application assignments and clutter audit records. The exact filter syntax depends on how your domain is built, so confirm it against your own object classes before you rely on it.
Before you schedule the full sync, run a short test with one known nested group and one known workstation. Choose a group whose access depends on nesting, add a test user as a member of the inner group, and check that the user appears with the expected group membership in authentik. Then confirm that the workstation's computer account does not appear among imported users. Record the result for each check and keep the test scope small, so you can roll back any incorrect accounts without affecting production users. If either check fails, adjust the filter or group resolution and repeat the test. Only after both pass should you schedule the full sync, because accounts imported in error are harder to trace once users have signed in or been assigned to applications.
Read-only sync or password write-back through LDAPS
In a read-only design, authentik's LDAP source reads users, groups and attributes from Active Directory, and passwords stay managed in Active Directory. Users sign in to authentik with their directory password, which authentik verifies by binding against the domain. Password changes, resets and lockouts are handled by Windows, so the directory password policy applies unchanged. This keeps the write path out of authentik and is usually the simpler option to justify to a security team.
- Service account rights: The bind account needs read access to the user and group objects in the synchronized search base. It does not need permission to reset or change passwords.
- LDAPS: Read-only sync can run over plain LDAP on the same network segment, but the bind carries a password, so most organizations use LDAPS or StartTLS with a certificate the authentik server trusts.
- Password policy and lockouts: Failed sign-in attempts through authentik count against the Active Directory account lockout threshold, so a misconfigured bind can lock real users out.
- Testing: Confirm that a disabled account cannot sign in, that group membership changes appear after the next sync, and that a bad password increments the lockout counter as expected.
Before enabling any binding setting, confirm the current LDAP signing and channel binding defaults on your domain controllers against Microsoft's documentation, including the default that applies to Windows Server 2025.
Password write-back lets authentik set or change the password of a directory account, for example when a user enrolls or resets a password in authentik. Active Directory only accepts password attribute changes over a secure channel, so this option depends on LDAPS and a certificate the domain controllers and authentik both trust. The write path also expands the blast radius of the service account, so it needs a narrower and more carefully audited design.
- Service account rights: Grant the account permission to reset passwords only on the target OUs, not domain-wide. Avoid membership in privileged groups such as Domain Admins.
- LDAPS and certificates: Install a certificate from your enterprise certification authority on the domain controllers, and verify that the authentik container trusts the issuing CA chain. Expired or self-signed certificates cause failures that look like wrong passwords.
- Password policy and lockouts: Writes must satisfy the domain password complexity, history and minimum age rules. Reject messages from authentik will not always explain which rule failed, so review domain policy first.
- Testing: Test on a non-production domain or a dedicated test OU. Cover new enrollment, self-service change, administrator reset and a password that violates policy, and check the domain controller event logs for each.
Before enabling write-back, confirm the current LDAP signing and channel binding defaults on your domain controllers against Microsoft's documentation, including the Windows Server 2025 default, because a change in those settings can break writes that worked before.
Both options depend on how the domain controllers handle signed and encrypted LDAP traffic, so the certificate and signing checks are a prerequisite for either tab rather than an optional hardening step. Treat them as a gate that must pass in a test environment before the sync source is pointed at production domain controllers. The checks confirm what the directory will accept, not what authentik assumes it will accept.
- Certificate chain: Verify that the LDAPS certificate has the domain controller name in its subject or subject alternative name, is within its validity period, and chains to a CA that the authentik server trusts.
- Signing and channel binding: Record the current LDAP server signing requirement and LDAP channel binding settings on each domain controller, and compare them with Microsoft's documentation for your Windows Server version.
- Connectivity: Test the LDAPS port from the authentik server and worker containers, not only from an administrator workstation, because container networks and firewall rules often differ.
- Change control: Document the signing and binding values before and after any change, so a later tightening does not silently break the sync source.
Ask your Active Directory team to confirm these values in writing for each domain controller, since defaults differ by Windows Server release and by any local policy.
Security settings for the Active Directory bind
The LDAP source is the one place where authentik holds a credential for your directory and reads it continuously. The cards below cover the controls that limit what that credential can do, how it is stored, how the connection is protected, and who can change the source. Work through them together before the first sync runs against production.
Least-privilege service account
Create a dedicated bind account and grant it read access only on the search base that authentik needs, not domain-wide rights or membership in administrative groups. Confirm the account can read the attributes your property mappings use, such as the user identifier, mail and group membership, and nothing that requires write permission. Ask your directory team to document the account's scope, owner and password rotation process, because an over-privileged bind account is the most common way a sync integration becomes a larger risk than it needs to be.
Password kept in secret handling
Enter the bind password through authentik's secret handling and avoid placing it in exported blueprints, version control or documentation. Check how your deployment supplies the value, whether through the admin interface, an environment variable or an external secret store, and confirm that configuration exports do not write the password in clear text. Record who can read the deployment's environment and database, since PostgreSQL holds all authentik configuration.
LDAPS with certificate validation
Connect over LDAPS and keep certificate validation enabled, so authentik checks that the domain controller presents a certificate issued by a trusted authority and matching the host name. Install the issuing CA certificate in the authentik container or host trust store, and test the connection from the same network path that authentik uses. Avoid disabling validation to get a connection working, because that leaves the bind password exposed to anyone who can intercept traffic between authentik and the directory.
Scoping OUs in the search base
Set the base DN and any filters so that authentik only reads organizational units that contain users and groups it should sign in or provision. Exclude service accounts, disabled staging OUs and other populations that do not belong in authentik, and review the filter after each directory reorganization. A narrow search base also limits how much directory data authentik stores and how many accounts appear in a compromise scenario.
Reviewing who can edit the source
Changing the LDAP source's base DN, filters, certificate or bind credentials can redirect which accounts authentik trusts. Limit edit rights for the source to a named group of authentik administrators, and review that membership on a schedule. Treat changes to the source as reviewable changes, record who made them, and keep a documented procedure for emergency edits.
Monitoring bind failures and lockouts
Forward authentik logs to your monitoring system and alert on repeated LDAP bind failures, since a rotated or expired service account password will stop syncs silently until someone notices. Watch for lockouts on the bind account in the directory, which often follow a password change that was not updated in authentik. Confirm which audit events your edition records. The Enterprise audit logging feature is listed on the pricing page, so ask whether the events you need for bind and source changes are covered by your edition or require additional logging.
Common Active Directory sync failures and their fixes
This table pairs common symptoms of an authentik LDAP sync from Active Directory with their likely causes, the checks to run on each side, and the fix. Verify each symptom in your own environment before changing settings, because the same symptom can have more than one cause.
| Symptom | Likely cause and check | Fix |
|---|---|---|
| Invalid bind credentials | The service account password has expired, changed, or the bind DN points to the wrong object. In authentik, check the source's bind DN and the sync task log. In Active Directory, confirm the account is enabled and the password is current. | Reset or re-enter the service account password in the authentik source, then confirm the bind DN uses the full distinguished name of that account. |
| Users missing after sync | The base DN does not include the OU that holds the users. In authentik, compare the source's base DN with the OU path in Active Directory Users and Computers or ADSI Edit. | Set the base DN to the parent container that holds all in-scope users, or narrow scope with the user object filter, then run a full sync. |
| Disabled accounts appearing or not appearing | The user object filter does not exclude disabled accounts, or it excludes accounts that should sync. Check the filter in the source and the userAccountControl flag on sample accounts in Active Directory. | Adjust the user object filter to match your policy for disabled accounts, then confirm with a test user from each state. |
| Computer accounts imported as users | The filter matches the objectClass for computers or does not exclude it. Look for objects ending in $ in the synced user list in authentik. | Add a filter that limits results to user objects and excludes computer objects, then remove the imported entries and re-sync. |
| Nested group members lack group-based access | Group membership is read one level deep, or the group lookup does not resolve nested groups in your configuration. Compare a nested member's groups in authentik with the effective membership in Active Directory. | Confirm nested group handling is enabled in the source, or use a matching rule based on direct group membership, and test with a user two levels deep. |
| Certificate errors on LDAPS | The domain controller certificate is not trusted by authentik, its name does not match the server address, or the chain is incomplete. Check the connection with the server name you configured and review the error in the logs. | Install the issuing CA certificate in the authentik trust store and use the hostname that appears on the domain controller certificate. |
| Sync succeeds but users cannot sign in | The synced account has no usable password path, is mapped to a flow that requires a factor it lacks, or its source binding is missing. In authentik, check the user's source link, flow bindings and the password policy. In Active Directory, confirm the account is not locked or disabled. | Bind the source to the correct authentication flow, confirm the user can authenticate against the directory, and test sign-in with a pilot account before wider rollout. |
Questions teams ask before connecting authentik to Active Directory
What drives the effort of an Active Directory integration with authentik?
The main drivers are how much of the directory authentik must read, how groups are nested, and what the integration must write back. Scope grows with the number of organizational units in the sync, because each base DN and filter needs a deliberate decision about which objects enter authentik. Nested groups add mapping work, since group membership and application entitlements must be checked against real results. LDAPS certificate setup adds work on both the authentik and domain controller sides. Password write-back, if you need it, adds a further security review and testing. Testing scope and the number of user populations to validate also count. Ask for each of these as a separate line item in the quote, with the assumptions behind it.
Can our identity team connect authentik to Active Directory without a partner?
Yes, a capable identity or platform team can build this in-house, but the work is more than a form. The team needs working knowledge of LDAP filters, Active Directory schema, bind accounts, TLS trust chains and authentik's source and property mapping model. Expect the first sync to surface data you did not anticipate, such as service accounts, disabled users or computer objects in the wrong place. A partner tends to make sense when the team has not run a directory sync before, when the rollout has a fixed deadline, or when an independent party should review the design. Either way, the internal team should own the configuration after handover and be able to run and troubleshoot the sync without outside help.
What does the Active Directory team need to provide for the integration?
The Active Directory team provides the read-only service account, the scope of OUs and groups to sync, and the certificate material for LDAPS. Ask them for directory access or an export that lets the design rest on real data rather than assumptions. They should also confirm the domain controller settings for LDAP signing and channel binding, because those decide whether plain LDAP or LDAPS will work. If password write-back is in scope, they must approve the delegated permissions and review the effect on password policy and lockout. Name a contact for change windows, since sync failures often trace back to expired bind passwords, lockout policy or group changes made during testing. Agree in writing on who signs off each stage.
Can authentik write passwords back to Active Directory?
Confirm this against the authentik documentation for the release you plan to run before you commit to it, because write-back depends on the version and on how the source is configured. Writing a password to Active Directory requires an encrypted connection, so the design should use LDAPS with a certificate chain the authentik server trusts. The service account also needs explicit permission to reset passwords on the relevant OUs, and that delegation should be scoped as narrowly as possible. Test the flow in a lab domain first, then verify that a change reaches every domain controller that users authenticate against. Also ask how a failed write-back is handled, so a user is not left with mismatched passwords or locked out in one system while working in the other.
How does directory size and group design affect testing time?
Testing effort depends on how many objects the sync touches and how many group rules must behave correctly. A directory with a small number of OUs and flat groups needs fewer cases than one with deep nesting, overlapping groups and mixed populations such as contractors, service accounts and shared mailboxes. Test cases should cover new joiners, leavers, disabled accounts, group moves, nested membership changes and password changes if write-back is included. Repeat sync runs deserve their own tests, because the second run often reveals deletion, duplicate or drift problems that the first run hides. Ask the quote for the test matrix, the number of test cycles included and who signs off the results. Be cautious about any timeline that does not come with a list of test cases behind it.
Which authentik edition do we need for an Active Directory source?
The authentik code is mostly under the MIT license, and the Open Source edition is free with community support through Discord. authentik's pricing page lists an Enterprise edition at $5 per user per month billed annually, plus $0.02 per external user per month, and places Google Workspace and Microsoft Entra ID integrations, audit logging and password history among Enterprise features. The pricing page does not name an LDAP source as an Enterprise feature, but confirm that on the page and in the documentation for your version. Also confirm that every feature you need for compliance evidence, such as audit logging, is available in the edition you choose. Code in the enterprise directory of the repository falls under a separate license, so check that license if you plan to use those features.
What should we ask for in a written quote for this work?
Ask for a written scope that lists each OU and group in the sync, the authentik version the work targets, and whether LDAPS and password write-back are included. Request the number of environments, the test matrix, the handover items and the documentation the internal team will receive. Separate one-time work, such as design, build and testing, from recurring work, such as upgrades, monitoring and support. Ask what changes if the directory is larger or the group design differs from the assumptions in the scope, and what you must provide, such as the service account and change windows. DeployOpen delivers most engagements as fixed scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.
How DeployOpen scopes, delivers and supports the Active Directory integration
DeployOpen plans and builds the authentik LDAP source for Active Directory as a fixed-scope engagement, with the scope agreed in writing before work starts. The work runs inside your own infrastructure, and the handover covers the configuration, tests and runbooks your team needs to operate the sync.
How we scope
- Confirm which domains, forests and organizational units authentik will read, and which group types and nesting depth the sync must honor.
- Agree the service account rights, the LDAPS requirement for any password write-back, and the approach to computer account filtering in writing.
- Record the Windows Server 2025 LDAP signing default and the domain controller versions you run, so signing behavior is confirmed before build.
How we build
- Configure the LDAP source in authentik with user and group property mappings, sync filters and nested group handling matched to your directory design.
- Test the sync against a non-production copy of the directory, including disabled accounts, service accounts and nested memberships.
- Validate LDAPS certificates and password write-back paths on a controlled test account before any change reaches production users.
How we hand over
- Deliver the authentik source configuration, mappings and filters as documented settings your team can review and reproduce.
- Provide test results, a list of accepted exceptions and the rollback steps for the sync and the LDAP bind credentials.
- Walk your identity and directory administrators through sync schedules, failure signals and the escalation path for lockouts.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer that covers authentik version changes and directory changes.
- Retainer scope, response expectations and any service levels are set in writing with your team, so confirm them before signing.
- Re-test the integration after authentik security releases, which the project announces at least 24 hours in advance, and after directory changes.
