Windows Security · Active Directory

Kerberos — Das Herzstück der Windows-Authentifizierung

Wie das Drei-Köpfe-Protokoll Identitäten beweist, ohne Passwörter über das Netzwerk zu senden — und warum RC4 dabei nichts mehr verloren hat.

von IT-Service Walter · isw-adtools.de

Jedes Mal, wenn sich ein Benutzer an einer Windows-Domäne anmeldet, eine Freigabe öffnet oder auf einen Exchange-Server zugreift, arbeitet Kerberos im Hintergrund — schnell, sicher und für den Anwender völlig unsichtbar. Trotzdem ist das Protokoll in vielen Umgebungen falsch konfiguriert oder wird durch veraltete Kryptographie (RC4) geschwächt. Dieser Artikel erklärt, wie Kerberos wirklich funktioniert, welche Komponenten zusammenspielen und wie ein modernes Kerberos-Deployment ohne RC4 aussieht.

Was ist Kerberos?

Kerberos ist ein netzwerkbasiertes Authentifizierungsprotokoll, das am MIT in den 1980er-Jahren entwickelt wurde und heute in RFC 4120 spezifiziert ist. Der Name stammt aus der griechischen Mythologie: Kerberos (Cerberus) ist der dreiköpfige Wächter des Hades — passend, denn das Protokoll hat drei zentrale Akteure:

👤

Client

Der Benutzer oder Dienst, der sich authentifizieren möchte.

🏛️

KDC (Key Distribution Center)

Vertrauenswürdige Drittpartei — in Windows der Domänencontroller. Enthält AS und TGS.

🖥️

Server / Ressource

Der Dienst, auf den zugegriffen werden soll (Dateiserver, SQL, Exchange …).

Das entscheidende Prinzip: Passwörter werden nie über das Netzwerk übertragen. Stattdessen arbeitet Kerberos mit zeitlich begrenzten, verschlüsselten Tickets, die als Identitätsnachweise dienen.

Der KDC: AS und TGS

Das Key Distribution Center besteht intern aus zwei Komponenten:

Authentication Service (AS)
Prüft die initiale Identität des Benutzers und stellt das Ticket-Granting Ticket (TGT) aus. Der AS kennt den Long-Term Key (abgeleitet vom Passwort) jedes Principals.

Ticket-Granting Service (TGS)
Tauscht ein gültiges TGT gegen ein Service Ticket (ST) für eine spezifische Ressource. Der TGS muss das Passwort des Benutzers nicht kennen.

Der Authentifizierungsablauf — Schritt für Schritt

Der vollständige Kerberos-Ablauf teilt sich in drei Phasen auf. Alle Nachrichten sind in der Spezifikation als AS-REQ/REP und TGS-REQ/REP bzw. AP-REQ/REP definiert.

Phase 1 — AS-REQ / AS-REP: Anmeldung am KDC

Der Client sendet eine AS-REQ an den KDC. Diese enthält den Benutzernamen (unverschlüsselt) und einen Zeitstempel, der mit dem Long-Term Key des Benutzers verschlüsselt ist (Pre-Authentication).
Der KDC prüft den Zeitstempel. Stimmt er, antwortet er mit einer AS-REP: Sie enthält einen Session Key (für Client ↔ TGS) und das Ticket-Granting Ticket (TGT).
Das TGT ist mit dem Passwort des krbtgt-Kontos verschlüsselt — nur der KDC kann es lesen. Der Client speichert das TGT im Credential Cache (lsass.exe).

Phase 2 — TGS-REQ / TGS-REP: Service Ticket anfordern

Will der Client auf eine Ressource zugreifen (z. B. cifs/fileserver.contoso.local), schickt er eine TGS-REQ mit dem TGT und dem Ziel-SPN an den TGS.
Der TGS entschlüsselt das TGT mit dem krbtgt-Passwort, extrahiert den Session Key und erstellt ein Service Ticket (ST) — verschlüsselt mit dem Long-Term Key des Zieldienstes.
Der Client erhält das ST per TGS-REP. Er kann den Inhalt des ST selbst nicht lesen — nur der Zieldienst kann es entschlüsseln.

Phase 3 — AP-REQ / AP-REP: Zugriff auf die Ressource

