authentik Kerberos and SPNEGO single sign-on

How authentik Kerberos and SPNEGO single sign-on works

If you run a Kerberos realm or Active Directory and want domain-joined users to reach authentik-protected applications without a password prompt, authentik's Kerberos source can fit, provided your browsers, DNS and reverse proxy can carry the negotiation. The source is designed for transparent browser login: when a user on a joined machine opens an application, the browser uses SPNEGO (the Negotiation mechanism) to present a Kerberos service ticket to authentik, and authentik maps the authenticated principal to a local user. Users who are not on a domain-joined machine, or whose browser is not configured to negotiate, still need a fallback login path, so plan for both.

The Kerberos source has a second role: it reads users from the KDC using a keytab, which is a file holding the service principal's long-term keys. That keytab, the service principal name and the realm settings together determine which accounts can sign in and how their names map to authentik usernames. Treat the keytab as a secret with restricted file permissions and a rotation plan, because a leaked keytab lets an attacker impersonate the service. Exact source fields, sync options and the browser policy that allows negotiation must be confirmed against the authentik sources documentation for the version you run. The supported versions receiving security fixes are 2026.5.x and 2026.8.x, so confirm your release sits in that line before you design around the source's behavior.

Before you build, confirm three things with your Kerberos or Active Directory administrators: the realm and KDC addresses reachable from the authentik server, the service principal and keytab procedure your directory policy allows, and whether your reverse proxy forwards the Authorization header and handles the negotiation challenge correctly. Proxy caching is a known cause of broken negotiation, since a cached 401 or response can stop the browser from completing the exchange, so the reverse proxy configuration needs its own test. Expect the verification to include a domain-joined test account, a non-domain account that must fall back cleanly, and a check of the sync results against a known set of users.

What you need before enabling Kerberos sign-in

Kerberos sign-in in authentik depends on several parts working together: a supported release, a healthy deployment, a KDC or Active Directory realm, a keytab, and clean name resolution and clocks. Gaps in any one of these tend to show up as negotiation failures in the browser, so confirm each before changing the login flow.

A supported authentik version

Run a release that still receives security fixes. The authentik security policy lists 2026.5.x and 2026.8.x as supported, so plan any upgrade to one of those lines before the Kerberos source is built. Check the current patch level against the GitHub releases page, since the project announces security releases at least 24 hours in advance and your change window should allow for that.

A healthy authentik deployment

Kerberos negotiation runs through the server container, so the core service, the worker container and PostgreSQL must all be running and reachable. Confirm the worker processes background tasks such as directory sync, and that PostgreSQL has connection headroom for your user count. Review the architecture page to map which container handles which function before you troubleshoot.

A KDC or Active Directory realm

Decide which Kerberos realm authentik will trust, whether an MIT KDC, FreeIPA or Active Directory. Create a service principal for the HTTP service name that matches the hostname users type in their browsers. Confirm the exact principal naming pattern with the authentik sources documentation, because a mismatch between the principal and the browser URL is a common reason negotiation fails silently.

A keytab created and protected

The keytab holds the long-term secret for the HTTP principal, so generate it on the KDC, copy it to authentik through a controlled channel, and restrict read access to the service account that runs the containers. Confirm the required keytab format, encryption types and file location with the authentik sources documentation. Record who holds copies and plan rotation with the KDC key version.

DNS and time synchronization

Kerberos resolves service principals by name and rejects tickets when clocks drift beyond the realm tolerance. Make sure the authentik hostname resolves forward and reverse to the address users reach, and that the authentik host, the KDC and the browser clients all sync to the same time sources. Test both before blaming authentik for a ticket error.

Browser policy on domain-joined machines

Transparent sign-in only works when the browser sends the Negotiate header. Confirm that the authentik URL falls within the intranet or trusted sites zone on managed Windows clients, and that the browser's delegation and authentication settings allow it. Test with a domain user on a machine that is joined to the realm, and keep a documented fallback to password login for unmanaged devices.

