# Authentifizierung: Kerberos, NTLM und Delegation

> Kerberos vs. NTLM, der Ticket-Lebenszyklus, SPNs und der Double-Hop, Delegationstypen (unconstrained/constrained/RBCD) und warum Zeitsynchronität kritisch ist.

Track: [Active Directory](https://physar.tech/learn/active-directory)  
Kanonische Fassung: https://physar.tech/learn/active-directory/authentication  
Stand: 2026-07-26  
Interaktiver Teil: 7 Checks (nur im Browser)

## Authentifizierung: Kerberos, NTLM und Delegation

### Zwei Protokolle: Kerberos zuerst, NTLM als Fallback

Eine Windows-Domäne authentifiziert mit zwei Protokollen. **Kerberos** ist der bevorzugte Weg; **NTLM** ist der ältere Fallback, der greift, wenn Kerberos nicht funktioniert. Der Unterschied ist nicht kosmetisch, sondern sicherheitsrelevant:

|  |  |
| --- | --- |
| **Gegenseitige Authentifizierung** | Kerberos: **ja** — der Client weist sich beim Dienst aus, und der Dienst beweist dem Client seine Identität. NTLM: **nein** — der Server authentifiziert sich dem Client nicht. |
| **Passwort über die Leitung** | Kerberos: nie ein Passwort-Äquivalent im Klartext auf dem Draht; Tickets sind mit Schlüsseln verschlüsselt, die aus dem Passwort abgeleitet sind. NTLM: Challenge-Response — kein Klartext, aber ein relayfähiger Handshake. |
| **Single Sign-On (SSO)** | Kerberos: einmal anmelden, dann Tickets ohne erneute Passworteingabe. NTLM: pro Dienst neuer Challenge-Response. |

> **Merksatz:** NTLM ist nicht „kaputt“, aber strukturell schwächer: **keine gegenseitige Authentifizierung**. Genau das macht **NTLM-Relay** möglich — ein Angreifer leitet einen Handshake an ein drittes Ziel weiter, weil der Server dem Client nie seine Identität beweist. Kerberos ist deshalb kein Nice-to-have, sondern die sichere Grundlinie.

### Der Ticket-Lebenszyklus

Kerberos trennt zwei Schritte: **einmal** die Identität nachweisen, dann **pro Dienst** ein kurzlebiges Ticket holen. Das ist der Kern des SSO.

_[Abbildung: Bei der Anmeldung holt der Client vom KDC (dem Authentication Service, AS) ein TGT — den Nachweis „ich bin angemeldet“. Für jeden Dienst tauscht er das TGT beim Ticket-Granting Service (TGS) gegen ein Service-Ticket. Dieses legt er dem Dienst per AP-REQ vor. Der Dienst prüft es mit seinem eigenen Schlüssel — ohne den KDC erneut zu fragen.]_

- **AS-Exchange:** Bei der Anmeldung fordert der Client beim **KDC** (auf jedem Domain Controller) ein **Ticket-Granting Ticket (TGT)** an. Das TGT ist mit dem Schlüssel des `krbtgt`-Kontos verschlüsselt — nur der KDC kann es später lesen.
- **TGS-Exchange:** Will der Client einen konkreten Dienst nutzen, legt er das TGT vor und bekommt ein **Service-Ticket** für genau diesen Dienst, verschlüsselt mit dem Schlüssel des Dienstkontos.
- **AP-Exchange:** Der Client sendet das Service-Ticket per **AP-REQ** an den Dienst. Der Dienst entschlüsselt es mit seinem eigenen Kontoschlüssel und vertraut ihm — **ohne Rückfrage beim KDC**.
- **Lebensdauer:** Tickets sind bewusst kurzlebig (Service-Tickets und TGT typischerweise ~10 Stunden, TGT erneuerbar). Ein gestohlenes Ticket ist damit zeitlich begrenzt brauchbar.

> **Warum das zählt:** Der Dienst braucht für die Prüfung **den KDC nicht** — er entschlüsselt das Ticket mit seinem eigenen Schlüssel. Deshalb muss der Client den Dienst unter dem **Namen** ansprechen, unter dem dessen Schlüssel registriert ist. Dieser Name ist der SPN.

### SPN: der Name, an dem Kerberos hängt

Ein **Service Principal Name (SPN)** verknüpft einen Dienst (z. B. `HTTP/web01.corp.example.com` oder `MSSQLSvc/sql01.corp.example.com:1433`) mit dem **Konto**, unter dem der Dienst läuft. Ohne diese Zuordnung kann der KDC kein Service-Ticket ausstellen, weil er nicht weiß, mit welchem Schlüssel er das Ticket verschlüsseln soll.

- **Fehlt der SPN**, findet der Client kein Ziel für ein Service-Ticket → Kerberos entfällt und Windows fällt (wenn erlaubt) auf **NTLM** zurück.
- **Ist ein SPN doppelt** auf zwei Konten registriert, ist die Zuordnung mehrdeutig → der KDC verschlüsselt ggf. mit dem falschen Schlüssel, der Dienst kann das Ticket nicht entschlüsseln → Kerberos **scheitert** (typisch `KRB_AP_ERR_MODIFIED`).
- **Zugriff per IP statt FQDN** löst standardmäßig **keinen** SPN-Lookup aus → NTLM. Kerberos verlangt den registrierten Namen.

> **Double-Hop:** Klassischer Fall: Ein Nutzer meldet sich an einer **Web-App** an (Hop 1), und die App soll **im Namen des Nutzers** auf eine **Datenbank** zugreifen (Hop 2). Der zweite Hop scheitert, weil die Web-App kein Nutzer-Passwort hat und ein Service-Ticket nicht einfach „weiterreichen“ kann. Diesen Sprung löst man **nicht** mit mehr SPNs, sondern mit **Delegation** — dem nächsten Thema.

### Delegation: drei Varianten, sehr unterschiedliches Risiko

Delegation erlaubt einem Dienst, gegenüber einem **weiteren** Dienst als der ursprüngliche Nutzer aufzutreten (der Double-Hop). Es gibt drei Bauformen — und die Wahl ist eine Sicherheitsentscheidung:

|  |  |
| --- | --- |
| **Unconstrained** | Der Dienst darf sich gegenüber **jedem** anderen Dienst als der Nutzer ausgeben. Dazu wird ein **weiterreichbares TGT des Nutzers** auf dem Dienstserver zwischengespeichert. Wird der Server kompromittiert, hat der Angreifer TGTs beliebiger Nutzer — **gefährlich, vermeiden.** |
| **Constrained** | Delegation nur an eine **feste Liste erlaubter SPNs** (`msDS-AllowedToDelegateTo` am Front-End-Konto). Kein Nutzer-TGT wird gecacht. Das Setzen der Liste verlangt ein **privilegiertes Recht** (`SeEnableDelegationPrivilege`, standardmäßig Domain Admins). |
| **Resource-Based (RBCD)** | Die Erlaubnis steht am **Ressourcen-/Ziel-Objekt** (`msDS-AllowedToActOnBehalfOfOtherIdentity`): das Ziel bestimmt selbst, **wer zu ihm** delegieren darf. Vom **Ressourcen-Owner** setzbar (Schreibrecht am Zielobjekt genügt), funktioniert **domänenübergreifend** innerhalb des Forests. |

> **Kernmissverständnis:** „Unconstrained ist am bequemsten, also nehmen wir das“ ist die klassische Falle. Bequemlichkeit erkauft man mit gecachten Nutzer-TGTs auf einem exponierten Server — ein Standard-Angriffspfad. Für neuen Bedarf ist **constrained oder RBCD** die richtige Grundwahl.

### Constrained vs. RBCD: wer die Erlaubnis kontrolliert

Beide begrenzen Delegation sauber — der Unterschied liegt darin, **wo** und **von wem** die Erlaubnis gesetzt wird:

- **Klassisch constrained:** konfiguriert am **Front-End** (dem delegierenden Dienst). Ändern erfordert das privilegierte `SeEnableDelegationPrivilege` → in der Praxis ein **Domain-Admin-Eingriff**. Domänenübergreifend eingeschränkt.
- **RBCD:** konfiguriert am **Back-End** (der Ressource). Der **Owner der Ressource** kann selbst entscheiden, wer zu ihr delegieren darf, ohne dass ein Domain Admin das Front-End anfassen muss — und es funktioniert über Domänengrenzen im Forest.

> **Merksatz:** RBCD **dreht die Kontrollrichtung um**: nicht „der delegierende Dienst darf zu diesen Zielen“, sondern „diese Ressource akzeptiert Delegation von diesen Aufrufern“. Das passt zu delegierter Verwaltung und domänenübergreifenden Szenarien — der Ressourcen-Owner steuert seinen eigenen Vertrauensrahmen.

### Zeit: Kerberos toleriert nur wenig Drift

Kerberos-Tickets tragen Zeitstempel, um Replay zu verhindern. Weichen die Uhren von Client und Dienst zu weit voneinander ab, wird das Ticket abgelehnt. Die tolerierte Abweichung (**Max Clock Skew**) ist standardmäßig **5 Minuten**.

Damit die Domäne synchron bleibt, gibt es eine **Zeit-Hierarchie**: Der **PDC-Emulator** der Forest-Root ist die **autoritative** Zeitquelle; die anderen DCs synchronisieren gegen ihn, Mitgliedserver und Clients gegen ihre DCs. Der Windows-Zeitdienst (`w32time`) hält diese Kette aufrecht.

> **Betriebliche Konsequenz:** Bekommt ein Server nach Zeitdrift plötzlich keine Tickets mehr (`KRB_AP_ERR_SKEW`), ist die Ursache **die Uhr**, nicht das Konto oder der SPN. Die Antwort ist **Zeit reparieren** (Server zurück in die `w32time`-Hierarchie), nicht die Skew-Toleranz aufzudrehen — das schwächt den Replay-Schutz für die ganze Domäne.

### Zusammenfassung — gleich im Check

Du kennst jetzt die Achsen: **Kerberos vs. NTLM** (gegenseitige Authentifizierung, Relay-Risiko), den **Ticket-Lebenszyklus** (TGT → Service-Ticket → AP-REQ), **SPNs** als Voraussetzung von Kerberos (fehlend/doppelt → NTLM oder Fehler, Double-Hop), die **drei Delegationstypen** und ihre Risiken sowie die **Zeitsynchronität** mit dem PDC-Emulator als autoritativer Quelle.

> **Gleich im Check:** In den nächsten Entscheidungen und einer Diagnose-Mission wählst du für konkrete Ops-Situationen selbst — und siehst pro Option, **warum** sie trägt oder aus welchem konkreten Grund nicht.

## Quellen

- RFC 4120 — The Kerberos Network Authentication Service (V5)
- Microsoft Learn — Kerberos Authentication Overview
- Microsoft Learn — Service Principal Names (SPNs) and setspn
- Microsoft Learn — Kerberos Constrained Delegation Overview
- Microsoft Learn — Resource-Based Constrained Delegation (msDS-AllowedToActOnBehalfOfOtherIdentity)
- Microsoft Learn — How the Windows Time Service Works (PDC-Emulator, Zeit-Hierarchie)
- Microsoft — Kerberos policy: Maximum tolerance for computer clock synchronization (MaxClockSkew, 5 Minuten)
- Microsoft — Mitigating NTLM relay attacks (SMB/LDAP Signing, Extended Protection for Authentication)
- Microsoft Learn — Service Principal Names (SPNs)
- Microsoft Support — Troubleshooting Kerberos errors (duplicate SPN, KRB_AP_ERR_MODIFIED)
- Microsoft — Mitigating NTLM relay attacks (SMB signing, LDAP signing/channel binding, EPA)
- Microsoft Learn — Microsoft NTLM (protocol overview and security considerations)
- Microsoft Learn — Unconstrained delegation security considerations
- Microsoft Learn — Kerberos Constrained Delegation Overview (SeEnableDelegationPrivilege)
- Microsoft — Kerberos policy: Maximum tolerance for computer clock synchronization (MaxClockSkew)
- Microsoft Learn — How the Windows Time Service Works (PDC-Emulator als autoritative Zeitquelle)
- Microsoft Learn — Network security: Restrict NTLM
- Microsoft Learn — Kerberos authentication overview