Kerberos-Tickets: TGT und Service-Ticket verstehen
Active-Directory-Authentifizierung ohne Mythen und MissverständnisseKerberos-Tickets verstehen: TGT und Service-Ticket im Klartext
Kerberos ist der Türsteher von Active Directory: unsichtbar, humorlos und erschreckend gut darin, genau dann zu streiken, wenn eine Führungskraft auf eine Präsentation zugreifen will. Der Grund für die meisten Kerberos-Dramen ist selten Magie, sondern ein Denkfehler. Viele Admins stellen sich vor, der Domain Controller würde bei jedem Dateizugriff kurz nachfragen, ob das noch in Ordnung ist. Tut er nicht. Er stellt Tickets aus, wäscht sich die Hände und überlässt den Rest den beteiligten Rechnern.
Dieser Artikel nimmt genau diesen Ablauf auseinander: von der ersten Anfrage bei der Anmeldung bis zum Moment, in dem ein Dateiserver ein Service-Ticket entschlüsselt und entscheidet, wer da eigentlich klopft. Das Fokus-Thema ist das Kerberos Ticket Granting Ticket, kurz TGT, und sein kleiner Bruder, das Service-Ticket. Sie erfahren, wer welches Ticket ausstellt, wer es prüft, wie lange es gilt und warum ein Ticket kein Passwort ist. Dazu gibt es Praxis mit dem Bordmittel klist, ein paar unbequeme Wahrheiten zu Ticket-Lebensdauern und die aktuellen Änderungen bei den Verschlüsselungstypen, die 2026 einige Legacy-Geräte in den vorzeitigen Ruhestand schicken.
Der Gesamtüberblick zur Serie steht auf der Pillar-Seite Microsoft Kerberos unter /microsoft-kerberos.
Die Beteiligten: Client, KDC und Zieldienst
Kerberos kennt drei Rollen, und jede hat genau eine Aufgabe. Wer diese drei sauber trennt, hat achtzig Prozent aller Missverständnisse schon hinter sich.
Der Client sammelt, der KDC stellt aus
Der Client ist der Rechner, auf dem ein Konto angemeldet ist. Er hält einen Ticket-Cache im Speicher der lokalen Sicherheitsbehörde, und dieser Cache ist genau das, was klist anzeigt. Der Key Distribution Center, praktischerweise als KDC abgekürzt, läuft auf jedem Domain Controller und besteht aus zwei Diensten in einem Gehäuse. Der Authentication Service prüft die erste Anmeldung und gibt das TGT heraus. Der Ticket Granting Service nimmt dieses TGT anschließend als Ausweis an und gibt dafür Service-Tickets für einzelne Dienste heraus. Wenn ein Nutzer oder ein Dienst sich anmeldet, stellt ein Domain Controller in der Rolle des KDC ein verschlüsseltes Ticket aus, das die Identität des Aufrufers belegt.
Der Dienst prüft, ohne zu fragen
Der Zieldienst, etwa ein Dateiserver mit CIFS, ein SQL Server mit MSSQLSvc oder ein Webserver mit HTTP, prüft das vorgelegte Service-Ticket ausschließlich mit seinem eigenen Langzeitschlüssel. Er ruft dazu keinen Domain Controller an. Das ist der Kern der Skalierbarkeit von Kerberos und gleichzeitig die Quelle des größten Irrtums im Betrieb. Die erste Authentifizierung gegen den Domain Controller liefert ein TGT, das anschließend zum Anfordern von Service-Tickets für Ressourcen genutzt wird; jeder Computer holt sich beim Start ebenfalls ein TGT, bevor er Service-Tickets für den Domain Controller und andere benötigte Systeme anfordert. Auch Computerkonten spielen also mit, was beim Debuggen gern vergessen wird.
Zusätzlich packt der Domain Controller in die Tickets ein PAC. Das Privilege Attribute Certificate ist eine Erweiterung des Kerberos-Tickets, die Informationen über die Berechtigungen eines Nutzers enthält und beim Anmelden in der Domäne vom Domain Controller in das Ticket geschrieben wird. Genau deshalb muss der Dienst nicht live nachfragen: Die Gruppenmitgliedschaften reisen im Ticket mit.
|
INFO Faktenkasten Rollen: Ein TGT wird vom Authentication Service ausgestellt und mit dem Schlüssel des krbtgt-Kontos verschlüsselt. Ein Service-Ticket wird vom Ticket Granting Service ausgestellt und mit dem Langzeitschlüssel des Dienstkontos verschlüsselt. Der Client kann keines von beiden lesen. Er ist nur der Briefträger, der zwei versiegelte Umschläge und je einen dazugehörigen Session-Key besitzt. |
|---|
Von AS-REQ bis Service-Ticket: der Anmeldevorgang Schritt für Schritt
Der Ablauf besteht aus drei Austauschen. Wer diese drei Phasen im Kopf hat, kann Netzwerkmitschnitte lesen, ohne in Tränen auszubrechen.
Phase 1: AS-REQ und AS-REP
Der Client schickt eine AS-REQ an Port 88 des Domain Controllers. In modernen Umgebungen enthält sie sofort die Pre-Authentication: einen aktuellen Zeitstempel, verschlüsselt mit dem aus dem Passwort abgeleiteten Schlüssel des Kontos. Der Domain Controller entschlüsselt das, prüft den Zeitstempel und antwortet mit einer AS-REP. Darin stecken das TGT, versiegelt mit dem krbtgt-Schlüssel, und ein Session-Key, der für den Client lesbar verschlüsselt ist. Zu spät gestellte Uhren sind hier der Klassiker: Ein Zeitversatz jenseits der erlaubten Toleranz beendet die Anmeldung, bevor sie begonnen hat. Auf dem Domain Controller taucht dieser Vorgang als Ereignis 4768 auf.
Phase 2: TGS-REQ und TGS-REP
Will der Client auf eine Freigabe zugreifen, legt er das TGT wieder beim KDC vor, diesmal beim Ticket Granting Service, zusammen mit einem frischen Authenticator und dem Service Principal Name des Ziels. Der KDC prüft nicht, ob der Nutzer auf den Ordner darf. Er prüft nur, ob das TGT gültig ist und ob der SPN existiert. Dann stellt er ein Service-Ticket aus, verschlüsselt mit dem Schlüssel des Dienstkontos. Das ist Ereignis 4769. Für ein belastbares Audit lohnt der Blick in das Sicherheitsprotokoll auf die Ereignisse 4768 und 4769; ab Windows Server 2019, und auf Windows Server 2016 mit dem kumulativen Update von Januar 2025, enthalten diese Ereignisse zusätzliche Angaben zu unterstützten Verschlüsselungstypen und verfügbaren Schlüsseln.
Phase 3: AP-REQ und AP-REP
Jetzt wird es interessant, denn der KDC ist raus. Der Client schickt das Service-Ticket samt Authenticator direkt an den Dienst. Der Dienst entschlüsselt es mit seinem eigenen Schlüssel, liest Identität und PAC, prüft den Zeitstempel und gewährt oder verweigert Zugriff anhand seiner lokalen Rechtevergabe. Auf Wunsch antwortet er mit einer AP-REP zur Gegenauthentifizierung, damit der Client weiß, dass er nicht mit einem Hochstapler spricht.
|
WICHTIG Der KDC prüft keinen einzelnen Zugriff. Er beantwortet nur die Frage, ob ein Ticket ausgestellt werden darf. Ob ein Nutzer eine Datei öffnen darf, entscheidet allein der Dienst anhand seiner Zugriffsrechte und der Gruppeninformationen im PAC. Ein gesperrtes oder deaktiviertes Konto verliert deshalb nicht sofort alle Zugriffe, solange gültige Tickets im Umlauf sind. Kontosperren wirken bei Kerberos mit Verzögerung, nicht mit Sofortwirkung. |
|---|
TGT und Service-Ticket im direkten Vergleich
Beide Ticketarten sehen im Netzwerkmitschnitt ähnlich aus, erfüllen aber völlig verschiedene Zwecke. Das TGT ist der Hausschlüssel, das Service-Ticket der Zimmerschlüssel. Wer den Hausschlüssel klaut, braucht den Zimmerschlüssel nicht mehr zu stehlen, er lässt sich einfach einen neuen ausstellen. Genau darum ist das krbtgt-Konto das wertvollste Objekt in der Domäne.
Bei den Laufzeiten gilt Microsofts Standard, an dem erstaunlich viele Umgebungen nie etwas ändern. Die Richtlinie für die maximale Gültigkeitsdauer des Benutzertickets legt fest, wie lange ein Ticket Granting Ticket verwendet werden kann; danach muss ein neues angefordert oder das bestehende erneuert werden. Empfohlen und in der Default Domain Policy voreingestellt sind 10 Stunden. Für Service-Tickets sieht es ähnlich aus: Die maximale Gültigkeitsdauer eines Sitzungstickets muss über zehn Minuten liegen und darf die Gültigkeitsdauer des Benutzertickets nicht überschreiten, voreingestellt sind 600 Minuten.
Eine Feinheit, die im Support regelmäßig für Verwirrung sorgt: Sobald eine Verbindung authentifiziert ist, spielt es keine Rolle mehr, ob das Sitzungsticket noch gültig ist, denn Sitzungstickets authentifizieren nur neue Verbindungen; laufende Vorgänge werden durch ein ablaufendes Ticket nicht unterbrochen. Der Kopiervorgang bricht also nicht nach zehn Stunden mitten in der Datei ab. Die nächste neue Verbindung braucht allerdings ein frisches Ticket.
Und wer die Lebensdauer aus Bequemlichkeit auf null setzt, sollte wissen, was er tut: Ist der Wert zu hoch, können Nutzer außerhalb ihrer Anmeldezeiten auf Netzwerkressourcen zugreifen, und Konten, die deaktiviert wurden, können mit vorher ausgestellten Service-Tickets weiterarbeiten; beim Wert 0 laufen Ticket Granting Tickets nie ab.
|
WARNUNG Service-Tickets sind das Futter für Kerberoasting, weil sie mit dem Schlüssel des Dienstkontos verschlüsselt sind und offline geknackt werden können. Microsoft räumt deshalb auf: Mit dem Windows-Update ab dem 13. Januar 2026 beginnt die Abkündigung von RC4 für die Kerberos-Authentifizierung, ab April 2026 stellen Domain Controller für Konten ohne explizite Einstellung standardmäßig AES-SHA1-Tickets aus, und bis Mitte 2026 folgt die Durchsetzung. Wer noch NAS-Kisten, Appliances oder Altanwendungen mit reinem RC4 betreibt, plant jetzt die Migration und nicht im Juli. |
|---|
Mit dem Windows-Update, das am oder nach dem 13. Januar 2026 veröffentlicht wurde, kündigt Microsoft die RC4-Verschlüsselung für die Kerberos-Authentifizierung ab. Ab April 2026 ändern Windows-Updates das Standardverhalten der Ticketausstellung auf AES-SHA1 für Konten ohne explizite Verschlüsselungseinstellung, RC4 bleibt nur dort nutzbar, wo es ausdrücklich aktiviert ist; getrieben von CVE-2026-20833 betrifft das jede Umgebung, in der Dienstkonten oder Geräte noch auf RC4 setzen, und nicht explizit für AES-SHA1 konfigurierte Dienstkonten, NAS-Geräte oder Altanwendungen können die Authentifizierung verlieren. Bei neuen Active-Directory-Installationen mit Windows Server 2025 ist RC4 bereits standardmäßig deaktiviert. Motivation ist ausdrücklich Kerberoasting, also die Offline-Knackbarkeit von RC4-Service-Tickets.
Praxis mit klist und die üblichen Denkfehler
Das gute Nachrichten zuerst: Sie brauchen kein Werkzeug aus dem Internet. klist ist Bordmittel und zeigt genau, was der Client wirklich im Cache hat, nicht was er laut Dokumentation haben sollte.
klist lesen, statt raten
Ohne Parameter zeigt klist alle Tickets des angemeldeten Nutzers, mit dem Parameter tickets die Tickets der Dienste, gegen die seit der Anmeldung authentifiziert wurde. Angezeigt werden unter anderem Länge und Algorithmus des Session-Keys, die Startzeit der Ticketanforderung, die Endzeit, ab der das Ticket nicht mehr zur Authentifizierung taugt, die Frist für die Erneuerung und der Zeitversatz zum KDC. Der Zeitversatz ist der stille Held der Fehlersuche. Und ein wichtiger Nebeneffekt der Benutzerkontensteuerung: Ein normales Eingabeaufforderungsfenster zeigt die Tickets des Standardtokens, ein administratives Fenster die des erhöhten Tokens, denn das sind getrennte Sitzungen mit getrennten Ticket-Caches.
Drei Missverständnisse, die Zeit kosten
Erstens: Ein Ticket ist kein Passwort. klist zeigt ausschließlich Metadaten der Tickets, also wer, was, wann und mit welcher Verschlüsselung, aber niemals Klartextpasswörter oder Schlüsselmaterial. Ein gestohlenes Ticket ist trotzdem gefährlich, aber es ist zeitlich begrenzt und an Schlüssel gebunden, nicht das Passwort selbst.
Zweitens: Gruppenänderungen wirken nicht sofort. In Active Directory ist das Hinzufügen zu einer Gruppe in der Datenbank sofort wirksam, im Ticket des Nutzers aber erst, wenn es abläuft oder verworfen wird. Genau dafür gibt es klist purge, aber mit Bedacht: Das Verwerfen zerstört alle zwischengespeicherten Tickets, kann laufende Zugriffe blockieren und macht im schlimmsten Fall eine neue Anmeldung nötig.
Drittens: Ein leerer Cache ist keine Diagnose. Wenn SPN oder Richtlinie falsch sind, entfernt das Verwerfen nur die Spuren und erzwingt denselben Fehler erneut, deshalb erst den Ist-Zustand mit klist festhalten und dann purgen. Nebenbei: Kerberos-Passwortänderungen laufen über Port 464 TCP, nicht über Port 88, und blockierte Regeln lassen Passwortänderungen scheitern, während normale Anmeldungen funktionieren.
|
TIPP Arbeitsablauf für die Fehlersuche: Erst klist ausführen und die Ausgabe speichern, dann den fehlerhaften Zugriff wiederholen, dann klist erneut ausführen und beide Ausgaben vergleichen. Der Vergleich vor und nach dem Versuch verrät mehr als jedes Verwerfen des Caches. Fehlt ein Service-Ticket komplett, ist meist der SPN falsch oder doppelt vergeben. Ist es vorhanden und der Zugriff scheitert trotzdem, liegt das Problem bei den Berechtigungen auf dem Dienst, nicht bei Kerberos. |
|---|
|
INFO Faktenkasten Härtung: Das PAC in Service-Tickets ist seit einigen Jahren durch zusätzliche Signaturen geschützt. Mit den Windows-Sicherheitsupdates ab April 2025 wurde die Durchsetzung abgeschlossen, die Registrierungsschlüssel für den Kompatibilitätsmodus wurden entfernt, und ein Zurückschalten ist nicht mehr vorgesehen. Für die Praxis heißt das: Alle beteiligten Domain Controller und Clients müssen aktuell gepatcht sein, sonst scheitern PAC-Prüfungen und die Fehlersuche beginnt an der falschen Stelle. |
|---|
Die Windows-Sicherheitsupdates ab April 2025 entfernen die Unterstützung für die Registrierungsunterschlüssel PacSignatureValidationLevel und CrossDomainFilteringLevel und erzwingen das neue, sichere Verhalten; einen Kompatibilitätsmodus gibt es danach nicht mehr.
Häufige Fragen
Kann ich mit einem gestohlenen TGT das Passwort auslesen?
Nein. Ein Ticket enthält kein Passwort und keinen Passwort-Hash im Klartext. Es ist ein mit einem fremden Schlüssel verschlüsselter Datensatz plus ein Session-Key. Wer ein TGT hat, kann sich damit für die Restlaufzeit Service-Tickets ausstellen lassen, ohne das Passwort zu kennen. Das ist schlimm genug, aber technisch etwas anderes als ein Passwortdiebstahl.
<<H3_START)>>Warum sieht der Dienst meine neue Gruppe nicht?<<H3_ENDE>>
Weil die Gruppeninformationen im PAC des Tickets stehen und das Ticket vor der Änderung ausgestellt wurde. Neu anmelden oder den Cache verwerfen löst es. Bei Diensten, die unter dem Computerkonto laufen, betrifft das auch die Tickets der Sitzung 0x3e7.
Wie lange gilt ein Service-Ticket wirklich?
Standardmäßig 600 Minuten, aber nie länger als die verbleibende Laufzeit des TGT. Bestehende, bereits authentifizierte Verbindungen laufen weiter, nur neue Verbindungen brauchen ein frisches Ticket.
Muss ich RC4 wirklich abschalten?
Microsoft schaltet es für Sie ab, nur eben nach Microsofts Zeitplan und nicht nach Ihrem. Inventarisieren Sie Dienstkonten und Geräte, prüfen Sie das Attribut msDS-SupportedEncryptionTypes und die Kerberos-Ereignisse auf den Domain Controllern. Zu beachten ist, dass dieses Attribut in Windows Server 2022 und älter aus Kompatibilitätsgründen immer DES und RC4 anzeigt, während ab Windows Server 2025 nur noch AES-SHA1 und stärkere Verfahren erscheinen.
Warum scheitert die Anmeldung, obwohl das Konto stimmt?
In den meisten Fällen wegen der Uhr, eines fehlenden oder doppelten SPN, eines fehlenden AES-Schlüssels am Konto oder weil der Client gar keinen Domain Controller erreicht. klist und die Ereignisse 4768 und 4769 zeigen das in zwei Minuten.
Fazit
Kerberos ist kein Orakel, sondern eine Ausgabestelle mit Öffnungszeiten. Der Authentication Service stellt das TGT aus, der Ticket Granting Service tauscht dieses TGT gegen Service-Tickets, und der Zieldienst prüft sie allein mit seinem eigenen Schlüssel. Der Domain Controller ist bei jedem einzelnen Dateizugriff nicht mehr dabei, und genau deshalb wirken Sperren, Gruppenänderungen und Rechtekorrekturen erst mit der nächsten Ticketausstellung. Zehn Stunden Standardlaufzeit sind hier die Zahl, die Sie im Kopf behalten sollten.
Für den Betrieb heißt das: klist zuerst, Vermutungen später. Die Ausgabe verrät Ticketart, Verschlüsselung, Laufzeit und ausstellenden Domain Controller, und sie verrät nie ein Passwort. Wer zusätzlich rechtzeitig von RC4 auf AES umstellt und die PAC-Härtung vollständig ausgerollt hat, verwandelt Kerberos von einer nächtlichen Überraschung in ein langweiliges, verlässliches Stück Infrastruktur. Langweilig ist in der Authentifizierung das größte erreichbare Kompliment.