Kerberos – Ein Deepdive

Kerberos ist im ActiveDirectory-Umfeld ein bekannter Begriff. Dennoch wissen viele Administratoren nicht oder nicht wirklich, wie dieses Protokoll funktioniert. Ich habe viele Ansätze im Internet verfolgt, um meinen Kursteilnehmern eine Hilfestellung geben zu können. Leider habe ich nichts wirklich passendes gefunden.

Daher habe ich einfach selber eine kleine Beschreibung der Vorgänge mit Kerberos zusammengestellt. Vielleicht kann ich euch damit etwas unterstützen. 🙂

Insgesamt habe ich 3 Beiträge verfasst, um die Vorgänge bei Kerberos darzustellen. Für alle Beiträge möchte ich noch folgende Hinweise mitgeben:

  • Jeder Beitrag besteht aus einem Video. Falls etwas zu schnell oder zu langsam geht dann nutzt einfach die entsprechenden Schaltflächen des Videoplayers.
  • Bei Kerberos wird symmetrisch verschlüsselt – oder einfach gesagt: Was mit einem geheimen Schlüssel verschlüsselt wurde kann mit dem gleicen Schlüssel auch wieder entschlüsselt werden. Verschlüsselung habe ich in den Videos mit Farben dargestellt.
  • Achtet auf diese Farben. Ein „gelber“ Schlüssel ver- und entschlüsselt Elemente mit „gelben“ Hintergrund.

Und vielleicht fallen euch die vielen Abkürzungen in den Videokommentaren auf. Hier könnt ihr noch einmal in einer tabellarischen Zusammenfassung alles in Ruhe nachlesen:

Abkürzung Name Erläuterung
LTK Long Term Key Das ist der Hash eines Passwortes. Long Term bedeutet in diesem Fall, dass er „länger“ gültig ist – bei Computerkonten üblicherweise 30 Tage, bei Benutzern eben bis zum Ablauf des Anmeldepasswortes.
SK Session Key SK’s sind vom DomainController generierte, kurzlebige Schlüssel. Üblicherweise sind können diese 10 Stunden verwendet werden. Hier liegt auch die Sicherheit bei der Verwendung von Kerberos: selbst wenn es ein Angreifer schafft, einen solchen Schlüssel zu knacken – er ist sehr schnell wieder ungültig… 🙂
KRBTGT Kerberos Ticket Granting Ticket Das ist der Name der Identität, mit der alle Aktionen der DomainController ausgeführt werden. Dieser ActiveDirectory-Benutzer hat ein Kennwort, das alle DomainController kennen. Mit diesem werden alle TGT’s verschlüsselt.
TGT Ticket Granting Ticket Ein TGT ist nichts weiter als ein mit dem Passwort des KRBTGT-Users verschlüsselter SessionKey, den ein DomainController für die Anmeldung eines Benutzers/Computers zufällig generiert hat. Jeder DomainController kann ein TGT entschlüsseln und somit den SessionKey extrahieren. Damit kann ein Benutzer sich an einem DC1 anmelden (dieser generiert den SK) und dann an einem DC2 ein TGS anfragen, dass er mit diesem SK verschlüsselt hat.
TGS Ticket Granting ServiceTicket Ein TGS enthält einen zufälligen SessionKey für zwei Identitäten. Mit diesem kann z.B. ein Benutzer eine Session zu einer Ressource (z.B. Fileserver) auf einem Computer anfordern.
AS-REQ Authentication Service Request Bei einem AS-REQ handelt es sich um ein Netzwerkpaket von einem Client/Benutzer zu einem DomainController. Es stellt eine Anmeldeanfrage im Klartext dar. Wenn Kerberos V5 mit PreAuthentication verwendet wird (das ist der Standard, der bitte niemals deaktiviert wird), dann enthält es einen verschlüsselten Authenticator.
AS-REP Authentication Service Reply Das ist die Netzwerk-Antwort eines DomainControllers auf ein AS-REP (bei erfolgreicher Authentifizierung). Es enthält den zufällig generierten (und verschlüsselten) SessionKey und das (verschlüsselte) TGT.
TGS-REQ Ticket Granting Service Request Für den Zugriff auf eine Resource (z.B. Fileserver) benötigt eine Identität (z.B. Benutzer) ein TGS. Dieses erhält er von einem DC, wenn er es mit einem validen TGS-REQ anfragt. In diesem Netzwerk-Paket sind die Informationen zur Ressource, ein Authenticator und das TGT enthalten.
TGS-REP Ticket Granting Service Reply Wenn der DomainController das TGS-REQ erfolgreich überprüft hat, dann sendet er als Antwort ein TGS-REP. Dieses enthält den verschlüsselten, neu generierten SessionKey für Benutzer-zu-Ressource und das TGS-Ticket.
AP-REQ Authentication Protocol Request Hat eine Identität (z.B. ein Benutzer) ein TGS-REP von einem DomainController erhalten, kann sie ein AP-REQ als Netzwerkpaket zum Ressourcen-Server (z.B. Fileserver) senden, um sich dort anzumelden. Das AP-REQ enthält einen Authenticator und das TGS-Ticket.
AP-REP Authentication Protocol Reply Dieses Netzwerkpaket ist eher unüblich. Es stellt die Antwort auf die Sessionanfrage einer Identität auf eine Ressource dar.
Authenticator Authenticator Bei Kerberos wird mit einem Schlüssel (je nach Paket der LTK oder der SK) die aktuelle Uhrzeit verschlüsselt. Das Netzwerkpaket muss zügig zum Zielserver gesendet werden, denn dieser entschlüsselt den Authenticator mit dem ihm bekannten Schlüssel (damit wird bewiesen, dass das Paket vom bekannten Absender stammt, denn nur dieser sollte den Schlüssel kennen). Symmetrische Verschlüsselungen können mit einem entsprechend hohem Zeitaufwand entschlüsselt werden. Ebenso könnte der dafür erforderliche Schlüssel aus dem Netzwerkpaket berechnet werden. Kerberos lässt einem Angreifer dafür aber nur wenige Minuten Zeit, denn dann ist der Timestamp „abgelaufen“. Daher ist beim Einsatz von Kerberos auch die gemeinsame „zeit“ über alle Clients und DomainController so enorm wichtig!

Und hier geht es nun zu den Videos:

  1. Teil 1: eine Clientanmeldung an einem DomainController
  2. Teil 2: eine Benutzeranmeldung an einem DomainController
  3. Teil 3: eine Ressourcenanmeldung eines Benutzers an einem Service