Kerberos: Tickets, Schlüssel und vertrauenswürdige Dienste

Kerberos ermöglicht einem Benutzer oder Prozess, sich gegenüber einem Netzwerkdienst auszuweisen, ohne das Kennwort an diesen Dienst zu senden. Client und Server vertrauen dafür einem Key Distribution Center (KDC), das zeitlich begrenzte Tickets und Sitzungsschlüssel ausstellt. Bei einer passwortbasierten Anmeldung wird aus dem Kennwort dennoch ein langfristiger Schlüssel abgeleitet; Passwortqualität, Pre-Authentication und der Schutz des Clients bleiben daher sicherheitsrelevant (RFC 4120, Abschnitte 1.1 und 1.2, RFC 3961, Abschnitt 3).

Für Messaging- und Verzeichnisadministratoren liegt Kerberos häufig neben LDAP, nicht an dessen Stelle. LDAP transportiert Verzeichnisoperationen; Kerberos kann über SASL die Identität für eine LDAP-Sitzung liefern. Weboberflächen verwenden HTTP Negotiate, Windows-Dienste SSPI, Unix-Anwendungen meist GSS-API. Ein Fehler kann deshalb in DNS, Zeit, KDC-Erreichbarkeit, Realm-Zuordnung, Ticket-Cache, SPN, Dienstkonto, Keytab, Verschlüsselungstyp, PAC oder Delegationspolicy entstehen, obwohl die Anwendung nur «Integrated Authentication failed» meldet.

Die Erklärung folgt einem Principal vom ersten Kontakt mit dem KDC über TGT und Service Ticket bis zum Zielservice. Erst danach werden Active-Directory-Erweiterungen, Delegation, Zeitabhängigkeit, Diagnose und Recovery vertieft.

Architekturansatz: vertrauenswürdige dritte Instanz

Kerberos verteilt symmetrische Schlüssel über eine vertrauenswürdige Instanz. Das KDC besitzt Zugriff auf die langfristigen Schlüssel der Principals seines Realms und vereinigt logisch zwei Dienste: Der Authentication Service, AS, stellt ein Ticket-Granting Ticket, TGT, aus; der Ticket-Granting Service, TGS, tauscht dieses TGT gegen ein Ticket für einen konkreten Anwendungsdienst. Der Client/Server-Austausch, AP, findet danach zwischen Client und Dienst statt. Ein Dienst kann ein Service-Ticket normalerweise mit seinem eigenen Schlüssel prüfen, ohne bei jeder Anmeldung erneut das KDC aufzurufen (RFC 4120, Abschnitte 1.2 und 3).

Dieses Modell reduziert Passwortweitergabe und zentrale Online-Prüfungen, erzeugt aber klare Ausfallbereiche. Ohne erreichbaren KDC können neue Tickets nicht ausgestellt werden; bereits vorhandene Tickets können bis zum Ende ihrer Gültigkeit weiter funktionieren. Eine kompromittierte KDC-Datenbank oder ein Realm-Schlüssel gefährdet dagegen die Vertrauenskette des gesamten Realms. Kerberos ist deshalb keine zustandslose Token-Signaturplattform, sondern ein verteiltes System aus KDC-Zustand, Client-Caches, Dienstschlüsseln, Uhren und Namensdiensten.

Kerberos authentisiert Principals und kann Integrität oder Vertraulichkeit für einen GSS-Sicherheitskontext bereitstellen. Es verschlüsselt nicht automatisch den gesamten Nutzdatenstrom einer Anwendung und bietet keine Perfect Forward Secrecy für die im Kerberos-Kern verteilten Sitzungsschlüssel. Anwendungen können Kerberos zur Authentisierung eines separat geschützten Kanals verwenden; TLS bleibt deshalb bei HTTPS oder LDAPS eine eigene Schicht mit eigener Serveridentität und Zertifikatsprüfung (RFC 4120, Abschnitt 10, RFC 4121, Abschnitte 2 und 4).

Principals, Realms und Schlüsselmaterial

Ein Kerberos-Principal ist ein Name innerhalb eines Realms. Benutzer werden häufig als alice@EXAMPLE.CH, Dienste als HTTP/intranet.example.ch@EXAMPLE.CH dargestellt. Der Teil vor @ kann mehrere Komponenten enthalten; Gross-/Kleinschreibung ist im Kerberos-Namensmodell grundsätzlich relevant. Ein DNS-Domainname und ein Kerberos-Realm sind verschiedene Namensräume, auch wenn Realms üblicherweise wie grossgeschriebene DNS-Domains aussehen. Clients benötigen deshalb eine überprüfbare Zuordnung aus Hostname oder DNS-Domain zu Realm (RFC 4120, Abschnitte 6.1 und 7.2.3, MIT Kerberos: Mapping hostnames onto realms).

