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.