When Kerberos Authenticates Users but Can’t Tell You Who They Are
Kerberos authentication worked.
Apache accepted the ticket.
The backend received the request.
And yet, the application had no idea which user was calling it, or which groups they belonged to.
This post documents how I built a Kerberos-authenticated Apache reverse proxy that correctly propagates user identity and AD group membership to backend services — and why doing this requires SSSD, NSS, and DBus, not Kerberos alone.
This is not a tutorial.
It’s a systems explanation for people who already run real infrastructure.
The Problem: Kerberos Auth ≠ Identity Context
Kerberos answers one question only:
“Is this client allowed to authenticate as this principal?”
That’s it.
When Apache validates a Kerberos ticket, it gets:
a principal name (e.g. user@REALM)
proof that the client is authenticated
What it does NOT get:
Unix username mapping
Group membership
LDAP attributes
Authorization context
Kerberos is authentication, not identity resolution.
And backend services almost never want a Kerberos principal — they want:
a username
group membership
roles
That gap is where things usually break.
Why Apache Alone Is Not Enough
Apache with mod_auth_gssapi can authenticate a request and set:
REMOTE_USER=user
REMOTE_USER=user
into:
username + UID + GIDs + group names
And it does so in a way that:
is cached
is secure
survives temporary directory outages
Without SSSD, Apache has no reliable way to answer:
“What groups is this user in?”
Why DBus Is Involved
Apache cannot just “ask SSSD” directly.
SSSD exposes identity data through IFP (InfoPipe), which is accessed via DBus.
So the real call chain looks like this:
Apache
→ mod_lookup_identity
→ DBus
→ SSSD IFP / NSS
→ Active Directory
This design matters because:
SSSD runs as root
Apache does not
DBus enforces access control
identity lookups remain isolated and safe
When DBus or IFP is misconfigured, group lookup silently fails — even though authentication succeeds.
This is one of the most misleading failure modes in the stack.
Why Kerberos Cannot Provide Groups
This is important enough to state clearly
Kerberos cannot provide group membership.
Kerberos tickets do not carry:
LDAP attributes
AD group lists
authorization data usable by applications
Some environments use PAC data inside Kerberos tickets, but:
Apache does not expose it cleanly
It is not portable
It still does not replace identity resolution
So even with a valid Kerberos ticket, you still need LDAP/SSSD to answer authorization questions.
How This Project Solves the Problem
This setup intentionally separates responsibilities:
1. Kerberos (Authentication)
mod_auth_gssapi
validates the client ticket
establishes trust
sets REMOTE_USER
2. SSSD + NSS (Identity Resolution)
resolves username to UID/GIDs
fetches AD group membership
caches results
3. DBus + mod_lookup_identity (Bridging)
Apache queries SSSD safely
group information becomes available inside Apache
4. Apache Headers (Propagation)
identity is forwarded as headers:
X-User
X-User-Groups
5. Backend (Authorization)
backend receives identity context
no Kerberos awareness required
no directory access required
This keeps the backend simple and stateless.
Why Headers Are the Right Boundary
Instead of:
embedding Kerberos in every service
exposing LDAP credentials everywhere
duplicating identity logic
The proxy becomes the identity boundary.
Backend services only need to trust:
the proxy
the headers it injects
This is intentional, auditable, and scalable.
See the Working Configuration
The full, sanitized, working configuration described in this post is available here:
👉 GitHub repository:
https://github.com/pash10/kerberos-apache-SSO-AD-reverse-proxy
The repository includes:
A complete Apache configuration for Kerberos-authenticated reverse proxying
SSSD + NSS integration examples
Dockerfile and Compose setup
Minimal documentation describing scope and assumptions
This repository is intentionally artifact-first.
It is not a tutorial and does not attempt to abstract away the underlying systems.