Langfristige Keys gehören zu Principals. Sitzungsschlüssel werden für einen begrenzten Austausch erzeugt. Ein Ticket enthält unter anderem Client, Server, Realm, Zeitfelder, Flags, Session Key und Authorization Data; sein verschlüsselter Teil ist mit einem Schlüssel des Ziel-Services geschützt. Der Client erhält denselben Session Key in einem für ihn geschützten Antwortteil. Er kann den Ticketinhalt daher transportieren, aber den für den Service verschlüsselten Teil nicht selbst verändern (RFC 4120, Abschnitte 5.3 und 5.4).

Der Key Version Number, KVNO, unterscheidet Generationen eines Principal-Schlüssels. Der Encryption Type, Enctype, legt Algorithmus, Key-Länge, String-to-Key und Prüfsumme fest. Ein Service kann mehrere Keytab-Einträge für denselben Principal mit verschiedenen KVNOs oder Enctypes halten, um eine kontrollierte Rotation zu überstehen. Stimmen Ticket-KVNO und Enctype mit keinem verfügbaren Dienstschlüssel überein, kann der Dienst das Ticket nicht entschlüsseln. «SPN vorhanden» beweist deshalb noch keinen passenden Schlüssel auf dem Zielsystem (RFC 4120, Abschnitt 5.2.9, MIT Kerberos: Keytabs).

Active Directory speichert SPNs im mehrwertigen Attribut servicePrincipalName eines Benutzer- oder Computerkontos. Der SPN verknüpft den vom Client zusammengesetzten Dienstnamen mit genau dem Konto, dessen Key der KDC für das Service-Ticket verwendet. Ein Alias, Load-Balancer-Name oder geändertes Dienstkonto verlangt deshalb eine bewusste SPN-Zuordnung. Doppelte SPNs sind innerhalb ihres Suchbereichs mehrdeutig; ein SPN auf dem falschen Konto führt typischerweise dazu, dass der Dienst das ausgestellte Ticket nicht entschlüsseln kann (Microsoft: Service principal names, Microsoft: setspn).

Eine Keytab ist keine Exportdatei mit beliebig wiederherstellbarer Identität, sondern eine Sammlung realer langfristiger Keys. Jeder Eintrag enthält Principal, KVNO, Enctype und Key. Wer die Datei lesen kann, kann sich als dieser Principal ausgeben. MIT empfiehlt lokale, restriktive Ablage und keine ungeschützte Übertragung. Bei Active-Directory-Interoperabilität kann ktpass Principal, Konto und Keytab verbinden; die gewählten Parameter können dabei Passwort, Salt, KVNO oder Enctype beeinflussen und gehören in einen getesteten Rotationsprozess, nicht in einen einmaligen Installationszettel (MIT Kerberos: Application servers).

Sind Principal, Realm und Schlüssel geklärt, lässt sich der Ticketfluss als drei aufeinanderfolgende Gespräche lesen: AS, TGS und schliesslich der Anwendungsdienst.

Protokollfluss: AS, TGS und AP

Der AS-Austausch beginnt mit KRB_AS_REQ. Ein KDC kann mit KDC_ERR_PREAUTH_REQUIRED antworten und die unterstützten Pre-Authentication-Verfahren nennen. Beim verbreiteten verschlüsselten Zeitstempel beweist der Client Kenntnis seines langfristigen Keys, bevor das KDC ein TGT ausstellt. KRB_AS_REP enthält das TGT, das für den TGS verschlüsselt ist, und einen Antwortteil für den Client. PKINIT ersetzt diesen ersten Nachweis durch Public-Key-Kryptografie und Zertifikate; Kerberos FAST kann Pre-Authentication in einem geschützten Tunnel härten (RFC 4120, Abschnitte 3.1 und 5.2.7, RFC 4556, RFC 6113, Abschnitt 5).

