Authentifizierung: Kerberos, NTLM und Delegation

„Ich habe sie doch in die Gruppe aufgenommen — sie kommt trotzdem nicht rein.“ Die Mitgliedschaft steht auf allen Domain Controllern, die Berechtigung stimmt, und der Zugriff scheitert weiter. Kein Replikationsproblem: Ihr Kerberos-Ticket trägt die Gruppenliste von vorhin noch mit sich herum. Dieses Modul behandelt, was bei einer Anmeldung tatsächlich passiert — Kerberos gegen NTLM und warum sich NTLM nicht einfach abschalten lässt, der Ticket-Lebenszyklus samt der Autorisierungsdaten im Ticket, SPNs als der Name, an dem alles hängt und der fast immer beim Ändern kaputtgeht, die drei Delegationsvarianten mit sehr unterschiedlichem Blast-Radius, die Zeittoleranz von Kerberos — und die Verschlüsselungstypen, deren fehlendes Attribut eine Härtung Wochen später in einen Ausfall verwandelt.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-06

Zwei Protokolle: Kerberos zuerst, NTLM als Fallback

Eine Windows-Domäne authentifiziert mit zwei Protokollen. Kerberos ist der bevorzugte Weg; NTLM ist der ältere Fallback, der greift, wenn Kerberos nicht funktioniert. Der Unterschied ist nicht kosmetisch, sondern sicherheitsrelevant:

Gegenseitige Authentifizierung: Kerberos: ja — der Client weist sich beim Dienst aus, und der Dienst beweist dem Client seine Identität. NTLM: nein — der Server authentifiziert sich dem Client nicht.
Passwort über die Leitung: Kerberos: nie ein Passwort-Äquivalent im Klartext auf dem Draht; Tickets sind mit Schlüsseln verschlüsselt, die aus dem Passwort abgeleitet sind. NTLM: Challenge-Response — kein Klartext, aber ein relayfähiger Handshake.
Single Sign-On (SSO): Kerberos: einmal anmelden, dann Tickets ohne erneute Passworteingabe. NTLM: pro Dienst neuer Challenge-Response.

MerksatzNTLM ist nicht „kaputt“, aber strukturell schwächer: keine gegenseitige Authentifizierung. Genau das macht NTLM-Relay möglich — ein Angreifer leitet einen Handshake an ein drittes Ziel weiter, weil der Server dem Client nie seine Identität beweist. Kerberos ist deshalb kein Nice-to-have, sondern die sichere Grundlinie.

Der Ticket-Lebenszyklus

Kerberos trennt zwei Schritte: einmal die Identität nachweisen, dann pro Dienst ein kurzlebiges Ticket holen. Das ist der Kern des SSO.

Bei der Anmeldung holt der Client vom KDC (dem Authentication Service, AS) ein TGT — den Nachweis „ich bin angemeldet“. Für jeden Dienst tauscht er das TGT beim Ticket-Granting Service (TGS) gegen ein Service-Ticket. Dieses legt er dem Dienst per AP-REQ vor. Der Dienst prüft es mit seinem eigenen Schlüssel — ohne den KDC erneut zu fragen.

AS-Exchange: Bei der Anmeldung fordert der Client beim KDC (auf jedem Domain Controller) ein Ticket-Granting Ticket (TGT) an. Das TGT ist mit dem Schlüssel des krbtgt-Kontos verschlüsselt — nur der KDC kann es später lesen.
TGS-Exchange: Will der Client einen konkreten Dienst nutzen, legt er das TGT vor und bekommt ein Service-Ticket für genau diesen Dienst, verschlüsselt mit dem Schlüssel des Dienstkontos.
AP-Exchange: Der Client sendet das Service-Ticket per AP-REQ an den Dienst. Der Dienst entschlüsselt es mit seinem eigenen Kontoschlüssel und vertraut ihm — ohne Rückfrage beim KDC.
Lebensdauer: Tickets sind bewusst kurzlebig (Service-Tickets und TGT typischerweise ~10 Stunden, TGT erneuerbar). Ein gestohlenes Ticket ist damit zeitlich begrenzt brauchbar.