Der Client präsentiert dem Dienst das ST in einer AP-REQ, zusammen mit einem Authenticator (Zeitstempel, verschlüsselt mit dem Service Session Key).
Der Dienst entschlüsselt das ST mit seinem eigenen Passwort/Schlüssel, extrahiert den Service Session Key und prüft damit den Authenticator.
Optional antwortet der Dienst mit einer AP-REP (gegenseitige Authentifizierung / Mutual Authentication) — der Client wird damit sicher, dass er mit dem echten Dienst spricht.

Schlüsselkonzepte im Überblick

🔑 Long-Term Key

Vom Passwort abgeleiteter Schlüssel, der dauerhaft in der AD-Datenbank gespeichert ist. Für Benutzer ist das heute ausschließlich der AES-256-Schlüssel (etype 18).

🎫 TGT — Ticket-Granting Ticket

Das “Generalticket” des Benutzers. Standardmäßig 10 Stunden gültig. Ermöglicht weitere Tickets ohne erneute Passworteingabe (Single Sign-On).

🎟️ Service Ticket (ST)

Spezifisch für einen Dienst (identifiziert über den SPN). Gültig i. d. R. 10 Stunden. Enthält Gruppen-Memberships im PAC.

⏱️ Zeitstempel & Uhrsynchronisation

Kerberos toleriert maximal 5 Minuten Zeitabweichung (Skew). NTP ist zwingend erforderlich — Domänencontroller sind automatisch NTP-Quellen.

🏷️ SPN — Service Principal Name

Eindeutiger Name für einen Dienst, z. B. cifs/fileserver.contoso.local. Fehlerhafte oder doppelte SPNs verhindern Kerberos-Authentifizierung.

📋 PAC — Privilege Attribute Certificate

Windows-Erweiterung des Service Tickets. Enthält SID, Gruppen-Memberships und Berechtigungen — signiert vom KDC, nicht vom Client manipulierbar.

Kryptographie: Warum kein RC4

Historisch unterstützte Windows Kerberos mehrere Encryption Types (etypes): DES (lange veraltet), RC4-HMAC (etype 23) und AES. RC4 war jahrelang der Standard-Fallback — ein Relikt aus Windows 2000-Zeiten.

⚠️ Warum RC4 in Kerberos gefährlich ist

AS-REP Roasting: Benutzerkonten ohne Pre-Authentication senden einen RC4-verschlüsselten Blob — offline knackbar.
Kerberoasting: Service Tickets mit RC4 können offline per Wörterbuch-Angriff gebrochen werden, wenn das Dienstkonto-Passwort schwach ist.
RC4 ist kryptographisch gebrochen: Bekannte Angriffe (BEAST, RC4-Biases) machen RC4 für moderne Sicherheitsanforderungen ungeeignet.
Pass-the-Hash vereinfacht: Mit RC4 lassen sich Hashes direkt als Kerberos-Schlüssel einsetzen (Overpass-the-Hash).

Das Ziel: Ausschließlich AES-256 (etype 18) und AES-128 (etype 17). Diese sind in RFC 3962 spezifiziert und gelten als kryptographisch sicher. Windows Server 2019 und Windows 10/11 unterstützen AES nativ und bevorzugen es — solange keine Legacy-Systeme RC4 erzwingen.

Etype	Bezeichnung	Algorithmus	Status
1, 3	DES-CBC-CRC / DES-CBC-MD5	DES	❌ Verboten (seit Windows 2012)
23	RC4-HMAC	RC4	⚠️ Deaktivieren — Legacy-Risiko
17	AES128-CTS-HMAC-SHA1-96	AES-128	✓ Akzeptiert
18	AES256-CTS-HMAC-SHA1-96	AES-256	✓ ✓ Empfohlen — Standard

RC4 in der Domäne deaktivieren

RC4 wird über das GPO-Setting “Network security: Configure encryption types allowed for Kerberos” gesteuert (Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options).

ℹ️ Empfohlene GPO-Konfiguration

✅ AES256_HMAC_SHA1 — aktivieren
✅ AES128_HMAC_SHA1 — aktivieren
✅ Future encryption types — aktivieren
❌ RC4_HMAC_MD5 — nicht aktivieren
❌ DES_CBC_CRC / DES_CBC_MD5 — nicht aktivieren

Wichtig vor der Umstellung: Alle Dienst- und Computerkonten müssen aktuelle AES-Schlüssel besitzen. Dazu muss für jedes Dienstkonto mindestens einmal das Passwort geändert oder das Konto mit msDS-SupportedEncryptionTypes = 24 (AES128+AES256) konfiguriert werden. Für Gruppenrichtlinien-Konten (gMSA) geschieht dies automatisch.