Im TGS-Austausch sendet der Client KRB_TGS_REQ mit dem TGT, einem Authenticator und dem gewünschten Service-Principal. Das KDC prüft Realm-Policy, Ticketflags, Zielprincipal und unterstützte Schlüssel und liefert in KRB_TGS_REP ein Service-Ticket plus einen neuen Client/Service-Session-Key. Das Benutzerpasswort wird dabei nicht erneut benötigt. Ein bereits vorhandenes TGT kann daher für viele Dienste genutzt werden, bis Lifetime, Policy oder Cachezustand eine neue Initialauthentisierung verlangen (RFC 4120, Abschnitt 3.3).

Beim AP-Austausch präsentiert der Client dem Dienst KRB_AP_REQ: das Service-Ticket und einen mit dem Session Key geschützten, frischen Authenticator. Der Dienst entschlüsselt das Ticket mit seinem langfristigen Key, prüft Zielprincipal, Zeiten, Flags und Replayzustand und erhält daraus den Session Key. Fordert der Client gegenseitige Authentisierung, antwortet der Dienst mit KRB_AP_REP. Erst diese Antwort beweist dem Client kryptografisch, dass die Gegenseite den Dienstschlüssel besitzt (RFC 4120, Abschnitte 3.2 und 5.5).

Pre-Authentication schützt nicht gegen jede Offline-Attacke, verändert aber die Voraussetzung. Konten ohne erforderliche Pre-Authentication können eine AS-Antwort liefern, deren passwortgeschützter Teil offline geprüft werden kann. Service-Tickets sind ebenfalls offline analysierbar; schwache Dienstkontopasswörter und RC4 verschärfen dieses Risiko. Der wirksame Schutz besteht aus Pre-Authentication, starken zufälligen Service-Keys oder gMSA, modernen Enctypes, begrenzten Rechten und Auditdaten, nicht aus dem blossen Vorhandensein von Kerberos (RFC 6113, Abschnitt 1, RFC 8429, Abschnitt 5, Microsoft: Detect and remediate RC4 usage).

Tickets, Zeiten, Flags und Transport

Ein Ticket besitzt authtime, optional starttime, endtime und bei erneuerbaren Tickets renew-till. Das TGT ist kein universelles Zugriffstoken: Es richtet sich an den TGS und dient zum Bezug weiterer Tickets. Ein Service-Ticket richtet sich an genau den Serverprincipal. Lifetime und Renewal sind KDC-Policy und können pro Realm oder Konto eingeschränkt werden. Feste Werte wie «zehn Stunden» sind daher Produktdefaults, keine Eigenschaft des Kerberos-Standards (RFC 4120, Abschnitte 2.3 und 5.3).

Flags wie forwardable, forwarded, proxiable, proxy, renewable, initial, pre-authent und ok-as-delegate verändern die Verwendbarkeit eines Tickets. Sie sind keine dekorativen Diagnosefelder. Ein Double-Hop kann scheitern, obwohl das erste Service-Ticket gültig ist, weil ein benötigtes Flag oder eine KDC-Policy fehlt. Umgekehrt erweitert ein forwardbares TGT die Wirkung eines kompromittierten Dienstes. Ticketflags gehören deshalb zu jedem Delegations- und Incident-Nachweis (RFC 4120, Abschnitt 2).

Authenticators und manche Pre-Authentication-Verfahren verwenden Zeit zur Freshness-Prüfung. RFC 4120 lässt die zulässige Abweichung als lokale Policy offen. Active Directory verwendet standardmässig fünf Minuten; diese Toleranz ist kein Ersatz für präzise Zeitsynchronisation. Entscheidend sind Client, KDC und Zielservice: Ein Client kann ein Ticket erhalten und trotzdem am Service mit KRB_AP_ERR_SKEW scheitern, wenn dessen Uhr abweicht (RFC 4120, Abschnitte 3.2.3 und 7.5.1, Microsoft: Kerberos troubleshooting guidance, Microsoft: Windows Time Service).

Kerberos verwendet Port 88 über UDP und TCP. RFC 4120 verlangt TCP-Unterstützung und beschreibt UDP als optional; zu grosse UDP-Antworten können mit KRB_ERR_RESPONSE_TOO_BIG einen TCP-Neuversuch auslösen. PAC, Gruppenmitgliedschaften und weitere Authorization Data vergrössern Tickets. Eine Firewall, die nur kleine UDP-Tests erlaubt oder TCP 88 blockiert, kann daher benutzer- oder gruppenabhängige Ausfälle erzeugen (RFC 4120, Abschnitt 7.2.1, Microsoft: Kerberos KDC configuration keys).