Warum das zähltDer Dienst braucht für die Prüfung den KDC nicht — er entschlüsselt das Ticket mit seinem eigenen Schlüssel. Deshalb muss der Client den Dienst unter dem Namen ansprechen, unter dem dessen Schlüssel registriert ist. Dieser Name ist der SPN.

SPN: der Name, an dem Kerberos hängt

Ein Service Principal Name (SPN) verknüpft einen Dienst (z. B. HTTP/web01.corp.example.com oder MSSQLSvc/sql01.corp.example.com:1433) mit dem Konto, unter dem der Dienst läuft. Ohne diese Zuordnung kann der KDC kein Service-Ticket ausstellen, weil er nicht weiß, mit welchem Schlüssel er das Ticket verschlüsseln soll.

Fehlt der SPN, findet der Client kein Ziel für ein Service-Ticket → Kerberos entfällt und Windows fällt (wenn erlaubt) auf NTLM zurück.
Ist ein SPN doppelt auf zwei Konten registriert, ist die Zuordnung mehrdeutig → der KDC verschlüsselt ggf. mit dem falschen Schlüssel, der Dienst kann das Ticket nicht entschlüsseln → Kerberos scheitert (typisch KRB_AP_ERR_MODIFIED).
Zugriff per IP statt FQDN löst standardmäßig keinen SPN-Lookup aus → NTLM. Kerberos verlangt den registrierten Namen.

Double-HopKlassischer Fall: Ein Nutzer meldet sich an einer Web-App an (Hop 1), und die App soll im Namen des Nutzers auf eine Datenbank zugreifen (Hop 2). Der zweite Hop scheitert, weil die Web-App kein Nutzer-Passwort hat und ein Service-Ticket nicht einfach „weiterreichen“ kann. Diesen Sprung löst man nicht mit mehr SPNs, sondern mit Delegation — dem nächsten Thema.

Wo SPNs im Alltag kaputtgehenFast nie beim Anlegen, fast immer beim Ändern. Ein Dienst wechselt das Konto, und der SPN bleibt am alten hängen — jetzt existiert er doppelt oder am falschen Ort. Ein Server bekommt einen zusätzlichen Alias, unter dem ihn alle ansprechen, aber niemand registriert den SPN dafür. Eine Anwendung wird hinter einen Lastverteiler gestellt, und der neue Name hat keinen SPN. In allen drei Fällen funktioniert der Zugriff weiter — nur eben über NTLM, und damit fällt der Bruch erst auf, wenn jemand NTLM einschränkt oder eine Delegation braucht.

Delegation: drei Varianten, sehr unterschiedliches Risiko

Delegation erlaubt einem Dienst, gegenüber einem weiteren Dienst als der ursprüngliche Nutzer aufzutreten (der Double-Hop). Es gibt drei Bauformen — und die Wahl ist eine Sicherheitsentscheidung:

Unconstrained: Der Dienst darf sich gegenüber jedem anderen Dienst als der Nutzer ausgeben. Dazu wird ein weiterreichbares TGT des Nutzers auf dem Dienstserver zwischengespeichert. Wird der Server kompromittiert, hat der Angreifer TGTs beliebiger Nutzer — gefährlich, vermeiden.
Constrained: Delegation nur an eine feste Liste erlaubter SPNs (msDS-AllowedToDelegateTo am Front-End-Konto). Kein Nutzer-TGT wird gecacht. Das Setzen der Liste verlangt ein privilegiertes Recht (SeEnableDelegationPrivilege, standardmäßig Domain Admins).
Resource-Based (RBCD): Die Erlaubnis steht am Ressourcen-/Ziel-Objekt (msDS-AllowedToActOnBehalfOfOtherIdentity): das Ziel bestimmt selbst, wer zu ihm delegieren darf. Vom Ressourcen-Owner setzbar (Schreibrecht am Zielobjekt genügt), funktioniert domänenübergreifend innerhalb des Forests.

