LDAP password writeback from authentik: what it does and when to use it
Users who change their password in authentik often expect the Active Directory or LDAP account behind it to match. Without an explicit setting, authentik does not do this, so a user can change a password in one place and still sign in to a directory-backed system with the old one. The supported method is the user password writeback option on an LDAP source. When it is enabled, a password change made in authentik is pushed back to the LDAP directory that the source reads from. Decide this before rollout, because it changes where users reset passwords and which system your help desk must check when an account is locked.
The option has a hard dependency: authentik must receive the raw password to write it anywhere. That means writeback only works for passwords authauthentik itself sees in plain form during a change or a bind. Users imported from the directory with their existing hashes are not written back, because authentik never holds the cleartext value for them. Those accounts keep authenticating against the directory through the source, but a password change for them has to be made in the directory itself until the user sets a new password through authentik's own flow. Plan your password policy, MFA rollout and any service accounts with this boundary in mind, and confirm the exact behavior for your authentik version in the authentik LDAP source documentation.
Writeback is limited to one LDAP source. If you connect several directories, only one can receive password changes from authentik, so choose the directory that is the master for credentials and confirm that the other sources are read-only for passwords. Before enabling the option in production, test a change for a non-critical account, confirm the directory accepts the new password under its own policy rules, and check how the account behaves when the directory rejects the write. Ask your authentik and directory administrators to agree who owns that check and the rollback steps if the write fails.
What you need before enabling LDAP password writeback
Writeback touches three areas at once: the directory that stores the password, the authentik deployment that sends the change, and the password rules both sides enforce. Work through the cards in order, since a gap in the directory or the source configuration will stop writeback before any policy question arises.
A directory account that can reset passwords
authentik needs a bind account in the directory with rights to change user passwords in the scope where your synced users live. In Active Directory, that usually means delegating a reset-password permission on the relevant organizational units rather than granting domain admin rights. Confirm the exact delegation with your directory administrators, because the permission model differs between Active Directory and other LDAP servers such as OpenLDAP. Record which account, which base DN and which OUs it covers before you touch the authentik source.
A secure channel for the password
Because writeback sends a raw password to the directory, the connection must be encrypted. Plan for LDAPS or StartTLS, and make sure authentik trusts the directory's certificate chain, including any internal certificate authority. Check that the domain controllers or LDAP servers you target are reachable from the authentik server or worker on the port you configure. Testing this channel with a non-production user first avoids exposing a live credential on a path you have not verified.
A supported authentik version
Run a release that is still receiving security fixes according to the authentik security policy, and confirm the upgrade path to it before you enable writeback. Writeback is a source setting, so the version you plan around is the one your server and worker containers run. Pin the version in your deployment files so a routine pull does not change behavior between your test and production environments.
An existing LDAP source
Writeback is configured on an LDAP source that already syncs users from the directory, so the source, its base DN, user object filter and property mappings must be working first. Confirm that the users you expect to change passwords are correlated to the same directory objects that writeback will target. A source that imports users into a different branch of the tree will silently send changes to the wrong place or none at all.
PostgreSQL and worker capacity
authentik stores all configuration and user data in PostgreSQL and runs background tasks in a worker container, so the database and worker must be healthy when a sync or password change occurs. The Docker Compose guide positions Compose for test and small-scale production, while the Kubernetes guide recommends a separately managed PostgreSQL for production. Decide on that database before enabling writeback, and confirm that worker logs are visible to your team so failed writes can be investigated.
Password rules on both sides
authentik should accept only passwords that the directory will also accept, or users will see a successful change in one place and a rejection in the other. Compare minimum length, complexity, history and banned-word rules in the directory domain policy with the password policies configured in authentik. Password history is an enterprise feature, so confirm which edition you run before you rely on it. Agree with your directory administrators who owns each rule before go-live.
Configure writeback on an LDAP source step by step
This sequence turns on password writeback from authentik to an LDAP directory, binds it to the password change flow, and proves with a pilot user that a change lands in the directory and that a failed change leaves both systems unchanged. Each step ends with a check you can record before you widen access.
Select or create the LDAP source
Open the LDAP source that connects authentik to your directory, or create one if none exists, and confirm the server address, base DN and user search scope point at the accounts you intend to manage. Use an encrypted connection to the directory. Run a sync and check that a small set of pilot users appears with the expected attributes. Done when the source reports a successful sync and the pilot accounts match their directory entries.
Create a dedicated bind account
Create a service account in the directory for authentik to bind with, and grant it only the rights needed to read the users in sync scope and to set their passwords. Enter its distinguished name and password in the source's bind settings. Confirm the permission scope with your directory administrator, since the exact delegation depends on your directory platform and organizational units. Done when the source connection test succeeds and the account can change a pilot user's password in a lab-only test outside authentik.
Confirm passwords are held in raw form
Writeback needs authentik to receive the raw password at the time a user sets it. Users whose accounts were imported as password hashes cannot have changes written back, so identify them before you enable the option. For pilot users, set a new password through authentik, then confirm a login against the directory succeeds with that password. Note any imported accounts that will need a password reset through authentik before they can use writeback. Done when your pilot list contains only accounts that can be written back.
Enable user password writeback on the source
In the source settings, turn on the user password writeback option and save. Check the authentik documentation for the current limit on how many LDAP sources can use writeback in your version, and plan your design around that limit before you proceed. Record the setting and the date of the change in your change log. Done when the saved source shows writeback as enabled and a second administrator has reviewed the setting.
Bind the source to the password stage
Open the flow that users run to change their passwords and check that it includes a password stage configured to work with your LDAP source. The stage decides which backend receives the new password, so the source must be selected there for writeback to occur. Remove or disable any other password stage that could take precedence for these users. Done when a test run of the flow shows the password stage and the LDAP source linked as expected, and no other backend handles the change for pilot users.
Test a change with a pilot user
Sign in to authentik as a pilot user, change the password through the password change flow, and then confirm the change in the directory by binding as that user with the new password over an encrypted connection. Also confirm the old password no longer works in the directory. Review the authentik event log for the change. Done when the new password authenticates against the directory, the old password fails there, and the event log records a successful change for that user.
Verify a rejected change leaves no partial update
Submit a password that the directory rejects, such as one that fails its complexity or history rules, through the same flow. Confirm that authentik shows an error to the user, that the event log records the failed attempt, and that the user's authentik password and directory password are both unchanged. Run the same check with a password that passes authentik's own rules but fails the directory's rules, since that is the case where partial updates would appear. Done when both systems still accept only the old password and the failure is visible in logs.
Why authentik needs the raw password to write it back
Writeback only works when authentik sees the plaintext password at the moment it is changed. A directory such as Active Directory or OpenLDAP accepts a new credential that the client has presented in a form it can store or verify, and it does not accept a password hash that authentik copied from elsewhere. authentik's LDAP source documentation states that user password writeback requires authentik to receive the raw password, which is why a user whose hash was imported from a directory or another system cannot have that password written back. Before you enable the option, confirm with your own test accounts that a password changed in authentik reaches the directory, and confirm the same for an account created by import, so the behavior is known before users depend on it.
The same requirement shapes password policy. authentik has to evaluate the candidate password against its own password rules, such as length, complexity, and checks configured in its flows and policies, before the change can be pushed to LDAP. Rules that exist only in Active Directory, such as its domain password policy or password history, are not automatically enforced by authentik just because writeback is on. Ask the directory team which controls the domain enforces, decide which of them authentik must also enforce so users get consistent feedback, and test rejected passwords in both systems. Where the two policies disagree, a user can pass one check and fail the other at the directory, which is a common source of support tickets.
Because authentik needs the plaintext value, the password is handled by authentik's processing of the change request, and the sync to the directory happens from that point. Treat the authentik server and worker containers as holding that value during the operation, and include them in your review of access, logging and network paths to the directory. Confirm how the connection to the directory is protected in your environment, including whether LDAP is carried over TLS, and document which administrators can reach the authentik host. The authentik LDAP source documentation is the place to confirm current behavior for your release.
How writeback behaves for different user populations
Users created or synced through the LDAP source are linked to a directory object, so writeback is the mechanism that keeps passwords in step. When a user changes a password in authentik, the source can send the new value to the directory, provided authentik receives the raw password at that moment. The user sees one password change in authentik, and directory-bound applications accept the new password once the write completes.
- Writeback on: Self-service password changes in authentik are written to the directory when the source's user password writeback option is enabled.
- Directory policy applies: Complexity, history and lockout rules are enforced by Active Directory or the LDAP server, so a rejected write must be explained to the user in authentik.
- One writeback source: Only one LDAP source can write passwords back, so confirm which directory is the authority before enabling the option.
- Administrative resets: Admin-initiated changes in authentik also need the raw value, so test them separately from self-service changes.
Confirm with a test account that a change made in authentik can be used to bind to the directory, and record exactly how a policy rejection appears to the user.
Users whose password hashes were imported, for example from an earlier identity store, hold a stored hash and not the plaintext password. authentik needs the raw password to write a change back, so these accounts never write back. A password change made in authentik stays in authentik, and directory-bound applications continue to accept the old password. This is where the most confusion appears, because the user sees success in one place and no effect in another.
- No writeback: Hash-imported accounts are excluded because authentik never receives the raw password for them.
- Silent divergence: A successful change in authentik can leave the directory password unchanged, so users may report login failures in other systems.
- Password authority: Decide whether the directory or authentik owns the password for these accounts, and document that decision.
- Reset path: Plan a reset flow that gives authentik the raw value, or keep these users on the directory password until they can be moved.
Confirm with a test account exactly what changes in each system, and do not promise writeback to these users until that behavior has been verified in your environment.
Users created directly in authentik, without a link to the LDAP source, have no directory object tied to them through that source. The writeback option applies to accounts the source manages, so a native account's password change should be expected to stay in authentik unless the team links or provisions a matching directory account. Confirm the exact behavior in the release you run, because the answer depends on how the account is linked to the source.
- No automatic directory account: Creating a user in authentik does not by itself create an Active Directory object, so confirm which system provisions the account.
- Matching identifiers: If a directory account is created later, the username and attribute mappings must match so the source can correlate the two.
- Intended scope: Record whether each native account is meant to exist only in authentik or also in the directory.
- Duplicate identities: Two accounts with the same name in authentik and the directory cause confusion during writeback and sync, so check for collisions before import.
Ask who owns the lifecycle of native accounts, and test a password change against both systems before go-live.
Writeback works reliably only when the team knows which population each account belongs to and which system holds the password of record. Alignment is an operating task as well as a configuration task. Accounts move between populations over time through reimports, resyncs and new onboarding paths, so the mapping must be reviewed whenever those paths change. The outcome for users depends on this inventory being accurate.
- Inventory by origin: Tag every account by how it reached authentik before enabling writeback.
- Confirm the authority: Verify that the single writeback source points at the directory of record.
- Test failure messages: Check how directory policy errors and timeouts appear to users in authentik, and whether support staff can see them.
- Recheck after changes: Review mappings and sync scope after each authentik upgrade and after any change to the source configuration. The LDAP source documentation is the reference for the current option names.
Before go-live, document the password authority for each population and assign an owner who answers help desk questions about mismatched passwords.
Limits that shape the design
Three limits decide how writeback fits into your directory landscape: where passwords can be written, which passwords authentik can send, and which account authentik uses to write them. Each one forces a design decision you should settle before the first password change flows back to the directory.
One writeback source only
Only one LDAP source can hold password writeback in authentik, so a deployment that reads from several directories has to choose one. That choice makes the chosen directory the effective system of record for passwords, while the others remain read-only for credentials. Confirm which directory your users change passwords in today, and whether any other directory must also accept changes made in authentik before you enable the option on any source.
Raw password requirement
Writeback works only when authentik receives the raw password, which happens when users set or change it inside authentik. Accounts imported as stored hashes never give authentik the plaintext, so their passwords are not written back. Map out which users arrived by hash import and which were created or changed through authentik, because the two groups will behave differently after a change.
Hash imports stay local
Because hashed passwords are never written back, a password reset in authentik can leave the directory copy out of step. Users may then authenticate with different passwords in authentik and in Active Directory or OpenLDAP. Decide in advance whether users will authenticate against the directory or against authentik for each application, and document the expected state for helpdesk staff.
Bind account permissions
Writeback depends on the bind account that authentik uses to connect to the directory. If that account lacks permission to modify the password attribute on the target users, the change may fail after the user has already been told it succeeded. Plan a dedicated service account with only the rights needed for password changes on the in-scope users, and test a change on a non-production user before enabling the option broadly.
Directory system of record
The writeback choice is really a choice of system of record. Active Directory Domain Services replicates directory data to every domain controller in a domain, so a password written there reaches the other domain controllers through normal replication. Confirm with your directory team which directory owns identity lifecycle, group membership and password policy, and align the authentik source configuration with that owner.
Which password events write back and which do not
This table compares common password events against whether authentik writes the new password back to LDAP or Active Directory, why, and what the team should do. Read each row as a decision: if the event does not produce a raw password inside authentik, plan for the password to stay in the directory. Confirm edge cases in the LDAP source documentation before you rely on a row.
| Password event | Writeback applies | Reason and action |
|---|---|---|
| User changes password in authentik on an LDAP source | true | authentik receives the raw password when the user sets it, so it can be written to LDAP. Enable user password writeback on the source and test with a sample account. |
| Administrator resets password in authentik for an LDAP-sourced user | true | The administrator enters a new raw password in authentik, which is the input writeback needs. Confirm the reset path you use triggers the same writeback behavior in your version. |
| User imported with a password hash | false | authentik stores the hash but never receives the raw password, so there is nothing to write back. Keep password changes for these users in the directory or plan a one-time credential reset. |
| Native authentik account with no LDAP source link | null | No LDAP directory is involved, so writeback does not apply. Keep these accounts out of the LDAP writeback design. |
| Password changed directly in Active Directory or LDAP | false | The change originates in the directory and authentik does not see the raw password. Expect authentik to pick up the new state only through its normal sync, and confirm that behavior for your source. |
| Password written back from a source that is not the sole writeback source | null | authentik's writeback option is limited to one writeback source. Confirm the limit in the LDAP source documentation and choose one directory as the writeback target. |
Securing the writeback path
Writeback moves a plaintext password from authentik to your directory, so the path it takes and the accounts that touch it carry the risk. The cards below cover transport, the bind account, who can change the source, audit trails and the stored bind credential.
Encrypt the password in transit
The raw password crosses the network from authentik to the directory during every writeback, so the connection must be encrypted. Use LDAPS on port 636 or StartTLS on the directory connection, and confirm that authentik validates the directory's certificate chain against your internal certificate authority rather than skipping verification. Test with a non-production account first, because a plaintext connection can appear to work until a password is changed on a live path.
Scope the bind account to password reset
The service account authentik uses to write passwords should hold only the rights needed to set or reset user passwords in the target container. Grant no group membership changes, no attribute writes beyond the password fields and no rights over administrator accounts. Ask your directory team to document the delegation, and review it after every change to the source's search base so the account cannot reach users outside the intended scope.
Restrict who administers the source
Anyone who can edit the LDAP source in authentik can change its base DN, bind account or writeback setting, which can redirect password changes to a different directory. Limit source administration to a named group of administrators, separate it from general application administration, and require a second reviewer for changes to the bind account or search scope. Record who holds these permissions as part of your access review.
Log every password change
Writeback is a high-impact action that should leave a trail in both systems. Check what authentik records for password changes and what the directory records for the bind account's writes, then confirm the two logs can be correlated by username and time. Enhanced audit logging is listed on the authentik pricing page as an Enterprise feature, so confirm its availability and retention with authentik before you rely on it for evidence.
Protect the bind credential
The bind account password is stored in authentik's configuration, so anyone with database or configuration access could recover it. Keep it out of plain-text configuration files and version control, restrict database and backup access to operators who need it, and rotate the password on a schedule and after any administrator change. Confirm with your team how secrets are injected into your deployment before go-live.
Why writeback fails and how to fix it
The table lists the failures teams most often hit when password changes made in authentik do not reach Active Directory or LDAP, with the likely cause and fix for each. Work down the rows in order, because the first two failures are the ones that look like writeback is working when it is not.
| Failure | Likely cause | Fix |
|---|---|---|
| Password change does not reach the directory | Writeback is not enabled on the LDAP source, or the user's password was imported as a hash rather than set in authentik, so authentik never received the raw password | Enable user password writeback on the LDAP source. Confirm the user changed or set the password in authentik after the source was configured, because hashed imports are never written back |
| Directory rejects the new password | The password fails the directory's complexity, history or minimum age rules, and the error is not surfaced clearly in the authentik flow | Align the authentik password policy with the directory's domain password policy. Test with a sample password on a non-production account and read the directory's event logs for the rejection reason |
| Bind account cannot write passwords | The service account used by the LDAP source lacks the permission to reset or change user passwords on the target OUs | Grant the bind account password change rights on the user OUs in scope, scoped to only the attributes and containers it needs. Verify with a test change before rollout |
| Imported users never sync a change | Users were imported with hashed passwords, so authentik holds no raw password to send, and the sync source does not treat their accounts as writeback candidates | Have affected users set a new password in authentik so the raw value is captured. Plan a communication step for migrated accounts instead of assuming the directory will update |
| Two LDAP sources configured for writeback | More than one LDAP source has writeback enabled, which is a limit for this feature, so changes can be sent to the wrong directory or not at all | Keep writeback enabled on one LDAP source only. Disable it on the others and confirm the chosen source is the directory that owns the accounts |
| Certificate errors on the secure channel | The authentik server does not trust the certificate chain of the domain controller or LDAP server, or the connection is not using the TLS settings the directory expects | Import the issuing CA certificate into the authentik trust store, confirm the hostname matches the certificate, and test the secure connection from the authentik host before enabling writeback |
Questions teams ask before enabling LDAP password writeback
What drives the effort and cost of enabling LDAP password writeback?
The main drivers are the directory permissions review, testing with pilot users, alignment of password rules between authentik and the directory, and who runs the work. Your internal team is paid in staff time, while a partner is paid under a fixed-scope written agreement. Permissions review and testing are mostly one-time work, but password policy and directory changes need ongoing ownership. Ask any quote to break out the permissions review, the pilot plan, the policy mapping, and the handover documentation. Enterprise features and support tiers are listed on the authentik pricing page, so check there whether your chosen features require a paid edition.
Does LDAP password writeback work with Active Directory and OpenLDAP?
Writeback is configured on an authentik LDAP source, so it applies to directories that source can reach over LDAP. Confirm in the authentik LDAP source documentation exactly which directory server behaviors and password attributes your target directory needs, since Active Directory and OpenLDAP handle password attributes and policy differently. Active Directory password changes depend on directory settings such as the account type and the secure connection used, so test with a non-production account first. Confirm the approach for your OpenLDAP version with its documentation, because password handling depends on overlays and access rules you configure.
What happens to users imported with password hashes?
Users imported with hashed passwords are not written back. Writeback requires authentik to receive the raw password when a user sets it, and a hash import does not provide that. Those users keep working with the hash for authentication, but a password change made in authentik for them will not reach the directory. Plan for this before go-live by identifying which accounts were imported as hashes, deciding whether they should be migrated through a password reset that supplies a raw password, and confirming how your directory and authentik will stay consistent during the transition.
Can two LDAP sources write passwords back to the same directory?
Plan for one writeback source only. The documented limit is that one writeback source is supported, so a design with two sources writing to different directories or overlapping user sets needs a different approach. Map which users each source owns, confirm that only one source is enabled for writeback, and check how the other source handles password changes for its users. Confirm the current limit in the authentik LDAP source documentation before you finalize the design, because source behavior can change between releases.
What does the team need to provide before the work starts?
Provide a service account with the directory permissions needed to change user passwords, limited to the organizational units in scope. Also provide the password policy in force in the directory, the list of pilot users, a test directory or lab copy, the authentik version and deployment details, and the names of the people who approve changes. Your security team should review how the service account credentials are stored and rotated. Confirm each of these items in writing with the implementation scope so the test plan and the rollback path are agreed before any change reaches production.
Should our internal staff or a partner run the writeback rollout?
Either can run it. Internal staff are best placed when they already administer the directory, authentik and the change process, and can absorb the testing time. A partner is a fit when the directory team is stretched or the rollout has to be proven under a written scope. DeployOpen plans, implements, tests and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask either option to show the permissions review, the pilot results and the rollback steps before enabling writeback for all users.
How do we verify that writeback is working before we rely on it?
Test with a small group of pilot users whose accounts you can restore. Change a password in authentik, confirm the new password authenticates against the directory, and confirm that a failed change does not leave the two systems out of step. Test accounts imported with hashes separately, since they should show that no writeback occurs. Record the results, review the directory audit trail for the service account, and keep a rollback plan. Repeat the test after each authentik upgrade, because writeback behavior should be checked against the release notes for the version you run.
How DeployOpen scopes and delivers LDAP password writeback
DeployOpen approaches LDAP password writeback from authentik as a fixed-scope piece of identity work inside your own infrastructure. We agree the directory, the writeback source and the test plan in writing before any change reaches your domain controllers or LDAP server.
How we scope
- Confirm which LDAP source will receive writeback and that it is the single writeback source the deployment allows
- Record how users were onboarded, so hashed imports that cannot be written back are identified before go-live
- Agree in writing which password change paths in authentik are in scope, and which directory accounts they touch
- Set the scope and deliverables in writing before work starts, with a quote following from that scope
How we build
- Configure the LDAP source with user password writeback enabled and confirm authentik receives the raw password at login or change
- Test password changes against a non-production directory and a service account with the rights it actually needs
- Verify that each writeback result appears in the directory and that failed writes produce a visible error for the user
- Check that the authentik version in use is on a supported release line before enabling the feature in production
How we hand over
- Document the writeback configuration, service account permissions, and the list of users who cannot be written back
- Provide a test script and recorded results showing password changes reaching the directory and rejected cases
- Explain the known limits, including the one writeback source restriction and the reasons imported hashes are excluded
- Walk your administrators through the runbook for rotating the service account credential and reviewing failures
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing
- Retest writeback after each authentik upgrade, since release notes and breaking changes can affect LDAP sources
- Review directory and writeback logs with your team when password change failures are reported
- Confirm any directory-side behavior, such as password policy or replication delay, with your directory owners