Das Service-Ticket ist nur der kryptografische Nachweis. Damit HTTP, LDAP oder SMB ihn verwenden können, betten GSS-API, SSPI und SPNEGO Kerberos in das jeweilige Anwendungsprotokoll ein.

Einbettung in Anwendungsprotokolle

GSS-API stellt Anwendungen einen mechanismusunabhängigen Security-Context bereit; RFC 4121 definiert den Kerberos-V5-Mechanismus dafür. Windows SSPI erfüllt eine vergleichbare Rolle. SPNEGO handelt zwischen angebotenen GSS-Mechanismen aus und erscheint bei HTTP häufig als Negotiate. Der sichtbare Headername beweist nicht automatisch, dass Kerberos statt NTLM gewählt wurde. Diagnose muss den tatsächlich ausgehandelten Mechanismus und das angeforderte Target Name erfassen (RFC 4121, RFC 4178, Microsoft: Kerberos authentication overview).

SASL GSS-API bindet denselben Kerberos-Mechanismus in Anwendungsprotokolle ein. Das ist etwa bei LDAP, IMAP oder SMTP möglich, wenn Client und Server den Mechanismus anbieten. Nach erfolgreichem GSS-Kontext können SASL Security Layers Integrität oder Vertraulichkeit liefern. Ob sie tatsächlich verwendet werden und wie sie mit TLS zusammenspielen, ist Konfiguration der konkreten Anwendung; GSSAPI im Capability-Listing allein belegt weder SPN noch Channel Protection (RFC 4752).

Der Client bildet den Dienstnamen aus Service Class und Zielhost. Bei HTTP ist typischerweise HTTP/fqdn, bei LDAP ldap/fqdn relevant. Alias, CNAME, Reverse Lookup, Proxy, Clustername und der Hostname in der URL können die gebildete Identität verändern. Der Client muss das Ticket für denselben Principal anfordern, dessen Key der annehmende Dienst besitzt. Ein Load Balancer löst diese Bindung nicht; alle Backendinstanzen benötigen eine konsistente Dienstidentität und Schlüsselstrategie (MIT Kerberos: Application servers – DNS, Microsoft: Service principal names).

Active Directory als Kerberos-Realm

In Active Directory Domain Services ist der KDC in den Domänencontroller integriert. Benutzer-, Computer- und Dienstkonten sind Kerberos-Principals; das Verzeichnis liefert Keys, SPNs, Gruppen, Account Flags und Policies. Der krbtgt-Account repräsentiert den TGS der Domäne. KDC-Verfügbarkeit und KDC-Datenkonsistenz folgen damit DC Locator, DNS, AD-Replikation, Sites und dem Recoverymodell von AD DS, nicht einem separaten Kerberos-Clusterprotokoll (Microsoft: Kerberos authentication overview, MS-KILE: Kerberos V5 Synopsis, DC Locator).

AD fügt Tickets üblicherweise ein Privilege Attribute Certificate, PAC, als Authorization Data hinzu. Es kann unter anderem SIDs, Gruppenmitgliedschaften, Profil- und Policyinformationen sowie Signaturen enthalten. Der KDC erzeugt und signiert diese Daten; der Dienst verwendet sie für Windows-Autorisierung oder lässt sie gegebenenfalls validieren. Kerberos-Kernauthentisierung und AD-Autorisierung sind deshalb getrennte Aussagen: Ein kryptografisch gültiger Principal besitzt nicht automatisch die gewünschte Berechtigung (MS-PAC, MS-KILE: PAC Generation).

Schlüsselmaterial und SPN-Attribute replizieren mit Active Directory. Nach Konto-, Passwort- oder SPN-Änderungen können verschiedene DCs deshalb kurzzeitig unterschiedliche Stände verwenden. Trifft der Client für TGS und der Administrator für die Kontrolle verschiedene DCs, wirkt ein Fehler intermittierend. Ein belastbarer Nachweis nennt den ausstellenden KDC, den Ziel-DC der Verzeichnisabfrage, KVNO, Ticket-Enctype und Replikationsstand. Das gilt besonders bei manuellen Keytab-Rotationen und standortübergreifenden Diensten.