Kernmissverständnis„Unconstrained ist am bequemsten, also nehmen wir das“ ist die klassische Falle. Bequemlichkeit erkauft man mit gecachten Nutzer-TGTs auf einem exponierten Server — ein Standard-Angriffspfad. Für neuen Bedarf ist constrained oder RBCD die richtige Grundwahl.

Constrained vs. RBCD: wer die Erlaubnis kontrolliert

Beide begrenzen Delegation sauber — der Unterschied liegt darin, wo und von wem die Erlaubnis gesetzt wird:

Klassisch constrained: konfiguriert am Front-End (dem delegierenden Dienst). Ändern erfordert das privilegierte SeEnableDelegationPrivilege → in der Praxis ein Domain-Admin-Eingriff. Domänenübergreifend eingeschränkt.
RBCD: konfiguriert am Back-End (der Ressource). Der Owner der Ressource kann selbst entscheiden, wer zu ihr delegieren darf, ohne dass ein Domain Admin das Front-End anfassen muss — und es funktioniert über Domänengrenzen im Forest.

MerksatzRBCD dreht die Kontrollrichtung um: nicht „der delegierende Dienst darf zu diesen Zielen“, sondern „diese Ressource akzeptiert Delegation von diesen Aufrufern“. Das passt zu delegierter Verwaltung und domänenübergreifenden Szenarien — der Ressourcen-Owner steuert seinen eigenen Vertrauensrahmen.

Zeit: Kerberos toleriert nur wenig Drift

Kerberos-Tickets tragen Zeitstempel, um Replay zu verhindern. Weichen die Uhren von Client und Dienst zu weit voneinander ab, wird das Ticket abgelehnt. Die tolerierte Abweichung (Max Clock Skew) ist standardmäßig 5 Minuten.

Damit die Domäne synchron bleibt, gibt es eine Zeit-Hierarchie: Der PDC-Emulator der Forest-Root ist die autoritative Zeitquelle; die anderen DCs synchronisieren gegen ihn, Mitgliedserver und Clients gegen ihre DCs. Der Windows-Zeitdienst (w32time) hält diese Kette aufrecht.

Betriebliche KonsequenzBekommt ein Server nach Zeitdrift plötzlich keine Tickets mehr (KRB_AP_ERR_SKEW), ist die Ursache die Uhr, nicht das Konto oder der SPN. Die Antwort ist Zeit reparieren (Server zurück in die w32time-Hierarchie), nicht die Skew-Toleranz aufzudrehen — das schwächt den Replay-Schutz für die ganze Domäne.

Die Zeitquelle der Domäne ist damit ein Einzelpunkt, den man kennen sollte: Läuft der PDC-Emulator der Forest-Root auf einer virtuellen Maschine, deren Host ihm die Zeit aufdrängt, konkurrieren zwei Zeitgeber. Das Ergebnis sind sprunghafte Korrekturen, die reihenweise Tickets ungültig machen — ein Ausfall, der wie ein Netzproblem aussieht und keins ist. Für virtualisierte Domain Controller gilt deshalb: Die Zeitsynchronisierung des Hypervisors gehört abgeschaltet, damit die AD-Hierarchie die einzige Quelle bleibt.

Der PAC: warum eine neue Gruppe erst nach dem Abmelden wirkt

Ein Kerberos-Ticket beweist nicht nur, wer jemand ist — es transportiert auch, was er darf. Diese Autorisierungsdaten stecken in einer eigenen Struktur innerhalb des Tickets.

PAC (Privilege Attribute Certificate) — Der Teil des Kerberos-Tickets, der die Autorisierungsinformationen kodiert — die SID des Kontos und die SIDs aller Gruppen, in denen es Mitglied ist. Der Dienst liest daraus, welche Rechte der Aufrufer mitbringt, ohne dafür das Verzeichnis fragen zu müssen.