Configuration sequence for the Kerberos source

This sequence takes a working authentik deployment from a confirmed version to a Kerberos source that signs domain-joined users into browser applications without a password prompt. Each step closes with a check you can run before moving on.

Confirm the authentik version and deployment
Confirm that your authentik version is one that receives security fixes, which the project's security policy lists as 2026.5.x and 2026.8.x at the time of writing, and that the instance is reachable over HTTPS at the hostname your users will browse to. Check the deployment against the Docker Compose or Kubernetes installation guide, since the server and worker containers and PostgreSQL must all be healthy before you change identity settings. Ask your team to confirm the exact version against the releases page before you start. Done when the administration interface loads over HTTPS and the server, worker and database report healthy.
Create the service principal and keytab on the KDC
On the Kerberos Key Distribution Center, your directory or Active Directory administrator creates a service principal for the HTTP service under the hostname users will reach, then exports its key to a keytab file. Restrict read access to the keytab to the authentik service account and keep a copy in your secrets store, because a leaked keytab allows impersonation of the service. Record the principal name and the keytab location exactly as they will appear in the source settings. Done when the principal lists in the KDC and the keytab file can be read by the authentik process but not by other local users.
Add the Kerberos source in authentik
In the authentik administration interface, an administrator creates a Kerberos source and enters the realm, the service principal and the keytab details, plus the KDC and DNS settings your environment needs. Use the sources documentation for the exact field names and options, because they change between releases and this page does not reproduce them. Decide now whether the source will also sync users from the KDC, since that determines which user attributes authentik receives. Done when the source saves without validation errors and appears in the source list as enabled.
Bind the source to the login flow
Add the Kerberos source to the authentication flow that users pass through, and set its position so that negotiation is attempted before the password form is shown. Leave the password fallback enabled while you test, so that a failed negotiation does not lock out administrators. Confirm that the flow used by your applications is the same flow you edited. Done when a test request to a protected application starts the flow and the flow lists the Kerberos source as a stage option.
Configure browser trust and negotiation on domain-joined machines
On a pilot set of domain-joined Windows workstations, your endpoint team adds the authentik hostname to the browser's trusted or intranet zones so the browser will offer Kerberos tokens to it, and checks that the browser's negotiation settings allow SPNEGO for that site. Confirm that the workstations obtain a ticket for the service principal from the KDC before you test in the browser. Compare the browser configuration with the browser vendor's enterprise policy documentation. Done when a pilot user's workstation holds a valid ticket for the service principal and the browser is configured to negotiate with the authentik hostname.
Test with a clean browser session
Sign out of authentik, close all browser windows, and sign in from a pilot workstation with a fresh session. Expect the browser to complete negotiation without a password prompt and authentik to create or match a user from the KDC. Then check the authentik event log for an entry showing that the Kerberos source accepted the ticket, and confirm the user record carries the expected username and groups. Repeat the test from an account that is not a domain user to confirm the fallback login still works. Done when the pilot user reaches the application without entering a password and the log shows an accepted ticket.
Check for reverse proxy caching before rollout
Place the deployment behind your reverse proxy and repeat the clean-session test, since a proxy that caches the authentication response or strips the Authorization header can break negotiation for some users and not others. Review the proxy configuration with the network team and confirm that it passes the negotiation headers through to authentik unchanged. Ask your vendor or the authentik documentation which headers and cache rules apply to your proxy product. Done when repeated clean-session tests through the proxy succeed for several pilot users and the proxy logs show the negotiation headers reaching authentik.

How Kerberos principals and directory attributes map to authentik users

This table compares each identity element, from the KDC principal to group membership, with the authentik user field it feeds and who sets its value. Read it as a checklist: the first column names the element, and the remaining cells show where it lands in authentik and what you must confirm before go-live. The main takeaway is that the username and realm handling decide whether SPNEGO logins find the right account.