Die Enctype-Auswahl ist die Schnittmenge aus Clientangebot, KDC-Policy, Zielkonto-Keys und Dienstunterstützung. AES-fähige Software genügt nicht, wenn das Konto keine entsprechenden Keys besitzt oder msDS-SupportedEncryptionTypes und Domainpolicy sie ausschliessen. RFC 8429 stuft RC4 und 3DES für Kerberos als veraltet ein; Microsoft dokumentiert die Inventarisierung über die Security Events 4768 und 4769. Eine Ablösung beginnt mit Messung und Keygenerierung, nicht mit dem globalen Abschalten eines Bits (RFC 8429, RFC 8009, Microsoft: Detect and remediate RC4 usage).

Für Windows-Dienste reduzieren Group Managed Service Accounts, gMSA, die manuelle Passwort- und SPN-Verwaltung. Sie ersetzen aber nicht die Prüfung, unter welcher Identität der Prozess tatsächlich läuft, welche Hosts den Managed Password lesen dürfen und welche SPNs auf dem Konto registriert sind. Für Appliances oder Unix-Dienste bleibt häufig eine Keytab nötig; deren Rotation muss mit dem AD-Konto synchronisiert werden (Microsoft: Service Accounts).

Innerhalb einer AD-Domäne ist dieser Weg direkt. Beim Zugriff über Realm- oder Domänengrenzen hinweg kommen Cross-Realm-Tickets und gegebenenfalls mehrere Zwischenstationen hinzu.

Trusts und Cross-Realm-Pfade

Ein Realm-Trust verschmilzt keine Principal-Datenbanken. Cross-Realm-Authentisierung verwendet TGTs für krbtgt/TARGET@SOURCE und gegebenenfalls mehrere Zwischenrealms. Der Client folgt einem Ticketpfad, bis er den Realm des Zielservice erreicht. RFC 6806 ergänzt Referrals und Namenskanonisierung, wie sie insbesondere AD-Umgebungen verwenden. Der im Cache sichtbare Pfad ist deshalb aussagekräftiger als die pauschale Aussage «der Trust ist grün» (RFC 4120, Abschnitte 1.1 und 3.3.3, RFC 6806).

Trust-Richtung, Transitivität, Selective Authentication, SID-Filterung, Name Suffix Routing und verfügbare Enctypes begrenzen, was ein Cross-Realm-TGT praktisch ermöglicht. SPNs müssen im richtigen Forest auffindbar und eindeutig sein. Ein lokaler setspn -Q-Treffer beweist keine forestübergreifende Eindeutigkeit; setspn besitzt dafür Forest- und Domainoptionen. Diagnose dokumentiert jeden Referral-TGT, nicht nur den letzten Service-Ticket-Fehler (Microsoft: Windows Authentication Concepts, Microsoft: setspn).

Ein Ticket zum Frontend berechtigt dieses noch nicht automatisch, im Namen des Benutzers ein Backend anzusprechen. Genau hier beginnt das Double-Hop-Problem.

Delegation und der Double Hop

Beim normalen AP-Austausch erhält ein Frontend keinen frei verwendbaren Benutzer-Key. Soll es im Namen des Benutzers auf ein Backend zugreifen, braucht es ein Delegationsmodell. Forwarded-TGT- beziehungsweise unconstrained Delegation übergibt dem Dienst ein weiterverwendbares TGT und erweitert dessen Wirkung weit über ein einzelnes Backend. Ein kompromittiertes Frontend kann es für Tickets zu anderen Diensten verwenden; diese Form ist daher eine grosse Vertrauensausweitung (RFC 4120, Abschnitte 2.5 und 2.6, MS-SFU: Protocol Overview).

Microsofts Service-for-User-Erweiterungen teilen das Problem. Mit S4U2self kann ein Dienst ein Ticket zu sich selbst im Namen eines Benutzers beziehen, etwa nach einer anderen Frontend-Authentisierung. Mit S4U2proxy fordert er unter KDC-Policy ein Ticket zu einem zweiten Dienst im Namen dieses Benutzers an. Klassische constrained Delegation speichert erlaubte Ziele am Frontendkonto; resource-based constrained Delegation legt die erlaubten Aufrufer am Ressourcenkonto fest. In beiden Fällen sind Ziel-SPN, Ticketflags, Kontoeinstellungen und Trustpfad Teil der Entscheidung (MS-SFU: Overview, MS-SFU: Introduction).

