How authentik syncs users and groups from FreeIPA
When FreeIPA or Red Hat Identity Management is the system of record for people and groups, authentik has to mirror those identities before it can sign anyone in or assign them to applications. authentik documents directory synchronization from FreeIPA as a supported method, and it is built on the same LDAP source that handles other LDAP directories. The direction matters: the sync only creates or updates users and groups inside authentik. It does not change anything on the FreeIPA side. Password writeback is a separate option, and it needs the raw password, which FreeIPA does not hand over during a normal bind. Treat writeback as a distinct design decision with its own review, not as a side effect of sync.
This section explains how the pieces fit together so you can plan the build. The FreeIPA sync is configured as an LDAP source in authentik, which means the decisions that matter are the bind account, the search base and object filters that define which users and groups are imported, and how group membership is carried into authentik's own group model. Because authentik only reads, a misconfigured filter or a deleted group in FreeIPA will propagate into authentik on the next run, so confirm the scope with the FreeIPA administrators before the first sync. Also confirm which FreeIPA attributes your authentik flows and applications depend on, since those are what the sync must populate.
The rest of this page covers the service account and its permissions, the sync settings and schedule, how password validation is handled against FreeIPA, and the group mapping that decides who gets access to what. Read the service account section first, because every later setting depends on what that account is allowed to see. Where a setting depends on your FreeIPA version or deployment layout, check the current authentik sources documentation and your own FreeIPA configuration rather than assuming the defaults.
What you need before connecting authentik to FreeIPA
Most sync problems trace back to decisions made before the LDAP source exists. Confirm the authentik version, the FreeIPA server and its certificate chain, a read-only bind account, and the network paths from both authentik containers before you create anything in the admin interface.
Supported authentik version line
Run a version on a line that still receives security fixes. The authentik security policy lists 2026.5.x and 2026.8.x as the supported lines, and the project announces security releases at least 24 hours in advance. Confirm which minor version your environment runs before you copy LDAP source settings from older guides, because source options can change between releases. Plan upgrades before the sync goes live so you are not reconfiguring the source during a version change.
FreeIPA or Red Hat IdM version
Record the exact IdM version on your primary server before you choose settings. FreeIPA 4.13.4, a stabilization release dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could expose credentials to unauthenticated clients. Red Hat Identity Management ships its own version cadence, so confirm the build with your Red Hat subscription or your platform team rather than assuming it matches the upstream release.
Reachable IdM servers and DNS
Confirm that the authentik server and worker containers can resolve the IdM hostname and reach the LDAP port on at least one replica. FreeIPA clients depend on DNS, so verify that the name you put in the source URL matches the server certificate. Test from inside the containers, because host-level routing and container network policies can differ. If you plan to fail over, list more than one replica and confirm each one answers.
LDAPS and certificate trust
Use an LDAPS connection so bind credentials and any password writeback traffic are encrypted. Export the CA certificate that signed the IdM LDAP certificate, typically the IPA CA, and make it trusted by the authentik containers. Check that the certificate subject or SAN matches the hostname in the source configuration. Certificate errors often look like connection failures, so test the TLS handshake separately before troubleshooting authentik.
Read-only service account
Create a dedicated bind account in FreeIPA for authentik instead of reusing an administrator. Grant it only the read access needed to list users and groups under the directory base. Authentik's LDAP source creates and updates objects only inside authentik, so a read-only account is sufficient for sync. Add write permissions only if you enable password writeback, and document who approved that change and why it is needed.
Network paths and firewall rules
Map each path from the authentik server and worker to IdM before the first sync, since the worker runs the background sync tasks. Open the LDAP or LDAPS port from both containers, and confirm any firewall between the networks allows the traffic. Note that FreeIPA deployment guidance expects dedicated servers and at least two DNS servers in client resolver settings, so ask your IdM team which replicas will serve authentik and whether they accept connections from the authentik subnet.
Configure the FreeIPA LDAP source in authentik step by step
This sequence connects authentik to your FreeIPA domain through an LDAP source, so that users and groups are created and updated in authentik on a schedule you control. Each step ends with a check you can run before moving on.
Create a read-only service account in FreeIPA
A FreeIPA administrator creates a dedicated user, such as a service account for authentik, in the IPA domain and sets a strong password for it. The account needs read access to the user and group entries that authentik will import, and it should not be a person's administrator account. Confirm the exact rights and the LDAP access control settings for your FreeIPA version with your FreeIPA administrator and the authentik LDAP source documentation before you assign them. Done means the account exists, its password is stored in your secrets manager, and the next step's bind test succeeds.
Test the bind from outside authentik
Before touching authentik, run an LDAP search from a host that can reach the FreeIPA servers, using the service account's distinguished name and password. Use an LDAPS or StartTLS connection if your security policy requires encrypted transport, and confirm the certificate chain is trusted by the authentik host. A successful search that returns the expected user and group entries under the users and groups containers means the account, network path and certificate are working. A failed bind here will also fail inside authentik, so resolve it now.
Create the LDAP source in authentik
In the authentik admin interface, an administrator opens Directory, then Federation and Sources, and creates a new LDAP source. Follow the FreeIPA directory sync guide to choose the FreeIPA preset where it applies, then enter the server URI, the service account's bind distinguished name and password, and the TLS settings you tested. Save the source, then open its connectivity or test option if your version offers one. Done means the source is saved and reports a successful connection to the FreeIPA server.
Set the base DN and user and group filters
Enter the base distinguished name for your IPA domain, and set the user and group search base and object filters so they match the FreeIPA schema in your environment. Keep the scope narrow at first, for example one user container and one group container, so that service accounts, host entries and other objects are not imported by accident. Confirm the object class and attribute names against the entries you saw in the bind test. Done means a preview or test search returns only the users and groups you intended.
Choose sync users and sync groups
Enable user synchronization and group synchronization in the source, and map group membership so that FreeIPA groups become authentik groups with their members attached. Leave password writeback off unless you have a separate, reviewed requirement for it, because writeback needs the raw password and is a distinct option from synchronization. Document which settings you chose, since they determine what authentik can create or update. Done means the settings are saved and you can state, for each option, what it changes in authentik.
Run the first sync and watch the task
Trigger the source's synchronization task manually, then follow its progress in the authentik task view or logs until it completes or reports errors. Expect the first run to create the most objects, and capture any warnings about skipped entries or attribute mapping problems. Remember that synchronization only creates or updates objects in authentik and does not change anything in FreeIPA. Done means the task finishes without fatal errors and the logs list the object counts you can compare in the next step.
Verify object counts and a sample login
Compare the number of users and groups in authentik with the number returned by your filtered FreeIPA search from the earlier steps, accounting for any entries you excluded on purpose. Then pick one test user, confirm that the account, email and group memberships look correct in authentik, and sign that user in with their FreeIPA password through the authentik login flow. Done means the counts match your expected set and the sample user can authenticate, which is the evidence you need before enabling a regular sync schedule.
Mapping FreeIPA users, groups and attributes to authentik
This table compares each FreeIPA attribute or membership with how authentik receives it through the LDAP source and what you may need to configure. Read it as a checklist before the first sync, because attribute names depend on your FreeIPA schema and your mappings. The main takeaway is that the default mappings cover basic identity fields, while groups, nested membership and any custom attributes need explicit review and testing.
| FreeIPA item | Where it lands in authentik | What to confirm |
|---|---|---|
| uid | Username of the authentik user | Confirm uid is unique in your FreeIPA domain and that no local authentik accounts collide with it |
| User email address | Confirm every synced user has a mail value, since missing values leave gaps in notifications and recovery | |
| givenName and sn | First and last name fields on the user | Confirm the default property mappings populate these fields and check how display names render |
| memberOf (direct groups) | Group membership on the authentik user | Confirm the group attribute your source reads returns direct memberships for your users |
| FreeIPA groups | authentik groups created or updated by the sync | Confirm group names are unique and decide whether the sync should create groups you have not yet reviewed |
| Nested group membership | Depends on how the LDAP source resolves group chains | Test a user who is a member only through a nested group and confirm the expected authentik group membership |
| Custom or non-default attributes | Requires a custom property mapping in authentik | Confirm attribute names in your own schema, because FreeIPA deployments can extend the default object classes |
| Attributes used by applications | Scope or property mappings for downstream OIDC or SAML claims | Confirm which claims each application needs and test them with a non-production user before rollout |
How password validation against FreeIPA works
When a user signs in to authentik with a FreeIPA account synced through the LDAP source, authentik checks the password by performing a bind against FreeIPA. The password is verified by FreeIPA, not by authentik, and the sync itself does not copy the password into authentik's database. The sync only creates or updates user and group objects. That means the directory remains the place where the credential lives, and authentik's login result depends on whether FreeIPA accepts the bind at that moment. Confirm this behavior against the current LDAP source documentation for your authentik version, and test a bind with a non-administrator account in a staging environment before you rely on it.
The trade-off is between validating at every login and keeping a local credential in authentik. Validating against FreeIPA means one source of truth for passwords, OTP and account state, and no second password store to secure or rotate. The cost is a runtime dependency: if the FreeIPA replicas that authentik reaches are unavailable or unreachable over LDAP or LDAPS, users cannot sign in, and you should plan which replicas authentik targets and how failover is handled. Password writeback is a separate option. It needs the raw password to be sent from authentik to FreeIPA, so it only applies when users change their password in authentik and you have decided that the LDAP connection must carry that secret. Decide on writeback before rollout, because enabling it changes where password changes happen.
FreeIPA policies apply at the directory, so authentik inherits them without configuring them there. Account lockout after failed attempts, password expiry, password history and the state of disabled accounts are enforced when FreeIPA answers the bind. Users may therefore see a failed login in authentik with no explanation, and a lockout may come from attempts made in another application that uses FreeIPA. Ask your FreeIPA administrators which password and lockout policies apply to the groups you sync, and agree on how expiry prompts will reach users, since authentik will not warn them from a locally stored expiry date. Test these cases deliberately, including a locked account and an expired password, so your help desk knows what the user will see.
Securing the service account, LDAPS and sync scope
A FreeIPA source gives authentik a standing read path into your identity store, so the bind account, transport, search scope and password handling decide how much an attacker gains if authentik is compromised. The cards below cover each control and the checks to run before go-live.
Read-only bind account
Create a dedicated FreeIPA service account for the authentik LDAP source and grant it only the read access needed to list users and groups and the attributes authentik maps. Do not reuse an administrator account or a personal account. Confirm with your FreeIPA administrator which access control rules apply to that account, and test that it cannot modify entries. Because the LDAP source only creates or updates objects inside authentik, the bind account does not need write rights on the FreeIPA side for ordinary sync.
LDAPS with certificate validation
Connect authentik to FreeIPA over LDAPS and verify the server certificate against the CA that issued it, instead of accepting any certificate. FreeIPA's integrated Dogtag certificate authority can issue that certificate, so the CA chain is available to import into authentik. Plain LDAP sends the bind credentials and synced attributes in a form an attacker on the network path can read. Check that the hostname in the configured server address matches a name on the certificate.
Base DN and group scope
Set the sync base DN to the users and groups subtree that authentik needs, not the directory root. Narrow the group filter to the groups that map to authentik roles or applications. A wide scope pulls service accounts, host entries and system groups into authentik, where they can gain application access through group membership. Review the imported object counts after the first sync and compare them with what the access model expects.
Bind password storage in authentik
The bind password is stored in authentik's configuration database, so anyone with administrator access to authentik or to its PostgreSQL database can read it. Limit administrator roles in authentik, restrict database access to the authentik server and worker, and rotate the service account password on a schedule your FreeIPA team can support. Confirm how your deployment supplies secrets, for example through environment variables or a secrets manager, before storing the value in the admin interface.
Password writeback only where required
Password writeback needs the raw password, so authentik can only write changes back to FreeIPA when the password is available in plain form. Enable it only if users must change their FreeIPA password through authentik. Give the service account the minimum rights to set passwords on the user subtree, not on all of FreeIPA, and use LDAPS for that traffic. If users only sign in and do not change passwords through authentik, leave writeback off.
Keep FreeIPA patched
FreeIPA 4.13.4, a stabilization release dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials. Because authentik's bind account depends on those access controls, confirm which FreeIPA release your servers run and apply the security fixes in your maintenance cycle. Record the release in your change log, since the fix is only effective once your servers run a fixed version.
Why FreeIPA sync and logins fail in authentik
This table lists the failures teams most often hit when syncing FreeIPA into authentik through an LDAP source and signing users in, with the likely cause and fix for each. Read it in order when a sync or login breaks, starting with bind and TLS errors, since those block everything after them.
| Failure | Likely cause | Fix and where to check |
|---|---|---|
| Bind errors (invalid credentials) | The bind DN does not match the service account's full FreeIPA DN, or the password was rotated or entered with stray whitespace. | Confirm the service account DN and password with the FreeIPA administrator, then re-enter them in the LDAP source. Check the authentik worker logs for the bind result on the next sync. |
| TLS certificate trust failures | authentik does not trust the CA that issued the FreeIPA server certificate, or the connection uses a hostname that is not on the certificate. | Import the FreeIPA CA certificate into authentik's certificate store and select it in the LDAP source. Connect using the FreeIPA server hostname, not an IP address. Look for certificate verification errors in worker logs. |
| Users missing after sync | The base DN points above or beside the user container, or the user filter excludes FreeIPA's object classes or the account state in use. | Compare the base DN with the cn=users and cn=accounts branches in FreeIPA. Adjust the base DN and user filter, then run sync again. Confirm the user count against an LDAP search from a FreeIPA host. |
| Group membership not appearing | The group base DN or group filter misses FreeIPA groups, or membership is read from an attribute the mapping does not use. | Verify the group base DN and filter, and that the user-to-group membership attribute matches how FreeIPA stores members. Check that group sync is enabled. Re-run sync and review the group entries in authentik. |
| Duplicate usernames | A local authentik account already uses the same username, or two FreeIPA entries (such as a user and a service account) share a name. | Decide which source owns the account and rename or remove the duplicate before sync. Review the source's matching behavior in the documentation and confirm it with a test account first. |
| Password validation fails at login | The user is authenticated against the LDAP source, but the bind uses a password FreeIPA rejects, such as an expired password, a password policy that requires a change, or a Kerberos-only account. | Have the user change the password in FreeIPA, then retry. Confirm the password policy and expiry settings in FreeIPA. Check the authentik event log for the login attempt and its failure reason. |
| Logins blocked after FreeIPA lockout | FreeIPA locked the account after repeated failed binds, often because an old password is still stored by the source or a retry loop keeps binding with it. | Fix the stored password first, then unlock the account in FreeIPA. Review the failed bind attempts in the authentik logs before retrying, so the lockout does not repeat. Confirm the lockout policy with the FreeIPA administrator. |
| Changes not reflected after sync | The sync schedule has not run since the change, or the source is disabled or pointed at a different server. | Confirm the sync schedule and source status in authentik, then trigger a manual sync. Check the task and worker logs to see whether the sync job completed. |
Questions buyers ask about FreeIPA sync with authentik
Is authentik open source, and what does the enterprise license cover?
Yes. authentik's repository places most of its code under the MIT license (SPDX: MIT). The code in the authentik/enterprise/ directory falls under a separate enterprise license defined in that directory, so read that file before you rely on any enterprise-only feature. The LDAP source used for FreeIPA sync sits in the MIT-licensed code, so a community deployment can run this integration without an enterprise subscription. The pricing page lists Open Source as free with community Discord support only, and it lists enterprise-only features such as Google Workspace and Microsoft Entra ID integrations, mTLS, privileged access management and enhanced audit logging. None of those are needed for FreeIPA sync. Confirm the edition and licensing terms with authentik before you commit to a design, and check the authentik LICENSE file on GitHub.
Can our team set up FreeIPA sync with authentik alone?
Often yes, if your team already runs FreeIPA and authentik and has someone comfortable with LDAP filters, service accounts and certificate handling. The work is a defined sequence: create a read-only bind account in FreeIPA, configure the LDAP source in authentik, validate the user and group filters, set the sync schedule, map groups to authentik roles and test password validation against FreeIPA. The harder parts are usually outside authentik: replication health across FreeIPA servers, the LDAPS certificate chain, and deciding which group structure authentik should expose. Teams without recent FreeIPA administration experience tend to find those parts take longer than the authentik configuration itself. A fixed-scope engagement from DeployOpen covers the same steps with written deliverables, and you can ask for a quote that lists which of them your team will own.
How long does FreeIPA sync take, and what does it cost?
DeployOpen does not publish a price list, and this page does not give a duration because no researched figure covers this integration. Cost and time follow from the written scope, and the main drivers are the number of users and groups to sync, the FreeIPA replication topology (how many replicas exist and whether they span data centers), whether LDAPS certificates must be issued and distributed, how many group-to-role mappings you need, and whether password writeback is in scope. Ask for a fixed-scope quote that states each driver as an assumption, so you can see what changes the price. Recurring costs are mostly your own infrastructure and the time your team spends on FreeIPA and authentik upgrades, which is separate from the one-time build.
What does the work need from our team?
The engagement needs a few named people with access to the systems involved. You will need a FreeIPA administrator who can create a service account, review the directory tree and confirm which users and groups should be visible to authentik. You will need an authentik administrator who can review the source configuration and mappings, and someone who manages DNS and certificates so authentik can reach the FreeIPA servers over the network and trust their certificates. You also need a test group of users who can confirm logins after each change. Before work starts, confirm which FreeIPA server authentik should connect to, which network paths are open, and who approves changes to production directories. Those answers shape the quote more than almost anything else.
Does authentik need to write passwords back to FreeIPA?
No, not for basic sync. authentik's LDAP source only creates or updates objects inside authentik. It does not change objects on the LDAP server. Password writeback is a separate option, and it needs the raw password, so it is a decision to make deliberately. Choose writeback only if users must change their FreeIPA password through authentik and expect that change to apply everywhere FreeIPA authenticates. Without writeback, password validation can still run against FreeIPA, so users keep one password. Writeback adds a security review, a secure LDAPS path and a rollback plan, which raises the effort. Decide this before the quote so that scope and risk are clear in writing.
What breaks most often in FreeIPA to authentik sync?
Most failures come from a short list of causes that you can check before go-live:
- The bind account lacks read access to the users or groups in the search base, so syncs look successful but return few objects.
- LDAPS fails because the certificate chain is not trusted by authentik, or because the name in the certificate does not match the server address.
- The authentik server cannot reach a FreeIPA replica, usually because DNS resolution differs between the authentik container and your hosts.
- Group membership does not match the group mapping, so users sign in without the roles you expected.
- A FreeIPA replica is out of step, so authentik reads stale data depending on which server it contacts.
Test each item on a non-production copy, and record which FreeIPA server and bind account each source uses so you can trace a failure quickly.
Does the FreeIPA replication topology change the sync design?
Yes. FreeIPA is a multi-master directory, so authentik can point at one server, but that server becomes a dependency for every sign-in that depends on sync. FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter and no more than four replication agreements per replica. Plan which replica authentik uses, how it fails over if that replica is unavailable, and how you will confirm replication is healthy before a sync runs. If FreeIPA spans several data centers, the design includes latency, certificate distribution to each site and the ordering of changes. Ask for the replication topology in the scope so the quote reflects it.
Can FreeIPA users sign in to authentik with their FreeIPA passwords?
Yes, when the LDAP source is configured to validate passwords against FreeIPA, users sign in to authentik with the same password they use for FreeIPA. authentik checks the password through the LDAP bind rather than storing it, which keeps one credential for users. Confirm the exact behavior with the authentik LDAP source documentation for your version, including how the account is linked after the first sign-in and what happens when a user is disabled in FreeIPA. Also test MFA. FreeIPA has its own OTP support, and if FreeIPA holds the second factor, decide where that check happens so users are not asked twice or left unprotected.
Running FreeIPA sync after go-live
Once the FreeIPA source is live, the first decision is how often the sync runs and who sees the result. An LDAP source only creates or updates objects in authentik, so a scheduled sync can change who can sign in, which groups they belong to and which applications they reach, but it never writes back to FreeIPA unless password writeback is enabled separately. Set the sync schedule in the source settings, record which FreeIPA service account and base DN it uses, and confirm that a deleted or disabled FreeIPA user is handled the way your offboarding process expects. Each run should be reviewed in the authentik event log and in the sync status shown on the source, with alerts for failed runs and for sudden drops in user or group counts. A large unexpected drop usually points to a changed search base, a locked service account or a directory outage, not to real departures.
FreeIPA backup and restore events can change object state in authentik without any change in authentik itself. Restoring a backup can roll users, group memberships, password policies or disabled flags back to an earlier point, and authentik will then sync that older state on its next run. The FreeIPA backup documentation also warns that restoring an outdated backup into an active replica topology can break replication, and that the first server handles certificate renewal and CRL publication by default. Add a step to the FreeIPA restore runbook that forces a full authentik sync after any restore, compares group membership and disabled-account counts against the pre-restore baseline, and confirms replication health before the authentik sync is trusted. Ask your FreeIPA administrators to tell the authentik owner before any restore or topology change, because the order of those steps decides whether the sync result is correct.
Upgrades need the same discipline as the directory itself. Track the authentik versions that still receive security fixes in the authentik security policy, which currently lists 2026.5.x and 2026.8.x as supported, and plan upgrades before a line leaves that list. The project announces security releases at least 24 hours in advance, so the runbook should name who watches for that notice and who can schedule a window. Test each upgrade against a copy of the production database with the FreeIPA source enabled, check that the sync still matches users and groups by the same attributes, and review the release notes for changes to LDAP source behavior. Confirm with your FreeIPA team any upgrade or change to 389 Directory Server or the FreeIPA version, because schema or access control changes can alter what the service account can read. Keep a documented rollback that restores the authentik database to a point before the upgrade.