Element	Where it lands in authentik	What to confirm before go-live
Kerberos principal (user@REALM)	Matched against the authentik username through the source's user matching settings	Confirm the exact principal format the source expects and whether the realm is stripped before matching
Realm and domain suffix	Determines whether `user@EXAMPLE.COM` and `user` resolve to the same account	Confirm the realm casing and whether a suffix is appended or removed in the source configuration
Service principal and keytab	Used by the source to decrypt SPNEGO tokens sent by the browser	Confirm the service principal name, keytab file path and key version with the KDC administrator
Email attribute	Copied to the authentik user email field through a property mapping	Confirm the directory attribute name in your schema, typically mail in Active Directory or a FreeIPA equivalent
Display name attribute	Copied to the authentik user name field through a property mapping	Confirm which attribute holds the full name and whether given and family names are split in your directory
Directory group membership	Mapped to authentik groups, which applications use for access decisions	Confirm whether nested groups are expanded, and whether group names in the directory match the names your applications expect
Account state (disabled, locked)	Determines whether the authentik user can complete a Kerberos login	Confirm which directory attribute signals a disabled account and how often the source re-evaluates it

Why user sync from the KDC is a separate step from login

User sync from the KDC and browser negotiation are two separate operations, and they fail in different ways. Negotiation happens when a browser presents a Kerberos service ticket to authentik during sign-in, so it depends on the client being domain-joined, the browser trusting the right hosts, and the service principal being correct. Sync is a background read of accounts from the KDC, which depends on a credential that can query the directory. A team can have working transparent login while sync is stale, or the reverse, so each needs its own check before go-live. Confirm in the authentik Kerberos source documentation exactly which account attributes are read, how often sync runs, and whether it can create, update or disable users.

The keytab is the sensitive part of the sync path. A keytab file holds long-term secret keys for a principal, so anyone who reads it can obtain tickets as that principal. Treat it like a private key: restrict read access to the service account that runs authentik, keep it out of version control and general backups without equivalent protection, and record who holds copies. Plan rotation before the first deployment. Changing the principal's keys in the KDC invalidates older keytab entries, so the team needs a documented sequence for generating a new keytab, deploying it, confirming sync, and retiring the old file. Ask the KDC administrator which encryption types the realm issues, because the keytab must match them.

Account changes reach authentik only through the sync cycle, not through login. A disabled or locked account in the KDC may still be able to obtain a ticket until its ticket lifetime ends, and authentik will not reflect the change until the next sync. Before go-live, decide what happens to accounts that disappear from the KDC or are disabled there: whether authentik deactivates them, leaves them active, or flags them for review. Ask who owns departures, how quickly HR or the identity team removes access in the KDC, and whether authentik sessions and other application sessions need to be revoked. Test these cases with a disabled test principal and record the result.

Reverse proxy setups that keep negotiation working

In the simplest layout, one reverse proxy terminates TLS for the authentik hostname and forwards requests to the authentik server. Kerberos negotiation depends on the browser receiving an HTTP 401 with a WWW-Authenticate: Negotiate challenge, then sending back an Authorization: Negotiate header carrying the ticket. The proxy must forward the Authorization header unchanged and must not strip the WWW-Authenticate response header on the way back. Confirm the exact directives for your proxy with the authentik documentation and the proxy vendor's current guidance, since header handling differs between products.

Forward the Authorization header: Confirm that the proxy passes the Authorization request header to the upstream without modification.
Keep the challenge intact: Check that the 401 response and its WWW-Authenticate header reach the browser, not a proxy-generated error page.
Set forwarded headers consistently: Make sure the public host, scheme and client address the proxy sends match what authentik expects, so redirects return to the correct URL.
Disable caching on auth paths: Responses from the flow and source endpoints carry per-user state and must not be stored by the proxy.
Test with a domain-joined client: Sign in from a machine with a valid Kerberos ticket and confirm the login completes without a password prompt.