Delegation ist Autorisierung für Identitätsweitergabe, nicht bloss eine Kompatibilitätsoption. Der Admin inventarisiert Frontendprincipal, Backend-SPNs, erlaubte Benutzerklassen, Protocol Transition, Trustgrenzen und den technisch kleinsten Zielumfang. Ein erfolgreicher erster Hop belegt den zweiten nicht; ein direkter Backendtest unter dem Benutzerkontext umgeht umgekehrt die Delegationsgrenze und kann ein falsches positives Ergebnis liefern.

Betriebsmodell, Monitoring und Recovery

Nach Ticketfluss und Delegation stellt sich die Betriebsfrage: Welche Kerberos-Komponente muss verfügbar sein, welcher Nachweis zeigt ihren Zustand und was lässt sich im Notfall wiederherstellen? Die Tabelle ordnet diese Fragen den beteiligten Rollen zu.

Ticket-Caches sind Betriebszustand. Ein Benutzerprozess, Dienstkonto, Container oder Windows Logon Session kann einen anderen Cache sehen als die interaktive Adminshell. Löschen und Neubeziehen eines Tickets ist ein gezielter Test, aber keine Reparatur der zugrunde liegenden SPN-, Key- oder Replikationsursache. Vor dem Purge werden Principal, Ziel-SPN, KDC, KVNO, Enctype, Flags und Zeitfelder erfasst; sonst verschwindet der beste Fehlerbeweis.

Windows protokolliert TGT-Anforderungen unter 4768, Service-Tickets unter 4769, Pre-Authentication-Fehler unter 4771 und weitere AS-Fehler unter 4772, sofern die passenden Advanced-Audit-Policies aktiv sind. Das Volumen ist auf KDCs hoch. Monitoring braucht deshalb Aggregation nach Result Code, Client, Zielservice, DC und Enctype sowie Baselines, statt jeden erfolgreichen TGS Request als Alarm zu behandeln (Microsoft: Advanced Audit Policy Configuration).

Recovery richtet sich nach der KDC-Implementierung. Bei AD DS gehören KDC-Daten und krbtgt zum System-State- und Forest-Recovery-Modell; ein beliebiges Datenbankfile oder ein LDIF-Export ist kein gültiges Kerberos-Backup. Eigenständige MIT-Realm-Betreiber müssen KDC-Datenbank, Stash-/Master-Key-Material, Konfiguration, ACLs und Replikation gemeinsam sichern. Dienst-Keytabs sind zusätzlich zu inventarisieren und nach einem Restore auf KVNO- und Keykonsistenz zu prüfen (Microsoft: Back up the System State data, MIT Kerberos: Backups of secure hosts).

Für die Fehlersuche wird der Weg rückwärts geprüft: Zielname und SPN, vorhandenes Service-Ticket, TGS-Antwort, TGT, Realmfindung, DNS und Zeit.

Diagnosewerkzeuge

Die Diagnose beginnt aus derselben Netzwerkzone, mit demselben Zielnamen, Realm, Benutzer- oder Dienstkontext und derselben Logon Session wie die Anwendung. Testdaten verwenden reservierte Namen. Ticket- und Keytab-Ausgaben können Principals und Infrastruktur offenlegen; Keymaterial selbst darf nie in Tickets, Chat oder Prozessargumenten landen.

KDC und Kennwortdienst über DNS ermitteln

Resolve-DnsName -Type SRV "_kerberos._tcp.example.ch"
Resolve-DnsName -Type SRV "_kerberos._udp.example.ch"
Resolve-DnsName -Type SRV "_kpasswd._tcp.example.ch"

dig +short SRV _kerberos._tcp.example.ch
dig +short SRV _kerberos._udp.example.ch
dig +short SRV _kpasswd._tcp.example.ch

Resolve-DnsName und dig zeigen Priorität, Gewicht, Port und Target. Danach sind A-/AAAA-Auflösung und Erreichbarkeit jedes gelieferten Targets zu prüfen. RFC 4120 definiert DNS-SRV-Discovery, erlaubt aber lokale Realm-Konfiguration; ein leerer SRV-Test beweist deshalb nur dann einen Fehler, wenn der konkrete Client DNS-Discovery verwendet (RFC 4120, Abschnitt 7.2.3, RFC 2782).

Zeit und TCP-Erreichbarkeit vergleichen

w32tm /query /status
w32tm /stripchart /computer:dc1.example.ch /samples:5 /dataonly
Test-NetConnection dc1.example.ch -Port 88

timedatectl status
chronyc tracking
nc -vz dc1.example.ch 88

