Windows & Server

Kerberos

Allgemeine Infos

Kerberos ist ein Netzwerk-Authentifizierungsprotokoll, das Benutzer und Dienste über Tickets ausweist, statt Kennwörter über das Netz zu schicken. Version 5 ist in RFC 4120 (Juli 2005) standardisiert. Windows implementiert diese Version und ergänzt sie um eigene Erweiterungen für die Anmeldung per Zertifikat (PKINIT), für Autorisierungsdaten (PAC) und für Delegierung, dokumentiert in der Spezifikation MS-KILE.

In einer Active-Directory-Domäne läuft das Key Distribution Center (KDC) auf jedem Domain Controller und nutzt AD als Kontodatenbank. Kerberos liefert Single Sign-on nach der Windows-Anmeldung und eine gegenseitige Authentifizierung, die NTLM nicht bietet. Über das Negotiate-Verfahren versucht Windows zuerst Kerberos und weicht nur bei Bedarf auf NTLM aus. NTLMv1 ist in Windows Server 2025 entfernt, die übrigen NTLM-Varianten sind abgekündigt.

Aktuelle Änderungen: Domain Controller mit Windows Server 2025 stellen keine RC4-TGTs mehr aus und ignorieren den Registry-Wert SupportedEncryptionTypes. Mit CVE-2026-20833 stellt Microsoft den Standard schrittweise auf AES um: Updates ab 13. Januar 2026 schreiben Audit-Ereignisse (KDCSVC 201 bis 209), ab 14. April 2026 behandelt der KDC Konten ohne gesetztes msDS-SupportedEncryptionTypes als AES-only (0x18), mit den Updates ab Juli 2026 entfällt die Steuerung über RC4DefaultDisablementPhase und die Erzwingung ist fest aktiv. RC4 funktioniert dann nur noch, wenn es für ein Konto ausdrücklich erlaubt ist.

Abgrenzung: Active Directory und Domain Controller (eigene Einträge) stellen Verzeichnis und KDC bereit, Kerberos ist das Protokoll zwischen Client, KDC und Dienst. Microsoft Entra ID ist ein Cloud-Identitätsdienst ohne klassisches Kerberos-Domänenmodell. gMSA und dMSA (eigene Einträge) sind Dienstkonten, deren automatisch verwaltete Schlüssel Kerberos-Tickets absichern.

Funktionsweise & Details

Kerberos arbeitet mit drei Austauschen nach RFC 4120:

  1. AS-Exchange: Bei der Anmeldung fordert der Client beim Authentication Service des KDC ein Ticket Granting Ticket (TGT) an. Die Antwort ist mit dem aus dem Kennwort abgeleiteten Schlüssel des Clients verschlüsselt.
  2. TGS-Exchange: Mit dem TGT fordert der Client beim Ticket Granting Service ein Dienstticket für einen bestimmten Dienst an, adressiert über dessen Service Principal Name (SPN).
  3. AP-Exchange: Der Client legt das Dienstticket zusammen mit einem Authenticator beim Zielserver vor. Der Server entschlüsselt das Ticket mit seinem eigenen Schlüssel und kann sich auf Wunsch gegenüber dem Client ausweisen (gegenseitige Authentifizierung).

TGTs verschlüsselt der KDC mit dem Schlüssel des Kontos krbtgt, das beim Anlegen der Domäne automatisch entsteht und sich weder löschen noch umbenennen lässt. Weil Tickets Zeitstempel enthalten, müssen die Uhren synchron laufen, die übliche Toleranz liegt bei etwa fünf Minuten. Welche Verschlüsselung genutzt wird, steuern das Attribut msDS-SupportedEncryptionTypes (0x18 = AES128 und AES256, 0x1C = zusätzlich RC4) und die Gruppenrichtlinie „Network security: Configure encryption types allowed for Kerberos“. Die Tickets der aktuellen Sitzung zeigt klist an, Ticketanforderungen protokollieren die DCs als Ereignisse 4768 (TGT) und 4769 (Dienstticket).

Vorteile & Nutzen

  • Kennwörter gehen nicht über das Netz, weil sich Client und Server über Tickets und Sitzungsschlüssel ausweisen.
  • Single Sign-on: Nach der Windows-Anmeldung erreicht der Benutzer Dateiserver, Datenbanken oder Webanwendungen ohne erneute Eingabe.
  • Gegenseitige Authentifizierung schützt vor untergeschobenen Servern, was NTLM nicht leistet.
  • Server werden entlastet, weil sie Tickets selbst entschlüsseln und den DC nur für die Validierung des PAC kontaktieren.
  • Offener Standard: Auch Nicht-Windows-Dienste mit Keytab lassen sich in die Domänenanmeldung einbinden.

Praxisbeispiel

Ein Automobilzulieferer mit 250 Mitarbeitenden bereitet sich auf die RC4-Abschaltung vor. Die IT installiert die Januar-Updates 2026 auf allen Domain Controllern und wertet einige Wochen lang die KDCSVC-Ereignisse 201 bis 209 sowie die Events 4768 und 4769 mit dem Microsoft-Skript Get-KerbEncryptionUsage.ps1 aus. Auffällig sind ein altes Dienstkonto ohne AES-Schlüssel und eine Linux-Appliance mit einem Keytab, das nur RC4-Schlüssel enthält. Das Dienstkonto erhält ein neues Kennwort und damit AES-Schlüssel, für die Appliance wird ein neues Keytab mit AES erzeugt, danach setzt die IT RC4DefaultDisablementPhase noch vor dem Juli-Termin auf 2.

Worauf sollte man achten?

  • Werte die KDCSVC-Ereignisse 201 bis 209 aus und behebe ihre Ursachen, bevor die Erzwingung greift, sonst scheitern Anmeldungen an Diensten und Appliances.
  • Setze die Kennwörter sehr alter Dienstkonten neu, damit AES-Schlüssel entstehen; Konten aus der Zeit vor der AES-Unterstützung haben oft nur RC4-Schlüssel.
  • Halte die Zeit in der Domäne synchron, weil Abweichungen über der Toleranz zum Fehler KRB_AP_ERR_SKEW führen.
  • Registriere SPNs korrekt und eindeutig, fehlende oder doppelte SPNs verhindern die Kerberos-Anmeldung am Dienst.
  • Erlaube RC4 nur pro Konto über msDS-SupportedEncryptionTypes und nur für Altsysteme, nie domänenweit über DefaultDomainSupportedEncTypes, weil das alle Konten der Domäne angreifbar lässt.

Fazit

Kerberos ist die Grundlage jeder AD-Anmeldung, und mit dem Ende von RC4 im Jahr 2026 muss jede Domäne ihre Verschlüsselungstypen aufräumen. Wer die Audit-Ereignisse rechtzeitig auswertet, stellt ohne Ausfälle auf AES um.

Weiterführende Links

Verwandte Artikel