Before go-live, check that a second browser without a ticket still reaches the normal login form.

Organizations often run one reverse proxy in front of several applications, and some of those applications use authentik's forward auth through an outpost. In this layout, the proxy handles negotiation for the authentik hostname and also calls the outpost for every protected application. A caching rule written for static assets or for forward auth checks can therefore cache a negotiation response and serve it to a different user or a different browser. Keep the Kerberos-enabled authentik path and the forward auth paths in separate location blocks or routes, and review each one separately.

Scope caching rules narrowly: Apply caching only to static file paths, and confirm no global cache setting covers the authentik hostname.
Isolate the negotiation path: Route the authentik login path to its own block so forward auth settings do not change its header handling.
Watch shared Vary behavior: Confirm that responses differing by the Authorization header are not collapsed into one cached object.
Check outpost headers: Verify that forward auth identity headers are set by the proxy and cannot be supplied by the client.
Test each application path: Run a negotiation test and a forward auth test against separate applications after every proxy change.

In a shared proxy, the negotiation result for one user should never appear in another user's session, so verify this with two accounts.

When authentik runs in Kubernetes, traffic usually passes through an ingress controller, and sometimes a load balancer, before reaching the authentik service. Each hop can strip or rewrite the Authorization header, buffer responses, or apply its own cache and timeout behavior. Check which ingress controller and version your cluster uses, then confirm its annotations for passing authorization headers, handling 401 responses and disabling response caching for the authentik host. Because the Helm chart and ingress settings are maintained separately, review both when you upgrade either one.

Inspect every hop: Trace the request through the load balancer, ingress controller and service, and note where headers can change.
Set annotations per host: Apply negotiation-related annotations only to the authentik host so other ingress resources are not affected.
Confirm the forwarded host and scheme: Check that the public address reaches authentik, since wrong values break redirects after login.
Review ingress caching and buffering: Confirm the controller does not cache or buffer the negotiation exchange in a way that changes the response.
Retest after upgrades: Repeat the domain-joined sign-in test after any change to the chart, controller or load balancer.

Check the ingress controller documentation for the exact annotation names, because they vary by controller and version.

Security controls for Kerberos sign-in

Kerberos sign-in moves trust to a KDC, a keytab and a reverse proxy, so each of those becomes part of your security boundary. The cards below cover the controls that connect them, and the edition and version questions to settle before you rely on them.

Protect and rotate the keytab

The keytab holds long-term secrets that let the service account decrypt Kerberos tickets, so a copy in the wrong place lets someone impersonate users. Store it with restrictive file permissions on the authentik host, limit access to the operators who manage it, and keep it out of backups that are widely readable. Agree a rotation procedure with your KDC team, including how you regenerate the keytab and when old copies are destroyed. Confirm with your KDC administrators how key versions are handled during rotation so sign-in does not fail mid-change.

Least-privilege service account on the KDC

The service principal used by authentik should have only the rights needed to validate and issue service tickets for the SPNEGO endpoint, plus the directory reads needed for user sync. Avoid domain admin or broad delegation, and avoid sharing the account with other services. Review what the account can read and whether it can change passwords or group membership. Ask your directory team to document the account's permissions so the review can be repeated after upgrades.

Restrict which hosts reach the negotiation endpoint

The endpoint that answers SPNEGO negotiation is where a browser presents its Kerberos ticket, so it should be reachable only from the networks where domain-joined clients sit. Limit ingress at the reverse proxy and firewall to known client ranges, and confirm that the proxy passes the authorization header through unchanged. Test from both an internal domain-joined machine and an outside network to confirm the boundary behaves as you intend.

Control who can use local or password fallback

When Kerberos negotiation fails, users fall back to a password form or a local account, and that path bypasses the strength of Kerberos sign-in. Decide which accounts may use fallback, which groups are exempt from it, and whether administrators must always use a second factor. Record that decision in your access policy. Confirm in your authentik edition which flow and policy controls you can apply to the fallback stage before you rely on them.