✅ Checkliste vor RC4-Deaktivierung

✔ Kerberos-Events im Systemlog überwachen (Event ID 4769 — etype 0x17 = RC4 noch genutzt)
✔ Alle SPNs auf Gültigkeit prüfen (setspn -X)
✔ Dienstkonto-Passwörter aktualisieren / msDS-SupportedEncryptionTypes setzen
✔ Linux/Unix-Systeme mit AES-Keytabs konfigurieren (MIT Kerberos)
✔ Ältere NAS/Drucker/Applikationen auf Kerberos-AES-Unterstützung prüfen
✔ krbtgt-Passwort zweimal zurücksetzen (Replikationsintervall abwarten)
✔ GPO im Audit-Modus testen vor breitem Rollout

Kerberos-Delegation: Identitäten weiterreichen

Wenn ein Webserver im Namen eines Benutzers auf einen SQL-Server zugreifen muss, kommt Delegation ins Spiel. Dabei gibt es drei Varianten mit sehr unterschiedlichem Sicherheitsprofil:

🔴 Unconstrained Delegation (unbegrenzt)

Der delegierte Server erhält das komplette TGT des Benutzers und kann damit auf jeden Dienst in der Domäne zugreifen. Hochriskant — bei Kompromittierung des Servers kann sich ein Angreifer als beliebiger Benutzer ausgeben. Sollte nur auf Domänencontrollern verbleiben.

🟠 Constrained Delegation (begrenzt, KCD)

Der Server kann die Identität nur für explizit erlaubte SPNs annehmen (via msDS-AllowedToDelegateTo). Besser, aber der KDC erzwingt die Einschränkung — nicht der Dienst selbst. S4U2Proxy / S4U2Self ermöglichen das ohne TGT des Benutzers.

🟢 Resource-Based Constrained Delegation (RBCD)

Die Kontrolle liegt beim Zieldienst (msDS-AllowedToActOnBehalfOfOtherIdentity auf dem Ressourcenkonto). Flexibler und sicherer — kein Domain-Admin-Eingriff für jede Änderung nötig. Empfohlen für moderne Umgebungen.

Typische Kerberos-Fehler und ihre Ursachen

Fehlercode	Bedeutung	Häufige Ursache
KRB5KDC_ERR_PREAUTH_REQUIRED	Pre-Authentication fehlt	Normaler erster Schritt — kein Fehler. Problem wenn wiederholt.
KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN	SPN nicht gefunden	SPN fehlt, ist falsch geschrieben oder doppelt vergeben.
KRB5KRB_AP_ERR_SKEW	Zeitdifferenz zu groß	NTP-Synchronisation fehlt — mehr als 5 Minuten Abweichung.
KRB5KDC_ERR_ETYPE_NOTSUPP	Encryption Type nicht unterstützt	RC4 deaktiviert, aber Dienstkonto hat noch keine AES-Schlüssel.
KRB5KRB_ERR_RESPONSE_TOO_BIG	Antwortpaket zu groß für UDP	Benutzer in sehr vielen Gruppen — PAC wird zu groß. Kerberos wechselt auf TCP.

💡 Fazit

Kerberos ist ein elegantes, sicheres Protokoll — vorausgesetzt, es wird korrekt konfiguriert. Das bedeutet konkret:

Nur AES-128 und AES-256 erlauben — RC4 konsequent deaktivieren
Pre-Authentication für alle Konten erzwingen (kein “Do not require Kerberos preauthentication”)
SPNs sauber verwalten — keine Duplikate, keine verwaisten Einträge
krbtgt-Passwort regelmäßig rotieren (mindestens alle 180 Tage)
Unconstrained Delegation auf das absolute Minimum reduzieren
Event ID 4769 überwachen — RC4-Anfragen sofort aufspüren

Weiterführend: Den vollständigen Secure-Boot-Zertifikat-Status, Kerberos-Audit und weitere AD-Sicherheitschecks in Ihrer Domäne analysieren? Der ISW Kerberos Audit Analyzer prüft Encryption Types, Delegations-Konfigurationen, SPN-Konsistenz und krbtgt-Alter domänenweit — direkt aus der Windows-Oberfläche. Mehr auf isw-adtools.de.