Microsoft Kerberos

Kerberos ist seit Windows 2000 das Standard-Authentifizierungsprotokoll in Active-Directory-Umgebungen. Das ist die Theorie. In der Praxis erlebe ich seit weit über zwanzig Jahren regelmäßig, dass Kerberos eben nicht zustande kommt – und kaum jemand merkt es, weil Windows klammheimlich auf das alte NTLM zurückfällt. Es funktioniert irgendwie, also schaut keiner hin. Bis es eben doch nicht mehr funktioniert.

Diese Seite ist der zentrale Einstieg in das Thema Kerberos: Wie das Protokoll arbeitet, warum Service Principal Names das eigentliche Herzstück sind, was bei Multi-Hop-Szenarien passiert und wie man systematisch diagnostiziert, statt am Produktivsystem herumzuraten. Wer es eilig hat, springt direkt zur Diagnose-Checkliste am Ende.

1. Wie Kerberos arbeitet

Kerberos basiert auf einem vertrauenswürdigen Dritten – dem Key Distribution Center (KDC), das in Windows auf jedem Domain Controller läuft. Der Grundgedanke: Statt das Passwort über das Netz zu schicken, beweist der Client seine Identität einmal zentral und erhält dafür Tickets, mit denen er sich anschließend bei beliebigen Diensten ausweist.

Abbildung 1: Der Kerberos-Grundablauf – drei Austausche zwischen Client, KDC und Zielsystem.

Die drei Austausche

• AS-Exchange (Authentication Service): Der Client authentifiziert sich einmalig beim KDC und erhält ein Ticket-Granting Ticket (TGT). Das TGT ist mit einem Schlüssel verschlüsselt, den nur das KDC kennt – der Client kann es selbst nicht lesen, nur vorzeigen.
• TGS-Exchange (Ticket-Granting Service): Will der Client auf einen konkreten Dienst zugreifen, legt er sein TGT vor und nennt den SPN des Zieldienstes. Das KDC stellt daraufhin ein Service-Ticket aus – aber nur, wenn es den SPN eindeutig einem Konto zuordnen kann.
• AP-Exchange (Application): Der Client präsentiert das Service-Ticket direkt beim Zielsystem. Der Dienst kann es prüfen, ohne selbst beim KDC nachzufragen – das ist der Effizienzgewinn von Kerberos gegenüber NTLM.

2. Service Principal Names – das Herzstück

Ein Service Principal Name ist die eindeutige Kennung eines Dienstes in der Active-Directory-Welt. Er verknüpft eine Dienstklasse und einen Host mit genau einem Konto. Wenn ein Client ein Service-Ticket anfordert, geschieht das immer über den SPN – nicht über einen Servernamen, eine IP oder sonst etwas. Der SPN ist die Brücke zwischen „Wohin will ich?“ und „Welches Konto entschlüsselt das Ticket?“.

Abbildung 2: Aufbau eines SPN und die zentrale Fehlerquelle Duplikat.

Anatomie eines SPN

Ein SPN folgt dem Schema

Dienstklasse / Host [: Port [/ Dienstname]]

Beispiel für einen SQL Server: MSSQLSvc/srv-sql01.corp.local:1433. Für HTTP-Dienste typischerweise HTTP/portal.corp.local. Die Service-Klasse ist dabei kein frei wählbarer Text, sondern ein vom jeweiligen Dienst erwarteter Bezeichner.

Die wichtigsten Befehle

Diese drei Kommandos löst in der Praxis den Großteil aller SPN-Fragen:

setspn -L <Konto>      # listet alle SPNs eines Kontos

setspn -Q <SPN>        # sucht ein bestimmtes SPN domainweit

setspn -X              # findet domainweite Duplikate (der erste Griff!)

Unter PowerShell geht das auch über Get-ADUser / Get-ADComputer mit der Eigenschaft servicePrincipalName – nützlich, wenn man programmatisch über viele Konten iterieren will.

3. Multi-Hop und Delegation

Solange ein Client direkt mit einem Dienst spricht, ist Kerberos überschaubar. Spannend wird es, wenn ein Dienst die Identität des Anwenders an einen weiteren Dienst weiterreichen muss – das klassische „Double-Hop-Problem“. Beispiel: Der Anwender meldet sich an einem IIS-Webserver an, der wiederum mit der Identität des Anwenders auf einen SQL Server zugreifen soll. Der zweite Hop kommt nur zustande, wenn Delegation korrekt konfiguriert ist.

Abbildung 3: Multi-Hop-Szenario und die drei Delegationsvarianten.

Welche Delegation wann?

4. Diagnose: Warum kein Kerberos?

Die unangenehmste Variante eines Kerberos-Problems ist die, die nicht weh tut: Es „funktioniert“, aber heimlich per NTLM-Fallback. Performance leidet, Security leidet, und beim nächsten Schritt Richtung Cloud oder bei der Abschaltung von NTLM fällt das Kartenhaus zusammen. Der erste Schritt jeder Diagnose ist deshalb die Frage: Kommt überhaupt ein Kerberos-Ticket zustande?

Abbildung 4: Diagnose-Entscheidungsbaum und die typischen Ursachen.

Die Werkzeuge