Der Klassiker am Helpdesk„Ich habe sie in die Gruppe aufgenommen, sie kommt trotzdem nicht rein.“ Der Grund ist der PAC: Die Gruppenmitgliedschaft wird beim Ausstellen des Tickets hineingeschrieben. Ein bereits ausgestelltes TGT trägt die alte Liste weiter, bis es abläuft oder neu angefordert wird. Eine Gruppenänderung wirkt deshalb erst nach Ab- und Anmeldung — nicht, weil etwas nicht repliziert wäre, sondern weil das Ticket in der Hand des Nutzers noch den alten Stand enthält.

Daraus folgt zugleich der Grund, warum der Dienst den KDC bei der Prüfung nicht braucht: Alles, was er über den Aufrufer wissen muss, steht im Ticket. Das macht Kerberos schnell und skalierbar — und erklärt, warum eine entzogene Berechtigung genauso träge wirkt wie eine gewährte. Bis das Ticket abläuft, gilt der alte Stand.

Die Sicherheitsfolge, die man kennen mussEin Konto zu deaktivieren beendet keine laufende Sitzung und macht ausgestellte Service-Tickets nicht sofort ungültig. Bei einem Sicherheitsvorfall reicht das Deaktivieren allein deshalb nicht — die bestehenden Sitzungen müssen zusätzlich beendet werden.

Verschlüsselungstypen: die stille Fehlerquelle

Kerberos-Tickets werden verschlüsselt, und beide Seiten müssen sich auf ein Verfahren einigen. Welches ein Konto beherrscht, steht in seinem Attribut msDS-SupportedEncryptionTypes. Der Domain Controller wählt danach aus, womit er das Service-Ticket schützt.

Das dokumentierte Verhalten bei fehlendem AttributFehlt das Attribut, behandelt der DC das Zielsystem so, als beherrsche es keine stärkeren Verfahren — er fällt also auf das alte RC4 zurück. Ist auf dem Zielsystem RC4 zugleich abgeschaltet, was in gehärteten Umgebungen inzwischen der Normalfall ist, schlägt die Authentifizierung laut Dokumentation immer fehl. Für verwaltete Dienstkonten hält die Dokumentation deshalb ausdrücklich fest, dass AES gesetzt gehört.

Das Tückische ist die Symptomlage. Der Fehler tritt erst auf, wenn jemand RC4 abschaltet — also im Zuge einer Härtungsmaßnahme, oft Wochen nach dem Anlegen des Kontos. Er trifft nur einzelne Dienste, nämlich die mit fehlendem Attribut, und sieht dabei nach einem Rechte- oder SPN-Problem aus. Wer beim Abschalten alter Verfahren nicht vorher die betroffenen Konten inventarisiert, sucht den Zusammenhang später mühsam rückwärts.

Diagnose: die vier Fragen und ihre Werkzeuge

Authentifizierungsfehler fühlen sich alle gleich an: Etwas geht nicht, und die Meldung hilft nicht. Vier Fragen trennen die Fälle, und für jede gibt es genau ein Werkzeug.

Hat der Nutzer überhaupt Tickets?: klist tickets listet TGT und Service-Tickets der aktuellen Sitzung. Leer oder fehlend heißt: Der Fehler liegt vor dem Dienst.
Wurde Kerberos überhaupt versucht?: Fehlt ein Service-Ticket für den Zieldienst, ist die Sitzung vermutlich über NTLM gelaufen — häufigste Ursache: kein oder falscher SPN.
Ist der SPN eindeutig?: setspn -X sucht doppelte SPNs, mit -F forest-weit. Ein doppelt vergebener SPN bricht Kerberos für beide betroffenen Dienste.
Ist es die Uhr?: Ein Fehler mit KRB_AP_ERR_SKEW benennt die Ursache selbst. Dann ist Zeit zu reparieren, nicht das Konto.