w32tm und timedatectl zeigen Quelle und Synchronisationszustand; chronyc ergänzt bei Chrony Offset- und Trackingdaten. Test-NetConnection beziehungsweise nc belegen nur TCP 88. UDP, KDC-Protokoll, Realm und Pre-Authentication benötigen einen echten AS-/TGS-Test.

Tickets gezielt neu beziehen und anzeigen

klist purge
klist get HTTP/intranet.example.ch
klist

kdestroy
KRB5_TRACE=/dev/stderr kinit alice@EXAMPLE.CH
kvno HTTP/intranet.example.ch@EXAMPLE.CH
klist -ef

Windows-klist arbeitet im Kontext der gewählten Logon Session. Unter MIT Kerberos löschen kdestroy, beziehen kinit und kvno sowie zeigen klist die Credentials. KRB5_TRACE macht KDC-Auswahl und Protokollpfad sichtbar. Vor purge oder kdestroy ist ein vorhandenes Fehlerticket zu dokumentieren.

SPN und Dienstschlüssel gegeneinander prüfen

setspn -Q HTTP/intranet.example.ch
setspn -X -F
Get-ADUser svc-web -Properties @(
“servicePrincipalName”
“msDS-SupportedEncryptionTypes”
)

klist -kte /etc/krb5.keytab
kvno -k /etc/krb5.keytab \
  HTTP/intranet.example.ch@EXAMPLE.CH

setspn zeigt das AD-Zielkonto und sucht mit -X -F forestweit nach Duplikaten. Get-ADUser liest SPNs und deklarierte Enctypes; ein fehlender Wert hat produktspezifische Fallbacksemantik und darf nicht pauschal als «kein AES» gelesen werden. MIT-klist zeigt Principal, KVNO und Enctype der Keytab; kvno -k fordert ein Ticket an und validiert es gegen die angegebene Keytab.

Fehler einer Protokollphase zuordnen

Die Fehlercodes sind in RFC 4120 normiert; Windows ergänzt Status- und Auditkontext. Automatisierung sollte den numerischen Code, die Phase, den KDC, Clientprincipal und Zielprincipal erhalten. Freitext allein ist weder stabil noch eindeutig. Für Paketanalyse kann Wireshark nach kerberos filtern; verschlüsselte Ticketteile bleiben ohne passende Keys absichtlich unlesbar (RFC 4120, Abschnitt 7.5.9, Microsoft: Kerberos troubleshooting guidance).

Technische Geschichte

Kerberos entstand in den frühen 1980er-Jahren im MIT Project Athena. Das Protokoll baut konzeptionell auf Trusted-Third-Party-Arbeiten von Needham und Schroeder sowie Denning und Sacco auf. Versionen 1 bis 4 wurden im Athena-Umfeld entwickelt; Version 4 war die erste breit eingesetzte Fassung. Der Name verweist auf Kerberos, den mehrköpfigen Wächter der griechischen Mythologie, und steht für die zentrale Vertrauensrolle des KDC (RFC 4120, Abschnitt 1, MIT Kerberos Consortium: Documentation).

Kerberos V5 beseitigte Einschränkungen von Version 4 bei Naming, Ticket-Lifetimes, Kryptografie, Cross-Realm und Erweiterbarkeit. RFC 1510 standardisierte V5 1993. RFC 4120 ersetzte diese Spezifikation 2005 mit Klarstellungen und einer vollständigen ASN.1-Beschreibung. Die Protokollfamilie wurde danach modular erweitert, unter anderem durch PKINIT, Pre-Authentication Framework und FAST, GSS-API, Referrals sowie neue AES-Profile (RFC 1510, RFC 4120, RFC 4556, RFC 6113).

Microsoft machte Kerberos V5 mit Windows 2000 zum zentralen Domänen-Authentisierungsprotokoll und verband es mit AD-Principals, SPNs, PAC, SSPI, Trust-Referrals und Delegationserweiterungen. Parallel blieben MIT Kerberos, Heimdal und weitere Implementierungen interoperabel über IETF-Protokolle und GSS-API. Die Kryptografie entwickelte sich von DES und später RC4 zu AES-Profilen; RFC 8429 leitete 2018 die Ablösung von 3DES und RC4 ein. Die technische Geschichte erklärt, warum Altgeräte, alte Dienstkonten und Trust-Keys noch heute Enctype-Grenzen sichtbar machen, ohne dass der Artikel einen flüchtigen Produktversionsstand festschreibt (MS-KILE, RFC 3962, RFC 8009, RFC 8429).