# 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

```text
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:

```text
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](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.