Ein Werkzeug, das man kennen sollte, bevor man es brauchtklist purge verwirft die zwischengespeicherten Tickets der Sitzung. Das ist bei der Fehlersuche extrem nützlich: Danach holt der Client frische Tickets, und man sieht, ob eine Änderung tatsächlich greift, ohne den Umweg über Ab- und Anmelden. Genauso wichtig ist die Kehrseite — wer nach einer Änderung ohne neues Ticket testet, prüft weiterhin den alten Stand und zieht falsche Schlüsse.

Beim Anlegen von SPNsDie Dokumentation empfiehlt ausdrücklich, SPNs mit setspn -S statt mit -A anzulegen: -S prüft vor dem Schreiben, ob der Name bereits existiert. Der Unterschied ist ein Zeichen im Befehl und verhindert genau den Fehler, dessen Suche später Stunden kostet.

Durchgerechnet: „Die Anwendung kommt nicht an die Datenbank“

Ein Double-Hop, vier Prüfungen

Szenario

Eine interne Webanwendung auf web01 soll im Namen des angemeldeten Nutzers auf die Datenbank sql01 zugreifen. Nutzer melden sich an der Webanwendung erfolgreich an; der Datenbankzugriff scheitert mit einem Rechtefehler. Direkt an der Datenbank hat derselbe Nutzer Zugriff.

Anforderungen

Zwischen Anmeldung, Identitätsweitergabe und Berechtigung unterscheiden
Vor jeder Änderung benennen, welche Beobachtung sie rechtfertigt

Schritte

Welche Identität kommt an? Zeigt die Datenbank den Zugriff als anonym oder als Konto der Webanwendung statt als Nutzer, ist es kein Rechteproblem, sondern ein Double-Hop: Die Identität wurde nicht weitergereicht.
Läuft Hop 1 über Kerberos? klist tickets auf dem Client — gibt es ein Service-Ticket für HTTP/web01...? Fehlt es, lief die Anmeldung über NTLM, und NTLM kann die Identität nicht weiterreichen. Dann ist der SPN die Ursache, nicht die Delegation.
Ist der SPN sauber? setspn -X -F prüft auf Duplikate. Ein SPN, der versehentlich an zwei Konten hängt — etwa nach einem Wechsel des Dienstkontos —, macht Kerberos für beide unbrauchbar.
Erst dann Delegation: Steht Kerberos auf Hop 1, ist die Frage, ob web01 gegenüber sql01 delegieren darf. Die Antwort ist eine eingeschränkte Delegation auf genau diesen Zieldienst — nicht die unbeschränkte Variante, weil dort die TGTs aller Nutzer auf einem exponierten Webserver landen.

Merksatz: Delegation ist die letzte Frage, nicht die erste. Wer sie zuerst konfiguriert, repariert eine funktionierende Ebene und lässt die kaputte stehen — und hat am Ende zusätzlich ein Delegationsrecht vergeben, das niemand brauchte.

Warum NTLM nicht einfach abgeschaltet wird

Wenn NTLM strukturell schwächer ist, liegt die Frage nahe, warum es überhaupt noch läuft. Die Antwort ist unbequem: NTLM ist der Weg, den Windows nimmt, wenn Kerberos nicht kann — und die Fälle, in denen Kerberos nicht kann, sind zahlreicher als erwartet.

Zugriff über eine IP-Adresse statt über einen Namen — es gibt keinen SPN für eine IP.
Ein Alias oder ein Lastverteiler-Name, für den niemand einen SPN registriert hat.
Ein fehlender oder doppelter SPN am Dienstkonto.
Zugriffe über Vertrauensstellungen oder aus Umgebungen, in denen der KDC nicht erreichbar ist.
Ältere Anwendungen, die NTLM fest verdrahtet aufrufen.