Audit Kerberos logins

You need to show who signed in, from which host and through which source, and to detect failed negotiation patterns that suggest a misconfigured client or an attack. Forward authentik event logs to your central logging system and set retention to match your policy. Confirm whether enhanced audit logging, which the authentik pricing page lists as an Enterprise-only feature, is required for the events your auditors expect in the edition you plan to run.

Keep authentik on a supported version

Security fixes reach only the versions listed as supported, and the project announces security releases at least 24 hours in advance, so your change process must be able to respond at short notice. Plan a regular upgrade window, read release notes for changes to the Kerberos source and the reverse proxy path, and test negotiation after each upgrade. Confirm the current supported release lines against the security policy before you set your maintenance calendar.

Common failures when Kerberos sign-in breaks

This table pairs each symptom with its likely cause, a first fix, and whether the cause must be confirmed in your environment. Use it to triage a failing SPNEGO login before changing the authentik source, the reverse proxy or the KDC. Causes marked for confirmation depend on your browser policy, network layout and directory data, so verify them on your own hosts.

Symptom	Likely cause	First fix to try	Confirm in your environment
Browser shows repeated password prompts	The browser did not negotiate a Kerberos ticket, often because the authentik host is not in the browser's intranet or trusted site zone	Add the authentik hostname to the intranet or trusted sites policy and confirm the user holds a valid ticket for the service	Yes: check the browser policy delivered by GPO or MDM and the ticket cache on the client
Login works directly but fails only through the reverse proxy	The proxy strips or does not forward the Authorization header, or caches a 401 response that blocks the negotiation exchange	Pass the Authorization and WWW-Authenticate headers through and disable caching on the negotiate path	Yes: confirm the proxy product, its caching rules and the headers received by authentik
Users missing after sync from the KDC	The keytab principal lacks rights to read the target accounts, or the LDAP search base or scope excludes the users	Check the service account rights and widen the search base or scope to include the user container	Yes: confirm which OUs hold the accounts and what the sync service account can read
Clock skew errors during negotiation	The authentik host, the client and the KDC disagree on time beyond the Kerberos tolerance	Synchronize all hosts against the same trusted time source and retest	Yes: measure the offset on each host and confirm the tolerance set in your KDC policy
Login succeeds but the username does not match the expected account	The realm suffix or principal format differs from the username format authentik expects, such as user@REALM versus DOMAIN\user	Align the username mapping with the realm and the format used by existing accounts	Yes: compare the principal name on the keytab with the attribute authentik stores for the user
Keytab rejected or decryption failures	The keytab was generated for a different service principal, key version or encryption type than the one in use	Regenerate the keytab for the exact service principal and confirm the key version number	Yes: confirm the principal, key version and encryption types supported by your KDC

What teams ask before enabling authentik Kerberos SSO

How much effort does authentik Kerberos SSO take, and what drives it?

The effort depends on how many applications sit behind the sign-in, how the reverse proxy is laid out, how reachable the KDC is from the authentik network, and how much browser policy rollout the client needs. A single internal web application with one proxy and a test KDC is a small piece of work. Several applications across multiple proxies, plus Group Policy or browser settings pushed to many desktops, add review cycles and testing time. No duration is set here, so ask for a timeline that follows from a written scope that lists each of these factors.

Can an internal team set up Kerberos SSO without outside help?

An internal team with Kerberos, DNS and reverse proxy experience can do the work, and many do. The hard parts are usually outside authentik itself: service principal names, keytab creation with the right encryption types, clock sync, and proxy headers that the browser negotiation depends on. If your team has not run a KDC or changed proxy caching before, plan for a period of testing on non-production hosts. A partner is useful when you want the work scoped, documented and verified against your environment in writing before you commit.

What must the client provide before the work starts?

Expect to supply the following before work begins:

