Authentifizierung: Kerberos, NTLM und Delegation
Einführung · 7 Abschnitte · ~7 Min Lesezeit · Stand
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. |
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.
- 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.
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.
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. |
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.
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.
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.