Warum das Abschalten ein Projekt ist und kein SchalterJeder dieser Fälle wird beim Abschalten von NTLM zu einem Ausfall — und keiner davon ist vorher sichtbar, solange NTLM stillschweigend einspringt. Deshalb ist die erste Stufe einer NTLM-Reduktion niemals das Blockieren, sondern das Protokollieren: erfassen, wer NTLM tatsächlich benutzt, die Fälle einzeln auf Kerberos bringen, und erst danach einschränken. Wer die Reihenfolge umdreht, erfährt seine NTLM-Abhängigkeiten aus Störungsmeldungen.

Das eigentliche Risiko benennenNTLM hat keine gegenseitige Authentifizierung: Der Client prüft nicht, ob er wirklich mit dem gewünschten Server spricht. Damit kann ein Angreifer einen Handschlag weiterleiten und sich gegenüber einem dritten System als der Nutzer ausgeben. Deshalb reicht es nicht, NTLM „ungern“ zu benutzen — die wirksamen Gegenmaßnahmen setzen an der Weiterleitung an: Signierung und Kanalbindung erzwingen, damit ein weitergereichter Handschlag am Ziel nicht mehr gültig ist.

Zusammenfassung — gleich im Check

Du kennst jetzt die Achsen: Kerberos vs. NTLM (gegenseitige Authentifizierung, Relay-Risiko), den Ticket-Lebenszyklus (TGT → Service-Ticket → AP-REQ), SPNs als Voraussetzung von Kerberos (fehlend/doppelt → NTLM oder Fehler, Double-Hop), die drei Delegationstypen und ihre Risiken sowie die Zeitsynchronität mit dem PDC-Emulator als autoritativer Quelle.

Gleich im CheckIn den nächsten Entscheidungen und einer Diagnose-Mission wählst du für konkrete Ops-Situationen selbst — und siehst pro Option, warum sie trägt oder aus welchem konkreten Grund nicht.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität23 Primärquellen · zuletzt geprüft: 2026-09-06

01RFC 4120 — The Kerberos Network Authentication Service (V5)
02Microsoft Learn — Kerberos Authentication Overview
03Microsoft Learn — Service Principal Names (SPNs) and setspn
04Microsoft Learn — Kerberos Constrained Delegation Overview
05Microsoft Learn — Resource-Based Constrained Delegation (msDS-AllowedToActOnBehalfOfOtherIdentity)
06Microsoft Learn — How the Windows Time Service Works (PDC-Emulator, Zeit-Hierarchie)
07Microsoft — Kerberos policy: Maximum tolerance for computer clock synchronization (MaxClockSkew, 5 Minuten)
08Microsoft — Mitigating NTLM relay attacks (SMB/LDAP Signing, Extended Protection for Authentication)
09learn.microsoft.com/en-us/windows-server/secur…hentication-overview
10learn.microsoft.com/en-us/openspecs/windows_pr…e1-9c23-edaaa5f36962
11learn.microsoft.com/en-us/windows-server/admin…ndows-commands/klist
12learn.microsoft.com/en-us/windows-server/admin…dows-commands/setspn
13learn.microsoft.com/en-us/windows-server/secur…ce-accounts-overview
14Microsoft Learn — Service Principal Names (SPNs)
15Microsoft — Kerberos policy: Maximum tolerance for computer clock synchronization (MaxClockSkew)
16Microsoft Learn — How the Windows Time Service Works (PDC-Emulator als autoritative Zeitquelle)
17Microsoft Support — Troubleshooting Kerberos errors (duplicate SPN, KRB_AP_ERR_MODIFIED)
18Microsoft — Mitigating NTLM relay attacks (SMB signing, LDAP signing/channel binding, EPA)
19Microsoft Learn — Microsoft NTLM (protocol overview and security considerations)
20Microsoft Learn — Unconstrained delegation security considerations
21Microsoft Learn — Kerberos Constrained Delegation Overview (SeEnableDelegationPrivilege)
22Microsoft Learn — Network security: Restrict NTLM
23Microsoft Learn — Kerberos authentication overview