• klist – zeigt die zwischengespeicherten Tickets. Taucht hier ein Service-Ticket für den Zieldienst auf, läuft Kerberos. Wenn nicht, ist das schon die halbe Diagnose.
• setspn -X / -Q – Duplikate und Zuordnung der SPNs prüfen.
• Network Monitor / Wireshark – auf KRB- und NTLMSSP-Pakete schauen, um den tatsächlich verwendeten Mechanismus zu sehen.
• Eventlogs (System + Security) – Event-ID 4 (KRB_AP_ERR_MODIFIED), 4768/4769/4771 für Ticket-Vorgänge.

Die üblichen Verdächtigen – Checkliste

• SPN fehlt komplett oder ist doppelt vergeben.
• SPN am falschen Kontotyp (Computer- statt Dienstkonto oder umgekehrt).
• Client spricht den Server über einen Alias/CNAME an, der SPN steht aber nur auf dem A-Record-Namen.
• Delegation fehlt oder ist falsch konfiguriert (Multi-Hop).
• UPN-Suffix- oder Forest-Trust-Problem bei kontenübergreifender Auflösung.
• Ziel liegt nicht in der lokalen Intranet-Zone des Browsers – dann sendet der Client kein Kerberos.
• Kerberos-Ticket zu groß durch zu viele Gruppenmitgliedschaften (MaxTokenSize), Folge: 401-Schleifen oder abgebrochene Verbindungen.

5. Wo Kerberos in der Praxis auftaucht

Kerberos-Probleme sind selten „nur“ Kerberos-Probleme – sie zeigen sich an den Schnittstellen zwischen Systemen. Die häufigsten Schauplätze:

Unterstützung bei Kerberos

Kerberos-Probleme kosten erfahrungsgemäß überproportional viel Zeit, wenn man sie ohne Methodik angeht – weil die Symptome diffus sind und das System scheinbar funktioniert. Ein erfahrener Blick von außen spart hier oft Tage.

Ich unterstütze bei Analyse, Troubleshooting, Konzeption und Coaching rund um Kerberos in Windows-Umgebungen. Details zum Beratungsangebot und zur Vorgehensweise finden Sie auf der Seite Consulting Kerberos & Troubleshooting.

Häufige Fragen zu Kerberos

Warum nutzt Windows NTLM statt Kerberos, obwohl Active Directory vorhanden ist?

Windows fällt automatisch auf NTLM zurück, wenn keine Kerberos-Authentifizierung zustande kommt. Die häufigste Ursache ist ein fehlender oder doppelt vergebener Service Principal Name (SPN). Weitere Gründe sind ein über einen DNS-Alias angesprochener Server, dessen SPN nur auf dem A-Record-Namen steht, oder ein Ziel, das nicht in der lokalen Intranet-Zone des Browsers liegt. Der Fallback fällt oft nicht auf, weil der Zugriff scheinbar funktioniert.

Wie finde ich doppelt vergebene SPNs?

Der Befehl setspn -X listet alle domainweiten SPN-Duplikate auf. Ein Duplikat führt dazu, dass das KDC nicht weiß, mit welchem Schlüssel es das Service-Ticket verschlüsseln soll, und die Ausstellung verweigert. Im System-Eventlog erscheint dann typischerweise Event-ID 4 (KRB_AP_ERR_MODIFIED). setspn -X ist deshalb der erste Griff bei jeder Kerberos-Diagnose.

Was ist das Double-Hop-Problem?

Vom Double-Hop spricht man, wenn ein Dienst die Identität des Anwenders an einen weiteren Dienst weiterreichen muss – etwa ein IIS-Webserver, der mit der Anwenderidentität auf einen SQL Server zugreift. Der zweite Hop kommt nur zustande, wenn Delegation korrekt konfiguriert ist. Ohne Delegation hat der erste Server kein Ticket für den zweiten Dienst, und der Zugriff scheitert.

Welche Delegationsvariante sollte ich verwenden?

Für die meisten Szenarien ist Constrained Delegation die richtige Wahl, weil sie die Weitergabe auf explizit erlaubte Dienste beschränkt. Resource-Based Constrained Delegation (RBCD) ist die modernere, flexiblere Variante und kommt ohne Domain-Admin-Rechte aus, da die Konfiguration an der Zielressource liegt. Unconstrained Delegation sollte vermieden werden, da sie ein erhebliches Sicherheitsrisiko darstellt.

Was bedeutet Protocol Transition beziehungsweise S4U2Self?

Protocol Transition über S4U2Self erlaubt es einem Dienst, ein Kerberos-Ticket im Namen eines Anwenders anzufordern, auch wenn sich dieser nicht per Kerberos angemeldet hat – etwa bei Formular-Login oder NTLM. Das überbrückt den Übergang zwischen verschiedenen Authentifizierungsmechanismen. Dieser Pfad ist mächtig, aber zugleich eine der ergiebigsten Fehlerquellen, insbesondere in Kombination mit falschen UPN-Suffixen oder Trust-Konstellationen.

Wie prüfe ich, ob Kerberos tatsächlich verwendet wird?

Der Befehl klist zeigt die zwischengespeicherten Tickets des aktuellen Kontextes. Erscheint dort ein Service-Ticket für den Zieldienst, läuft Kerberos. Ergänzend lässt sich mit einem Network Monitor oder Wireshark der tatsächlich verwendete Mechanismus prüfen, indem man auf KRB- gegenüber NTLMSSP-Paketen schaut.