KDC administrator access, or a named administrator who can create the service principal and generate the keytab
A secure path for keytab handling, including who may hold the file and where it is stored
Test accounts on domain-joined machines in each browser and operating system you support
Rights to change the reverse proxy configuration and to cache or bypass settings in front of authentik
DNS records and certificates for the authentik and application hostnames

Confirm each item in the written scope, since missing access is one of the most common causes of delay.

What does Kerberos SSO cost to run, and what recurs?

Most of the cost is one-time: design, configuration, testing and documentation. Recurring items include keytab rotation when the service account password or key material changes, authentik version upgrades, proxy configuration reviews after upgrades, and monitoring of sync and login failures. Running costs also include the infrastructure hosting authentik and its PostgreSQL database. Ask any partner for a quote that separates one-time work from recurring support, and state whether a support retainer covers rotation and upgrade testing. DeployOpen does not publish prices, so the written scope and quote are the source of figures.

Is a support retainer needed after go-live?

A retainer is optional but useful when the Kerberos path is important to daily access. Negotiation failures often appear after browser updates, proxy changes or keytab changes, and a retainer gives a defined channel for those issues. Without one, your own team must watch authentik release notes and test each upgrade. Ask what the retainer covers, how fast issues are triaged, and whether upgrade testing on your configuration is included. Retainers are available from DeployOpen, and their terms are set in the written scope.

Does authentik Kerberos SSO require an Enterprise license?

The public pricing page lists Google Workspace and Microsoft Entra ID integrations, mTLS, privileged access management, password history and enhanced audit logging as Enterprise-only features. Kerberos SSO is not on that list, and the open-source edition is listed as free, so confirm the current edition boundary with authentik before you design around it. Enterprise pricing is listed per user per month plus a fee for external users, and that figure is set by authentik, not DeployOpen. Check whether your audit or identity governance needs are covered by Enterprise features.

How do authentik releases affect Kerberos SSO over time?

authentik names releases by year and month, and its security policy lists 2026.5.x and 2026.8.x as the supported versions that receive security fixes. The project announces security releases at least 24 hours in advance, so your team needs a process to receive that notice and schedule a window. Each upgrade can change the proxy or authentication behavior that negotiation depends on, so test Kerberos login on a staging instance before production. Confirm the upgrade path for your installed version in the authentik release notes before planning.

How DeployOpen scopes and delivers Kerberos SSO for authentik

DeployOpen plans, builds, documents and supports authentik Kerberos and SPNEGO single sign-on inside your own infrastructure. Each engagement starts with a written scope that names the domain, the KDC, the reverse proxy and the browser population, so the work is defined before any configuration changes.

How we scope

Inventory the Kerberos realm, KDC hosts, service principals and the domain-joined client population before design begins.
Map which hostnames, reverse proxy paths and browsers will negotiate SPNEGO and which will fall back to password login.
Record the keytab handling, service account rights and sync scope in the written scope, with fixed deliverables and timelines agreed in advance.
Confirm with your own team which authentik version line you run, since supported versions receive security fixes.

How we build

Configure the authentik Kerberos source against your realm, keytab and KDC settings in a non-production environment first.
Test SPNEGO negotiation from domain-joined Windows and other supported clients, including the reverse proxy path that passes the Authorization header.
Check the reverse proxy caching behavior that can break negotiation and document the cache rules that prevent it.
Verify user sync from the KDC, group mapping and the login fallback path before any production cutover.

How we hand over

Deliver configuration, keytab handling procedures and the source settings as versioned, reviewable artifacts.
Provide a test script that shows a domain user reaching the application without a password prompt and a failure case.
Document the reverse proxy rules, caching exclusions and the troubleshooting steps for negotiation failures.
Walk your engineers through the runbook so your team can rotate keytabs and change mappings without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Plan authentik version upgrades and re-run negotiation tests against each new release in your environment.
Review keytab rotation, KDC changes and proxy configuration changes that could affect transparent login.
Ask any support provider to confirm response terms and scope in writing before you sign.