When authentik's Kerberos source fits your directory
If you run an MIT Kerberos or Active Directory KDC and want authentik in front of your applications without moving every password into a new store, the authentik Kerberos source is the component to evaluate. It can act as a password backend, as a directory source that syncs users from the KDC, or as a SPNEGO login path for browser single sign-on. It has been a preview feature since 2024.10, which matters for how much production weight you place on it. These three roles are chosen separately, so you can enable the password backend without syncing users or enable SPNEGO without changing where passwords are checked. This page covers the first two roles, which together form the integration method for applications that sign users in through authentik.
The fit question starts with where credentials must be verified. In the password backend role, authentik passes the password check to the KDC, so the KDC stays the authority for password policy, lockout and expiry, and authentik stores no copy of the secret. In the directory role, authentik creates local user records from KDC principals, which means you must decide which principals are imported, how they map to authentik attributes and who owns the accounts after creation. Confirm with your identity team whether they expect authentik to be the system of record for any attribute, and whether service principals or disabled accounts should be excluded from the sync.
Before committing, check three things in your own environment rather than in a generic checklist. First, confirm that your KDC realm, its administrative policies and the realm name in your DNS match what authentik will use. Second, decide whether the preview status is acceptable for the applications involved, and ask the vendor for the current status and known limitations of the source in the release you plan to run, since the authentik Kerberos source documentation is the authoritative reference. Third, plan a fallback login path for the applications affected, because a preview component that fails during a KDC outage can lock out users who depend on it.
What the KDC, network and authentik need before you start
The Kerberos source depends on three systems agreeing with each other: the KDC, the network path to it, and the authentik release you run. Work through these cards before you configure anything, so that failures later point to a clear cause.
Confirm the KDC type and version
Identify whether the KDC is MIT Kerberos, FreeIPA or an Active Directory domain controller, and record its exact version. Directory sync and password validation depend on which attributes and encryption types the KDC exposes. Ask your Kerberos administrator which realm names and admin accounts are authorized for integration work, and confirm the realm name matches your DNS domain conventions.
Create the service principal and keytab
authentik needs a service principal in the realm and a keytab file that holds its key. Create the principal with a dedicated name, restrict its rights to what the source needs, and store the keytab with file permissions limited to the authentik service account. Treat the keytab as a high-trust secret: anyone holding it can impersonate the service, so record who rotates it and how.
Check DNS resolution
Kerberos relies on hostnames to locate the KDC and to build service principal names. Confirm that the authentik server and worker resolve the KDC and any replicas by fully qualified name, both forward and reverse, from inside the same network namespace the containers use. Mismatched or missing records produce authentication errors that look like password problems.
Synchronize clocks
Kerberos rejects tickets when clocks drift beyond the realm's allowed skew. Verify that the KDC, the authentik server and the authentik worker all sync to the same reliable time source. Container hosts often inherit time from the physical host, so check the host configuration rather than assuming the containers are correct.
Test reachability from server and worker
Both the authentik server, which handles browser login, and the worker, which runs background directory sync, must reach the KDC on the required ports. Test each container separately, since firewall rules and Kubernetes network policies often allow one and block the other. Run a test from each to the KDC and to any replica, and document the results before you schedule the source.
Match the authentik release and read the preview notes
Run a release in the supported lines, which the security policy lists as 2026.5.x and 2026.8.x, so you receive security fixes. The Kerberos source has been a preview feature since 2024.10, so confirm which of its capabilities your chosen release supports before you commit to password backend, directory sync or SPNEGO login. Plan a lab test on the same version you will run in production.
How to configure the Kerberos source step by step
This sequence takes a Kerberos realm from a service account on the KDC to a verified password login and a directory sync in authentik. Each step ends with a check you can run before moving on.
Create the service account and keytab on the KDC
The KDC administrator creates a dedicated service principal for authentik and exports a keytab for it, then restricts the keytab file to the account that runs authentik. Confirm the exact principal naming and keytab format with your KDC vendor or your own environment, since MIT Kerberos and Active Directory differ in how they handle service accounts. The step is done when the administrator can obtain a ticket for the service principal from the keytab on a host that can reach the KDC, using a non-interactive
kinittest. Record the principal name and keytab location for the next step.Make the authentik host trust the realm
Confirm that the authentik server and worker containers can resolve the KDC hostnames and reach the Kerberos ports on each KDC, including any replicas. Check the time sync between the authentik host and the KDC, because Kerberos rejects tickets when clocks drift too far apart. Verify the Kerberos configuration file that authentik will read, using the file path your deployment method documents. The step is done when a test lookup from inside the authentik container reaches each KDC address you plan to configure.
Define the realm and KDC addresses in authentik
In the authentik admin interface, create a Kerberos source and enter the realm name, the KDC addresses, and the service principal and keytab details from the first step. Keep the realm name in the form your KDC uses, since it is case-sensitive in most Kerberos setups. Save the source but leave user matching and enrollment settings for the next steps. The step is done when the source saves without a validation error and shows as enabled in the source list.
Choose password backend or directory sync
Decide how authentik should use the KDC: as a password backend, where users keep local authentik accounts and authentik checks passwords against the KDC, or as a directory source, where authentik syncs users from the KDC. The choice determines whether you need the sync scope in the next step, and it affects where password changes and account disabling happen. Document the decision and the owner of each user attribute before you enable the sync. The step is done when the decision is written down and the source settings match it.
Set the sync scope and attribute mapping
If you chose directory sync, limit the scope to the principals or organizational units that should appear in authentik, and map the username and display name attributes the source provides. Keep the scope narrow for the first run so that service accounts and disabled principals do not create active users. Confirm the attribute names with your KDC administrator, since they depend on the directory behind the KDC. The step is done when the source preview or dry run lists only the expected principals.
Test a password login
Sign in to authentik with a test principal whose password is held by the KDC, using the source as the password backend. Use a principal that was not created by hand in authentik, so the test proves the KDC check. Also test one wrong password and one locked or disabled principal, and confirm that authentik rejects both. Check the authentik event log for the attempt and the source name. The step is done when the valid login succeeds and both negative cases are refused and logged.
Run a directory sync and confirm users appear
Start a sync from the Kerberos source and wait for the run to finish, then open the user list in authentik. Confirm that the expected principals appear with the mapped attributes, and that group or disabled-account handling matches your decision from the earlier step. Run the sync a second time to confirm it updates existing users rather than duplicating them. The step is done when the user count matches the scope you set and a second run creates no duplicate accounts.
Confirm the source is in preview scope
The Kerberos source has been a preview feature since 2024.10, so review the authentik documentation for the version you run before you rely on it in production. Check the release notes for your target version and record any known limitations for password handling or sync behavior. Ask your authentik contact or review the project's documentation for the supported status of this source in your edition. The step is done when the team has a written note of the version tested and the limitations that apply.
Why password backend, directory sync and SPNEGO are separate decisions
The first decision to make is that SPNEGO browser login and the server-side roles of the Kerberos source are separate choices. SPNEGO depends on the user's workstation holding a valid Kerberos ticket and on each browser being configured to send it, so its failures usually sit on client machines, in browser policy and in DNS names that the browser must resolve correctly. The password backend and directory sync run inside authentik's server and worker containers and talk to the KDC over the network. A team that treats these as one feature will struggle to tell whether a failed login came from a missing ticket on a laptop or from a misconfigured source on the server.
Because the source lets you enable these roles independently, you can turn on one, test it, and leave the others off. A typical sequence is to validate password checks against the KDC first, since every login path in authentik can be tested with a known test account, then add directory sync once the attribute mapping is correct, and add SPNEGO last, once the browser fleet is known to behave. Before you start, confirm in the Kerberos source documentation which settings each role requires and whether a role can be disabled after it has been enabled without affecting users already linked to the source.
Separation also makes rollback predictable. If SPNEGO causes trouble, you can disable it for affected browsers or groups while password sign-in continues to work, and the directory sync can be paused without changing how passwords are checked. Write down, for each role, the test that proves it works and the steps that restore the previous state, and rehearse that rollback in a non-production authentik instance. Confirm with the vendor and your own environment that the Kerberos source is still a preview feature for the version you deploy, because preview behavior can change between releases and should be verified before production use.
Choosing the source role for your environment
In this role, authentik hands password checks to the Kerberos KDC, and the KDC remains the only place passwords are verified and changed. Users keep their existing Kerberos principal, and authentik uses the source to validate the password during its own login flow. This suits organizations that want one password authority and want authentik to sit in front of applications without taking over credential management.
- Password ownership: The KDC owns the password. authentik does not hold a copy of the secret it can compare against, and password changes continue to happen in the directory.
- Local storage: authentik keeps its own user record and the link to the source, so application attributes and group memberships are managed in authentik.
- Suited applications: Web applications that rely on authentik for OIDC or SAML sign-in, where users already know their Kerberos password.
- Operational dependency: Each login depends on the KDC being reachable from the authentik server and worker, so network paths and KDC availability need planning.
- Lockout behavior: Lockout and password policy come from the KDC, so confirm how failed attempts are counted across both systems.
Before you choose this role, confirm with your directory team which password policies they enforce and whether any service accounts need password checks from authentik.
In this role, authentik imports users from the KDC as a directory source, so accounts appear in authentik and can be assigned to applications, groups and policies. The KDC still owns the principal and its password, but authentik creates and maintains a local representation of each user. This suits organizations that want authentik to be the place where application access is decided, while the directory remains the system of record for identities.
- Password ownership: The KDC still owns the password, and authentik should not be treated as the place where credentials are set.
- Local storage: authentik stores the synced user record, attributes and group membership that the source provides, which means personal data leaves the directory and lives in authentik's PostgreSQL database.
- Suited applications: Multi-application environments where access rules are managed in authentik and need stable user objects to attach to.
- Deprovisioning: Confirm how users removed from the KDC are handled in authentik, because local records may persist unless your configuration removes them.
- Attribute mapping: Decide which KDC attributes you need and map only those, which limits what authentik stores.
Ask your team to document which attributes are synced and how sync results are reviewed, since this becomes part of your data inventory.
SPNEGO lets a browser present a Kerberos ticket that the user already obtained, such as from a domain-joined workstation, so the user signs in to authentik without typing a password. This role depends on the browser, the client's Kerberos configuration and the network path, and it is separate from using the KDC as a password backend. It suits internal users on managed devices who reach authentik from within the corporate network.
- Password ownership: The KDC issues the tickets and owns the credential. The user does not enter a password at the authentik login page when SPNEGO succeeds.
- Local storage: authentik records the authenticated identity and the session it creates, and the stored data depends on how the source is linked to users.
- Suited applications: Internal portals used from managed desktops, where browser settings can be controlled centrally.
- Fallback path: Plan a password or other sign-in method for users on unmanaged devices, external networks or browsers that do not negotiate Kerberos.
- Browser configuration: Trusted sites and the hostname used for authentik must match what the browsers and DNS expect, so test each browser family you support.
Confirm with your desktop team which browsers and operating systems are in scope, and test SPNEGO and fallback sign-in on each before users depend on it.
Mapping Kerberos principals and attributes to authentik users
This table compares each part of a Kerberos principal and its KDC account with the authentik user fields and groups it can feed. Read the KDC side as what Kerberos itself stores and the authentik side as where that value lands. The main takeaway is that a KDC holds few profile attributes and no group model, so confirm names, email and groups against the source documentation and your directory.
| Mapping area | Kerberos side | authentik side | What to confirm |
|---|---|---|---|
| Username | Principal name in the form user@REALM | Username field, usually the primary component | Whether the realm is stripped and how identical short names in two realms are handled |
| Realm | Realm portion of each principal, one per KDC realm | Scopes the source; not usually a separate user field | How trusted or cross-realm principals are accepted or rejected |
| Display name and email | Often absent from the KDC; typically held in AD or LDAP | Name and email user fields | Whether your KDC exposes these attributes at all and where to read them |
| Account status | Lockout, expiration and password policy settings | Active flag and login eligibility | Which expiry and lock states sync and which authentik enforces at login |
| Group membership | MIT KDC has no group model; AD and FreeIPA groups sit in LDAP | Group assignment, only if a group source is configured | Where group data originates in your topology and how it stays current |
| Password verification | Keys stored in the KDC database, not as readable passwords | Password checked against the KDC at sign-in | Whether any credential is stored locally after a successful login |
| Service principals | Host and service accounts such as HTTP/hostname | Should be excluded from user sync | Filter rules that keep service accounts from becoming users |
Securing the keytab, the KDC link and the preview source
A Kerberos source gives authentik a path to password checks and directory data held by a KDC, so the keytab, the network path to the KDC and the people who can edit the source all become part of your trust boundary. The cards below cover what to lock down before go-live and what to monitor afterward, plus the risk acceptance and rollback plan that a preview feature requires.
Protect the keytab file
The keytab holds long-term Kerberos keys for the service principal authentik uses, so anyone who reads it can act as that service. Store it only on the authentik hosts that need it, with file permissions limited to the service account running authentik, and keep it out of container images, Git repositories and shared volumes. Confirm who can read the file on every host and in every backup set.
Rotate keys on a documented schedule
Plan keytab rotation as a change with a named owner, not an occasional task. Record the key version numbers before and after each rotation, test a password check and a SPNEGO login against the new key, and keep the previous keytab until the change is verified. Ask your KDC team how they handle key version history so a rotation does not invalidate tickets that are still in use.
Give authentik a least-privilege service account
Create a dedicated service principal for authentik rather than reusing an administrator or a shared application account. Grant it only the directory read rights needed for the user sync you configured, and limit password-check use to the authentication path. Document which attributes authentik reads, so a later change to the directory schema is reviewed against the source configuration.
Encrypt and pin the KDC connection
Kerberos authentication depends on the network path between authentik and the KDC, so reach the KDC over a link you control and restrict it with firewall rules to the authentik hosts. Confirm that the directory traffic used for sync is encrypted, and that the KDC hostnames authentik uses resolve to the intended servers. Treat any path that crosses an untrusted network as out of scope for a password backend.
Check clock skew before go-live
Kerberos rejects tickets when the clocks on the client, authentik host and KDC differ by more than the allowed skew, and the failures often look like random password or SPNEGO errors. Synchronize every host with the same time source, and test a login from each authentik node after any host restart or NTP change. Ask the KDC team which skew limit their realm enforces.
Restrict who can edit the source
A Kerberos source that accepts passwords or syncs users can change who is allowed to sign in, so editing it should be a privileged action. Limit source edits to a small admin group, require that changes go through your normal review process, and log every edit. Review the property mappings periodically, because a changed mapping can grant access to users that the directory never meant to expose.
Monitor failed password checks
Failed password checks against the KDC can show a lockout attack, a misconfigured client or a service account with a broken key. Forward authentik authentication events to your log platform, set alerts on bursts of failures per account and per source IP, and compare them with KDC-side failure logs. Confirm which events authentik emits for Kerberos checks in the version you run, since the preview feature may change them.
Accept the preview risk and plan rollback
The Kerberos source has been a preview feature since 2024.10, so record a formal risk acceptance that names the owner, the accepted scope and the review date before production use. Keep local authentik credentials or another working login path available, and document how to disable the source and restore the previous login flow. Test the rollback on a staging instance before each authentik upgrade.
Common Kerberos source failures and how to fix them
This table lists the failures teams most often hit when a Kerberos source sits behind authentik, with the likely cause and a generic fix for each. Read each row by starting with the symptom, then confirm the cause in authentik's logs and a test login before changing configuration.
| Failure | Likely cause | Fix and check |
|---|---|---|
| Tickets rejected or logins fail intermittently | Clock skew between the authentik host, the KDC and the client, so Kerberos ticket timestamps fall outside the allowed window | Synchronize all three systems to the same reliable time source, then repeat a test login. Check authentik's worker and server logs for clock or ticket-validity errors. |
| Source fails to connect or authenticate at startup | Realm name or KDC hostname does not match what the KDC expects, often a short name, wrong case or a load balancer name without matching principals | Confirm the realm string and the KDC host name the KDC advertises, and use the same values in the source. Test resolution and reachability from the authentik containers, not only from your workstation. |
| Browser SPNEGO login fails after a password change | Keytab key version number (kvno) no longer matches the service principal in the KDC after a password reset or key rotation | Regenerate and redeploy the keytab for the service principal, then replace the old file. Verify with a fresh browser login and review the server log for decryption or key errors. |
| Hostname lookups or KDC discovery fail | DNS SRV records for the KDC or domain controllers are missing, incomplete or not resolvable from the container network | Check that the SRV records for Kerberos resolve from inside the authentik containers. Compare results across all KDC replicas, since partial records can cause intermittent failures. |
| Sync imports fewer users than expected | Scope filters, search base or group restrictions exclude accounts that the team assumed were included | Compare the directory search base and filter with a known set of expected users, then run a sync and count the results. Look for skipped-object messages in the sync log before widening the scope. |
| Users appear but cannot sign in with passwords | Password backend is enabled but the account lacks the expected principal form, or the realm used in the username does not match the source | Check how usernames map to principals in the source settings, then confirm the same principal authenticates with the KDC directly. Use one test account for each change. |
| Changes do not take effect after editing the source | Cached sync or session state from earlier settings, or a sync job that has not run since the change | Trigger a sync, then sign in again with a new session. Confirm the source settings saved correctly in the log before testing. |
What buyers ask before connecting Kerberos to authentik
What drives the cost of connecting a Kerberos KDC to authentik?
The main drivers are how many KDCs and realms are involved, whether the source acts as a password backend, a directory source, or both, and how much testing the change needs before it reaches users. A single MIT Kerberos realm with a clean principal layout is a very different job from several Active Directory domains with cross-realm trusts and existing SSO workflows. Scope also depends on whether browser SPNEGO login is required, because that adds client browser configuration and reverse proxy handling. Costs are one-time for design, build and testing, and recurring only if you retain DeployOpen for support or upgrades. Ask for a written scope that lists each realm, each source mode, each test case and each client type before you compare quotes.
How long does a Kerberos source project take?
Duration follows the scope, not the product alone. A project covering one realm, password backend use and a short test plan is shorter than one that adds directory sync, several realms, SPNEGO and an upgrade rehearsal. Timing also depends on how quickly your KDC administrators can provide a test realm, service principal details and keytab handling approval. DeployOpen does not publish a timeline. The written scope sets the schedule, and it should name the dependencies on your side, such as change windows and access approvals, so that delays are visible early.
Can our internal team set up the Kerberos source without outside help?
Yes, a team with working knowledge of authentik and of their KDC can build it, provided they have time to test. The hard parts are usually not the authentik form fields but the Kerberos side: service principals, keytab creation and rotation, time synchronization, DNS and the password policy that will govern logins. Teams without recent experience in both systems often underestimate the testing needed to confirm that password checks, directory sync and browser login behave correctly together. Ask yourself whether you can staff a named engineer for both systems and run a test realm before production. If not, a fixed-scope engagement can cover the build and the handover.
What access and people do we need to provide for the project?
You need administrative access to the KDC or the Active Directory domain controllers needed for the source, a dedicated test realm or test domain that mirrors production naming, and a named owner who can approve changes to the KDC. You also need an authentik administrator account for the build, a DNS owner for the hostnames that clients will use, and a contact for your change process. If browser SPNEGO is in scope, add the owner of the reverse proxy and the endpoint configuration for workstations. Confirm these in writing at the start so that the first week is not spent waiting for access.
Does the preview status of the Kerberos source affect production use?
The source has been a preview feature since 2024.10, so you should treat it as a feature that may change between releases and verify its behavior against your version before production. Preview status is a reason for a stronger test plan, a pinned authentik version and a documented rollback path, not an automatic reason to avoid it. Check the authentik Kerberos source documentation and the release notes for the version you run, and confirm with the project which parts you intend to rely on. Your risk owner should decide whether the preview status is acceptable for each use: password backend, directory sync or SPNEGO login.
Should we use Kerberos as a password backend, a directory source, or SPNEGO?
Each mode solves a different problem, and the choice changes the effort. A password backend checks credentials against the KDC when users sign in, so the KDC stays the authority for passwords. A directory source syncs users from the KDC into authentik, which adds mapping and sync testing. SPNEGO lets domain-joined browsers sign in without typing a password, which adds client, browser and proxy configuration. Many teams start with the password backend and add SPNEGO later after the core path is proven. Document which mode you need for each application before you commit to a scope.
Does a Kerberos KDC integration matter for compliance evidence?
It matters for the access control and authentication evidence you will need to show, because the KDC often remains the record of password policy and account lifecycle. Keep records of which authentication path each application uses, who approved the KDC access, how service credentials are stored and rotated, and how test results were recorded. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports or certifications. Ask your assessor which control evidence they expect before the design is final.
When FreeIPA is the better KDC to put behind authentik
Choose FreeIPA as the Kerberos backend when you need a Kerberos KDC that comes with its own directory, certificate authority and host policy, and you do not already run Active Directory or a maintained MIT Kerberos realm. FreeIPA combines 389 Directory Server, an MIT Kerberos KDC and the Dogtag certificate system in one product, so the KDC that authentik authenticates against is also the store that holds users, groups and keytabs. It is licensed under GPL-3.0-or-later and has no paid edition of its own, which means the software cost is zero, while the work of operating it stays with your team or your partner. Plan that operating cost before you compare it with an Active Directory domain you already maintain.
Before you point authentik at a FreeIPA KDC, confirm the running version. FreeIPA 4.13.4, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and it hardened authentication checks across the API. Check the installed package version on every IPA server, not only the first one, and read the FreeIPA 4.13.4 release notes against your current build. If you run an older release, schedule the upgrade before you expose the directory to a new authentik service account.
FreeIPA is a related option, not a requirement. If your organization wants Linux identity, host access policy and certificates in one place, the DeployOpen FreeIPA page covers that deployment scope. If your need is only a Kerberos password backend for authentik, a standalone MIT Kerberos realm or an existing Active Directory domain may be the smaller change, so compare the replica, backup and upgrade work for each option in writing before you choose.
How DeployOpen scopes and delivers the Kerberos integration
DeployOpen treats the Kerberos source as a decision about where passwords are checked and where users come from, not as a switch to flip. We scope the integration in writing against your KDC, your authentik version and the preview status of the source, then build and verify it inside infrastructure you control.
How we scope
- Confirm whether the KDC serves as password backend, directory source, SPNEGO login, or a combination.
- Record the KDC type, whether MIT Kerberos or Active Directory, and the realm and DNS layout.
- Agree in writing how the preview status of the source is accepted, tested and supported for your environment.
How we build
- Configure the Kerberos source in a non-production authentik instance first, with test accounts and service principals.
- Test password checks, user sync scope, attribute mapping and fallback behavior for lockouts and expired passwords.
- Keep SPNEGO browser login as a separate, tested step with browser and network prerequisites documented per client.
How we hand over
- Deliver configuration, keytab handling, sync settings and a runbook covering each source function.
- Document the verification results, known preview limitations and the rollback path to your previous login method.
- Walk your identity and platform engineers through the operating model before cutover to production.
How we support
- Support is agreed in the written scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Re-test the integration when authentik or your KDC is upgraded, since preview features can change between releases.
- Ask for a quote built from the written scope, which sets out the one-time work and any recurring retainer separately.
