Kerberos-Delegierung verstehen: von unconstrained bis RBCD

Delegierung ist der Teil von Kerberos, bei dem in Besprechungen reihum genickt wird und anschließend niemand die Folie erklären möchte. Das ist verständlich. Kaum ein anderes Thema in Active Directory hat in zwanzig Jahren drei so unterschiedliche Antworten auf dieselbe Frage hervorgebracht — und kaum ein anderes hat so zuverlässig ganze Domänen mit in den Abgrund gerissen, wenn die falsche Antwort stehen blieb.

Die Frage selbst ist banal: Ein Anwender meldet sich an einem Webportal an, und das Portal muss anschließend eine Datenbank im Namen dieses Anwenders befragen. Nicht im Namen des Portals — im Namen des Anwenders, sonst sieht die Sachbearbeitung aus der Buchhaltung plötzlich die Personaldaten. Der Anwender hat sich aber beim Portal authentifiziert, nicht bei der Datenbank. Irgendjemand muss die Identität also weitertragen. Das ist Delegierung, und alles Weitere ist die Diskussion darüber, wie viel Vertrauen man wem einräumt und wer diese Entscheidung überhaupt treffen darf.

Historisch lauten die drei Antworten: „Vertrau dem Frontend einfach komplett“ (unconstrained), „vertrau ihm für eine Liste von Zielen“ (Constrained Delegation), und schließlich „lass das Ziel selbst entscheiden, wem es vertraut“ (Resource-Based Constrained Delegation, kurz RBCD). Die dritte Antwort ist seit Windows Server 2012 verfügbar, also seit über einem Jahrzehnt. In der Praxis begegnet man trotzdem regelmäßig der ersten — meist an einem Server, den 2011 jemand aufgesetzt hat, der das Unternehmen 2014 verlassen hat.

Dieser Beitrag geht den Dreisprung der Reihe nach durch: was jedes Modell technisch tut, wo es konfiguriert wird, wer es konfigurieren darf und woran man erkennt, dass es nicht tut, was es soll. Mit einem anonymisierten Praxisbeispiel, das in fast jeder Umgebung genauso aussieht, und mit den Stolperfallen, die erfahrungsgemäß den Freitagnachmittag kosten.

Zur Einordnung: Dieser Beitrag ist Teil der Serie rund um Microsoft Kerberos; den Überblick über alle Bausteine gibt die Pillar-Seite /microsoft-kerberos. Warum ein Dienstname überhaupt an einem Konto hängt und was passiert, wenn er an zweien hängt, steht in /spns-richtig-setzen-setspn. Und wer die Unterscheidung zwischen TGT und Service-Ticket noch einmal in Ruhe nachlesen möchte — sie ist für dieses Thema zentral —, findet sie in /kerberos-tickets-tgt-und-service-ticket.

Das Doppelsprung-Problem und drei Antworten darauf

Kerberos ist von Haus aus ein Protokoll für genau einen Sprung. Der Anwender beweist dem Dienst, dass er der ist, der er zu sein behauptet — Punkt, Ende der Zuständigkeit. Was der Dienst danach tut, geht Kerberos nichts an. Genau das wird zum Problem, sobald der Dienst selbst zum Client wird.

Warum der zweite Sprung nicht von allein funktioniert

Das Service-Ticket, das der Webdienst vom Anwender entgegennimmt, ist auf den Webdienst ausgestellt und mit dessen Langzeitschlüssel verschlüsselt. Es ist damit ein Beweis für den Webdienst, kein Ausweis, den der Webdienst weiterreichen könnte. Die Datenbank würde ein solches Ticket nicht einmal entschlüsseln können. Der Webdienst hat also die Wahl: Er greift unter seiner eigenen Identität auf die Datenbank zu — dann muss die Datenbank die Zugriffsrechte des Anwenders selbst kennen und prüfen, was in der Praxis fast nie sauber gebaut wird — oder er besorgt sich ein Ticket, das den Anwender ausweist. Letzteres ist Delegierung.

Dass so etwas überhaupt geht, ist keine Windows-Erfindung. Das Weiterreichen eines weiterleitbaren TGT ist in RFC 4120 vorgesehen. Was Microsoft ergänzt hat, sind die S4U-Erweiterungen: Verfahren, bei denen sich der Dienst das Ticket beim Domänencontroller selbst abholt, statt eines vom Anwender geschenkt zu bekommen. Der Unterschied klingt nach einer Formalie, ist aber der ganze Punkt — im ersten Fall entscheidet der Anwender einmalig und blind, im zweiten Fall entscheidet der Domänencontroller bei jeder einzelnen Anfrage neu.

FAKTEN Die drei Attribute, um die es geht Unconstrained: das Bit TRUSTED_FOR_DELEGATION (0x80000) im Attribut userAccountControl des Frontend-Kontos. Gesetzt von jemandem mit dem Recht SeEnableDelegationPrivilege, das standardmäßig nur die Domänen-Administration hat. Constrained (KCD): das mehrwertige Attribut msDS-AllowedToDelegateTo am Frontend-Konto. Enthält eine Liste von Dienstnamen (SPNs), zu denen weitergereicht werden darf. Ergänzt um das Bit TRUSTED_TO_AUTH_FOR_DELEGATION (0x1000000), wenn auch ein Protokollübergang erlaubt sein soll. RBCD: das Attribut msDS-AllowedToActOnBehalfOfOtherIdentity am Backend-Konto. Enthält keine Namensliste, sondern eine Sicherheitsbeschreibung — technisch dieselbe Struktur wie eine Zugriffssteuerungsliste, gefüllt mit den SIDs der Konten, die hierher delegieren dürfen.

 

Die drei Modelle im direkten Vergleich

Bevor wir in die Einzelheiten gehen, lohnt der Blick auf alle drei nebeneinander. Die entscheidende Spalte ist nicht „welches Attribut“, sondern „wer entscheidet“ — denn daran hängt, ob ein Delegierungsmodell in einer Organisation mit mehr als drei Servern noch handhabbar ist.

Die drei Delegierungsmodelle nebeneinander: gleiche Aufgabe, drei völlig verschiedene Vertrauensmodelle — und bei RBCD dreht sich die Blickrichtung um.

Tabelle 1: Die drei Delegierungsmodelle im Überblick

Kriterium	Unconstrained	Constrained (KCD)	RBCD
Verfügbar seit	Windows 2000	Windows Server 2003	Windows Server 2012
Konfiguriert am	Frontend-Konto	Frontend-Konto	Backend-Konto
Attribut	userAccountControl	msDS-AllowedToDelegateTo	msDS-AllowedToActOnBehalfOfOtherIdentity
Wer darf es setzen	Domänen-Administration	Domänen-Administration	Wer Schreibrecht auf das Backend-Konto hat
Was übertragen wird	Weiterleitbares TGT des Anwenders	Service-Ticket per S4U2Proxy	Service-Ticket per S4U2Proxy
Reichweite	Jeder Dienst der Domäne	Nur die gelisteten SPNs	Nur dieses eine Backend
Über Domänengrenzen	Nur mit ausdrücklich erlaubter TGT-Weitergabe	Klassisch nein	Ja
Protokollübergang	Nicht nötig — das TGT ist ja da	Nur mit gesetztem Bit TRUSTED_TO_AUTH_FOR_DELEGATION	Immer erlaubt, der KDC prüft es nicht
Einsatzempfehlung 2026	Keine. Abschalten.	Nur wo RBCD nicht geht	Standard

 

Unconstrained: die Generalvollmacht mit Blankounterschrift

Die älteste Variante ist zugleich die einfachste und die gefährlichste. Ein Haken im Reiter „Delegierung“, Beschriftung „Computer bei Delegierungen aller Dienste vertrauen (Kerberos only)“. Was dieser Haken bedeutet, steht nicht daneben, und das ist bedauerlich, denn er bedeutet ungefähr: Jeder, der sich hier anmeldet, händigt eine unterschriebene Blankovollmacht aus.

Was technisch passiert

Steht das Bit, teilt der Domänencontroller dem Client bei der Ticketanforderung mit, dass das Zielsystem für Delegierung freigegeben ist. Der Client fordert daraufhin ein weitergeleitetes TGT für sich selbst an und legt es dem Dienst zusammen mit dem Service-Ticket in den Anmeldevorgang. Der Dienst hat damit ein vollwertiges TGT des Anwenders im Arbeitsspeicher liegen — mitsamt dem zugehörigen Sitzungsschlüssel. Er kann damit jedes beliebige Service-Ticket anfordern, für jeden beliebigen Dienst der Domäne, zu jedem Zeitpunkt innerhalb der Ticketgültigkeit.

Es gibt keine Einschränkung, keine Liste, keine Rückfrage. Der Domänencontroller kann auch gar nicht unterscheiden, ob die Anfrage vom Anwender selbst oder vom Dienst kommt — es ist ja dasselbe TGT.

Oben das weitergeleitete TGT, unten S4U2Self und S4U2Proxy. Der Unterschied ist nicht die Anzahl der Pfeile, sondern wer bei Schritt drei noch gefragt wird.

Warum das heute keine Option mehr ist

Der theoretische Einwand war schon 2005 bekannt: Wer den Server übernimmt, übernimmt jeden Anwender, der sich dort je angemeldet hat. In der Praxis interessierte das lange niemanden, weil man annahm, ein Angreifer müsse warten, bis zufällig ein privilegiertes Konto vorbeikommt. Diese Annahme ist seit einigen Jahren hinfällig. Es gibt mehrere gut dokumentierte Verfahren, mit denen sich ein beliebiges Computerkonto — auch ein Domänencontroller — dazu bringen lässt, sich aktiv bei einem anderen Rechner zu authentifizieren; die bekanntesten nutzen die Druckwarteschlangen-Schnittstelle MS-RPRN oder die Dateiverschlüsselungs-Schnittstelle MS-EFSRPC. Ein Angreifer muss also nicht warten. Er ruft an.

Landet auf diesem Weg das TGT eines Domänencontrollers auf einem System mit unconstrained delegation, ist das Verzeichnis in dem Moment offen. Der Weg von dort zur vollständigen Replikation der Kennwortdatenbank ist kurz und gut beschrieben.

WARNUNG Unconstrained delegation ist kein Konfigurationsdetail, sondern eine Kompromittierung mit Vorlaufzeit Jedes Konto mit dem Bit TRUSTED_FOR_DELEGATION ist sicherheitstechnisch so wertvoll wie ein Domänencontroller — denn wer es übernimmt, kommt an alles, wofür sich dort jemand anmeldet oder anmelden lässt. Microsoft Defender for Identity meldet solche Konten unter „Unsichere Kerberos-Delegierung“ als eigene Empfehlung. Wenn dort etwas steht, ist es kein Hinweis zur freien Verfügung, sondern ein Befund. Domänencontroller selbst tragen dieses Bit ab Werk. Das ist normal und darf so bleiben. Alles andere in der Liste ist zu prüfen.

 

Microsoft hat die Notbremse übrigens schon gezogen, ohne dass es viele bemerkt hätten. Seit den Updates vom Juli 2019 ist die Weitergabe von TGTs über eingehende Wald- und externe Vertrauensstellungen standardmäßig abgeschaltet; der sichere Zustand von EnableTGTDelegation lautet „Nein“. Wer damals eine ausgefallene Anwendung hatte und den Zusammenhang nicht kannte, hat den Schalter vermutlich per netdom wieder umgelegt. Das wäre ein guter Kandidat für die nächste Inventur.

Finden, bewerten, abschalten

Bestandsaufnahme: wer trägt die Blankovollmacht? # Alle Konten mit unconstrained delegation – Computer und Benutzer Get-ADComputer -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=524288)' ` -Properties userAccountControl, OperatingSystem, LastLogonDate   Get-ADUser -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=524288)' ` -Properties userAccountControl, ServicePrincipalName   # Domänencontroller herausrechnen – die dürfen das $dcs = (Get-ADDomainController -Filter *).ComputerObjectDN   # Bit entfernen (nach Rücksprache mit dem Anwendungsverantwortlichen!) Set-ADAccountControl -Identity WEB01$ -TrustedForDelegation $false

 

TIPP Zwei Schutzmaßnahmen, die auch ohne Umbau sofort wirken Privilegierte Konten mit „Konto ist vertraulich und kann nicht delegiert werden“ markieren (Set-ADAccountControl -AccountNotDelegated:$true) oder in die Gruppe „Geschützte Benutzer“ aufnehmen. Beides verhindert, dass diese Identitäten überhaupt delegiert werden können — unabhängig davon, was am Server konfiguriert ist. Credential Guard auf Clients aktivieren: Ein System mit aktivem Credential Guard gibt kein weiterleitbares TGT mehr heraus, unconstrained delegation läuft von dort aus schlicht ins Leere. Ein angenehmer Nebeneffekt, der gelegentlich auch alte Anwendungen zum Vorschein bringt.

 

Constrained Delegation klassisch: die Liste am Frontend

Mit Windows Server 2003 kam die naheliegende Verbesserung: Statt „alles“ trägt man ein, wohin genau delegiert werden darf. Der Haken heißt nun „Computer nur für Delegierungen angegebener Dienste vertrauen“, und darunter steht eine Liste. Technisch landet diese Liste im mehrwertigen Attribut msDS-AllowedToDelegateTo am Konto des Frontends.

S4U2Self und S4U2Proxy — die beiden Hälften

Ab hier fließt kein fremdes TGT mehr. Stattdessen holt sich das Frontend zwei Dinge beim Domänencontroller. Erstens per S4U2Self ein Service-Ticket auf sich selbst, ausgestellt im Namen des Anwenders — das dient dazu, die Gruppenzugehörigkeiten des Anwenders in Form eines PAC überhaupt in die Hand zu bekommen, etwa wenn der Anwender sich per Formularanmeldung oder Zertifikat angemeldet hat. Zweitens per S4U2Proxy ein Service-Ticket auf das Backend, unter Vorlage des ersten Tickets. Bei diesem zweiten Schritt prüft der Domänencontroller die Liste. Steht das Ziel nicht darin, gibt es kein Ticket.

Der Rückgabewert bei dieser Ablehnung ist übrigens der wichtigste Fehlercode dieses ganzen Themengebiets: KDC_ERR_BADOPTION. Er bedeutet in neunundneunzig von hundert Fällen nicht „falsche Option“, sondern „diese Delegierung ist nicht erlaubt“. Wer ihn im Netzwerkmitschnitt sieht, muss nicht weitersuchen, sondern nachsehen, wo die Erlaubnis fehlt.

Tabelle 2: Die S4U-Begriffe, sortiert nach dem, was sie wirklich tun

Begriff	Was es tut	Wo es geprüft wird
S4U2Self	Dienst holt sich ein Ticket auf sich selbst im Namen eines Anwenders — auch ohne dass dieser Kerberos benutzt hat	Am anfordernden Konto (Protokollübergang)
S4U2Proxy	Dienst wandelt ein Ticket auf sich selbst in ein Ticket auf ein Backend um	An der Delegierungserlaubnis
Protokollübergang	Anmeldung des Anwenders erfolgte nicht per Kerberos, wird aber trotzdem in ein Kerberos-Ticket überführt	Bit TRUSTED_TO_AUTH_FOR_DELEGATION — bei RBCD nicht prüfbar
Weiterleitbares Ticket	Voraussetzung dafür, dass S4U2Proxy überhaupt greift	Wird vom KDC gesetzt, wenn Delegierung erlaubt ist

 

Der Unterschied zwischen „nur Kerberos“ und „beliebiges Protokoll“

In der grafischen Oberfläche stehen zwei Optionsfelder untereinander, und der Unterschied wird gern übersehen. „Nur Kerberos verwenden“ heißt: Das Frontend darf nur weiterreichen, was ihm der Anwender per Kerberos ohnehin gegeben hat. „Beliebiges Authentifizierungsprotokoll verwenden“ heißt: Das Frontend darf sich für jeden beliebigen Anwender ein Ticket ausstellen lassen, ohne dass dieser Anwender jemals aufgetaucht sein muss. Das ist der Protokollübergang, und er ist erheblich mächtiger, als das Optionsfeld suggeriert.

WICHTIG Ein Dienst mit Protokollübergang kann jeden Anwender behaupten Mit gesetztem TRUSTED_TO_AUTH_FOR_DELEGATION braucht das Frontend keinerlei Beweis, dass ein Anwender jemals da war. Es sagt dem Domänencontroller schlicht einen Kontonamen, und der stellt ein Ticket aus. Die einzige verbleibende Schranke ist die Zielliste. Deshalb ist die Kombination „Protokollübergang plus großzügige Zielliste“ in einer Bewertung genauso zu behandeln wie unconstrained delegation. Sie sieht nur harmloser aus, weil sie eine Liste hat.

 

Wo das Modell organisatorisch scheitert

Der technische Fortschritt gegenüber unconstrained ist real. Der organisatorische Bruch aber auch: Die Erlaubnis steht am Frontend, geändert werden darf sie nur von der Domänen-Administration, und die Ressource — also das Backend, um dessen Daten es geht — wird nie gefragt. Wer eine Datenbank betreibt, kann nicht einmal feststellen, welche Frontends berechtigt sind, in seinem Namen aufzutreten. Er kann es nur erraten, indem er die gesamte Domäne nach Einträgen durchsucht, die auf seinen SPN zeigen.

Dazu kommt: Klassisches KCD funktioniert innerhalb einer Domäne. Sobald das Backend in einer anderen Domäne steht — bei Zusammenschlüssen, Ausgründungen und gewachsenen Konzernstrukturen der Normalfall —, endet der Weg. Genau an dieser Stelle setzt RBCD an.

Klassisches KCD in PowerShell — beachten Sie, wessen Konto angefasst wird # Klassisches KCD: alles am Frontend-Konto Set-ADComputer -Identity WEB01 -Add @{ 'msDS-AllowedToDelegateTo' = @( 'MSSQLSvc/backend01.beispiel.intern:1433', 'MSSQLSvc/backend01.beispiel.intern' ) }   # Nachsehen, was dort steht Get-ADComputer WEB01 -Properties msDS-AllowedToDelegateTo | Select-Object -ExpandProperty msDS-AllowedToDelegateTo

 

RBCD: die Ressource entscheidet — und dreht die Richtung um

Resource-Based Constrained Delegation kehrt die Blickrichtung um. Nicht das Frontend trägt ein, wohin es darf, sondern das Backend trägt ein, wer zu ihm darf. Das klingt nach einer Verschiebung von Zuständigkeiten, und genau das ist es auch — es ist die eigentliche Neuerung, wichtiger als jedes technische Detail.

Dieselben zwei Konten, dieselbe Aufgabe, gegenläufige Eintragungsrichtung. Bei RBCD bleibt das Frontend-Konto vollständig unberührt.

Was in dem Attribut tatsächlich steht

msDS-AllowedToActOnBehalfOfOtherIdentity enthält keine Namen und keine SPNs, sondern eine binäre Sicherheitsbeschreibung. In deren Zugriffssteuerungsliste stehen die SIDs der Konten, die im Namen anderer auf dieses Backend zugreifen dürfen. Das ist bemerkenswert, weil es zwei Konsequenzen hat, die man kennen muss: Erstens ist die Erlaubnis an die SID gebunden und nicht an den Kontonamen. Zweitens darf jeder, der Schreibrecht auf dieses eine Attribut hat, die Liste ändern — kein Domänenrecht erforderlich.

Die zweite Konsequenz ist die gute Nachricht und die schlechte zugleich. Gut, weil das Betriebsteam einer Anwendung seine eigene Delegierung einrichten kann, ohne einen Änderungsantrag an die Verzeichnisverwaltung zu stellen. Schlecht, weil genau dieses Schreibrecht in vielen Umgebungen versehentlich viel zu breit vergeben ist — dazu weiter unten mehr.

FAKTEN Voraussetzungen und Eigenheiten von RBCD Der Domänencontroller in der Domäne der Ressource muss mindestens Windows Server 2012 sein. Die Waldfunktionsebene spielt keine Rolle, ein Schemaupdate ist nicht nötig — das Attribut existiert seit dem 2012er Schema. Der Protokollübergang lässt sich bei RBCD nicht abschalten: Der KDC erlaubt ihn immer, so als wäre das Bit gesetzt. Microsoft dokumentiert das ausdrücklich. Als Ausgleich dafür gibt es zwei wohlbekannte SIDs, die im Ticket mitgeführt werden: S-1-18-1 (AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITY) steht für „der Anwender hat sich wirklich mit eigenen Anmeldedaten ausgewiesen“, S-1-18-2 (SERVICE_ASSERTED_IDENTITY) für „ein Dienst behauptet das nur“. Ein Backend kann über eine gewöhnliche Rechtevergabe darauf reagieren. RBCD funktioniert über Domänengrenzen hinweg. Über Waldgrenzen ist es technisch möglich, aber deutlich voraussetzungsreicher — für den Regelfall sollte man es nicht einplanen.

 

Praxisbeispiel: Webdienst unter Maschinenkonto

Das folgende Szenario ist anonymisiert, aber in der Sache in nahezu jedem Haus identisch. Ein internes Portal läuft auf zwei Windows-Servern hinter einer Lastverteilung. Der Anwendungspool läuft nicht unter einem eigenen Dienstkonto, sondern unter NETWORK SERVICE — das heißt, nach außen tritt der Dienst unter dem Maschinenkonto des jeweiligen Servers auf. Die HTTP-Verarbeitung übernimmt http.sys im Kernmodus, und der SPN für den gemeinsamen Portalnamen ist entsprechend an beiden Maschinenkonten hinterlegt. Das Portal soll nun im Namen des angemeldeten Anwenders auf eine Datenbank zugreifen.

Das Standardszenario: zwei Webknoten unter Maschinenkonto, ein Backend, ein einziger Befehl — ausgeführt gegen die Ressource, nicht gegen das Frontend.

Der wesentliche Punkt: Weil kein Dienstkonto im Spiel ist, sind die Maschinenkonten WEB01$ und WEB02$ die handelnden Identitäten. Das ist betrieblich die bessere Variante — Windows verwaltet das Kennwort selbst und wechselt es turnusmäßig, niemand muss es irgendwo hinterlegen. Für die Delegierung heißt es lediglich, dass die Maschinenkonten in die Gästeliste des Backends gehören.

Die PowerShell-Handgriffe

RBCD einrichten, prüfen, erweitern und wieder entfernen # 1) Eintragen – ausgeführt gegen das BACKEND-Konto $web = Get-ADComputer -Filter 'Name -like "WEB0*"' Set-ADComputer -Identity SQL01 -PrincipalsAllowedToDelegateToAccount $web   # 2) Kontrolle – liefert aufgelöste Konten, nicht Rohbytes Get-ADComputer SQL01 -Properties PrincipalsAllowedToDelegateToAccount | Select-Object -ExpandProperty PrincipalsAllowedToDelegateToAccount   # 3) Erweitern – ACHTUNG: der Parameter ersetzt, er ergänzt nicht $prop = 'PrincipalsAllowedToDelegateToAccount' $alle = (Get-ADComputer SQL01 -Properties $prop).$prop $neu = Get-ADComputer WEB03 Set-ADComputer -Identity SQL01 -PrincipalsAllowedToDelegateToAccount ($alle + $neu)   # 4) Entfernen – vollständig Set-ADComputer -Identity SQL01 -PrincipalsAllowedToDelegateToAccount $null

 

WARNUNG Der häufigste Fehler beim zweiten Termin -PrincipalsAllowedToDelegateToAccount setzt die Liste, es hängt nichts an. Wer beim Hinzufügen des dritten Webknotens nur diesen einen übergibt, hat die beiden anderen in derselben Sekunde ausgetragen. Der Ausfall zeigt sich nicht sofort, sondern erst, wenn die vorhandenen Tickets ablaufen — was die Fehlersuche zuverlässig in die falsche Richtung schickt. Merksatz für die Änderungsdokumentation: Immer erst lesen, dann die Menge bilden, dann schreiben. Und danach lesen, was tatsächlich drinsteht.

 

Wer nachsehen möchte, was im Rohattribut steht — etwa weil PrincipalsAllowedToDelegateToAccount leer bleibt, obwohl das Attribut gefüllt ist —, muss die Sicherheitsbeschreibung selbst auspacken. Das ist kein Hexenwerk, gehört aber nicht zum Alltagswissen:

Rohansicht: welche SIDs stehen wirklich in der Gästeliste? $attr = 'msDS-AllowedToActOnBehalfOfOtherIdentity' $roh = (Get-ADComputer SQL01 -Properties $attr).$attr $sd = New-Object System.Security.AccessControl.RawSecurityDescriptor($roh, 0) $sd.DiscretionaryAcl | ForEach-Object { $_.SecurityIdentifier }

 

Ein Sonderfall, der überrascht: das Frontend ist ein Benutzerkonto

Läuft der Anwendungspool doch unter einem klassischen Dienstkonto, ändert sich am Prinzip nichts, wohl aber am Befehl: Man übergibt dann ein Benutzerobjekt statt eines Computerobjekts. Bei einem gruppenverwalteten Dienstkonto entsprechend ein Objekt aus Get-ADServiceAccount. Wichtig ist nur, dass das Frontend-Konto einen SPN besitzt — ohne SPN gibt es kein S4U2Proxy, weil der Domänencontroller sonst keinen Dienst erkennt, der delegieren könnte.

Frontend als Benutzer- oder gruppenverwaltetes Dienstkonto $svc = Get-ADUser svc-portal # klassisches Dienstkonto $gms = Get-ADServiceAccount gmsa-portal # gruppenverwaltetes Dienstkonto (gMSA) Set-ADComputer -Identity SQL01 -PrincipalsAllowedToDelegateToAccount @($svc, $gms)

 

Stolperfallen, Fehlerbilder und die Kehrseite

RBCD ist einfach genug, dass es in fünf Minuten eingerichtet ist. Genau das erzeugt die typischen Fehlerbilder: Es funktioniert im Test, es funktioniert drei Monate, und dann funktioniert es nicht mehr, ohne dass jemand etwas an der Delegierung geändert hätte.

Der Diagnosepfad in vier Fragen. Die Reihenfolge ist kein Vorschlag — Frage drei zu beantworten, bevor Frage eins geklärt ist, kostet nur Zeit.

Konto gelöscht, Konto neu angelegt, SID gewechselt

Das ist der Klassiker, und er trifft ausgerechnet die Sorgfältigen. Ein Webknoten wird neu aufgesetzt. Weil man es ordentlich machen will, wird das alte Computerkonto vorher aus dem Verzeichnis gelöscht und beim Domänenbeitritt neu angelegt. Gleicher Name, gleicher Standort, gleiche Gruppen — und eine neue SID. In der Gästeliste des Backends steht aber die alte. Der Domänencontroller findet beim S4U2Proxy-Vergleich keine Übereinstimmung und lehnt ab: KDC_ERR_BADOPTION.

Das Tückische daran ist die Anzeige. Get-ADComputer mit PrincipalsAllowedToDelegateToAccount versucht, die SIDs in Namen aufzulösen. Eine verwaiste SID lässt sich nicht auflösen und fällt aus der Ausgabe heraus — das Ergebnis ist eine leere oder unvollständige Liste, obwohl das Rohattribut gefüllt ist. Wer nur die aufgelöste Ansicht kennt, sucht dann den Fehler dort, wo keiner ist.

TIPP Wiedereintritt in die Domäne statt Neuanlage Ein Rechner kann derselben Domäne mit demselben Computerkonto neu beitreten, ohne dass das Konto gelöscht werden muss — dann bleibt die SID erhalten und sämtliche Delegierungs-, Gruppen- und Rechtezuweisungen überleben die Neuinstallation. Wenn das Konto doch neu angelegt werden muss: RBCD gehört auf die Nachbereitungsliste des Wiederaufbaus, direkt neben SPNs und Zertifikate. Ein Zweizeiler in der Ablaufbeschreibung erspart später eine Stunde Netzwerkmitschnitt. Gleiches gilt sinngemäß nach einer Domänenmigration: SID-Historie hilft an vielen Stellen, in msDS-AllowedToActOnBehalfOfOtherIdentity aber nicht zuverlässig. Die Einträge sind neu zu setzen.

 

Der Ticket-Zwischenspeicher lügt Sie an

Die zweithäufigste Ursache für „das funktioniert immer noch nicht“ ist schlicht ein alter Eintrag im Zwischenspeicher. Weder Client noch Server fragen den Domänencontroller erneut, solange ein Ticket gültig ist — und auch ein negatives Ergebnis wird nicht in Sekunden vergessen. Nach jeder Änderung an der Delegierung gehört deshalb ein Leeren des Zwischenspeichers dazu, und zwar in der richtigen Anmeldesitzung.

Zwischenspeicher leeren — und zwar dort, wo der Dienst läuft klist purge # aktuelle Anwendersitzung klist purge -li 0x3e7 # Sitzung des Maschinenkontos (SYSTEM) klist sessions # welche Sitzungen gibt es überhaupt? klist get MSSQLSvc/backend01.beispiel.intern:1433 # gezielt anfordern

 

Der Zusatz -li 0x3e7 ist der eigentlich wichtige. Ein Webdienst unter Maschinenkonto arbeitet in der Anmeldesitzung von SYSTEM; ein klist purge in der Administratorsitzung räumt dort gar nichts weg. Wer das nicht weiß, startet stattdessen den Server neu — was ebenfalls hilft, aber am Sonntagvormittag erklärungsbedürftig ist.

Konten, die sich nicht delegieren lassen wollen

Manchmal liegt es nicht am Server, sondern am Anwender. Ist am Benutzerkonto „Konto ist vertraulich und kann nicht delegiert werden“ gesetzt, oder ist der Anwender Mitglied der Gruppe „Geschützte Benutzer“, stellt der Domänencontroller kein weiterleitbares Ticket aus — und damit endet jede Delegierung. Das ist korrektes und gewünschtes Verhalten, führt aber zu Fehlerbildern der Kategorie „bei allen anderen geht es“. Und da diese Kennzeichnung meist bei privilegierten Konten gesetzt ist, testet ausgerechnet die Person, die den Test durchführt, regelmäßig einen Sonderfall.

Die Kehrseite: RBCD als Angriffspfad

Dieselbe Eigenschaft, die RBCD betrieblich so angenehm macht — die Ressource entscheidet, kein Domänenrecht erforderlich —, macht es zu einem der beliebtesten Werkzeuge für Rechteausweitung. Wer Schreibrecht auf ein Computerkonto erlangt, kann sich dort selbst als delegierungsberechtigt eintragen und anschließend ein Ticket im Namen eines beliebigen Anwenders auf dieses System anfordern. Aus „Schreibrecht auf ein Objekt“ wird so binnen Minuten „Administrator auf dem zugehörigen Server“.

Für den zweiten Baustein sorgt eine Voreinstellung, die seit Windows 2000 unverändert ist: ms-DS-MachineAccountQuota steht auf 10. Jeder authentifizierte Domänenbenutzer darf also zehn Computerkonten anlegen — und braucht damit für den Angriff nicht einmal ein vorhandenes Konto zu übernehmen, sondern bringt sein eigenes mit.

Tabelle 3: Woraus ein RBCD-Angriff besteht — und wo man ihn unterbricht

Baustein des Angriffs	Voreinstellung	Gegenmaßnahme
Angreifer braucht ein Konto mit SPN	Jeder Anwender darf 10 Computerkonten anlegen	ms-DS-MachineAccountQuota auf 0 setzen, Anlage delegieren
Angreifer braucht Schreibrecht am Ziel	Oft historisch breit vergeben (Ersteller, Hilfsgruppen, Altprojekte)	Rechte auf Computerobjekte regelmäßig prüfen, besonders WriteDACL und WriteProperty
Angreifer braucht Protokollübergang	Bei RBCD immer erlaubt, nicht abschaltbar	Sensible Konten als „vertraulich“ kennzeichnen oder in „Geschützte Benutzer“ aufnehmen
Angreifer braucht eine Zwangsauthentifizierung	Diverse Schnittstellen erlauben das Anstoßen	Signierung und Kanalbindung erzwingen, nicht benötigte Dienste abschalten

 

WICHTIG Zum Bronze-Bit als historische Fußnote CVE-2020-17049, im November 2020 veröffentlicht und unter dem Namen „Bronze Bit“ bekannt geworden, erlaubte es, ein nicht weiterleitbares S4U2Self-Ticket so zu verändern, dass der Domänencontroller es dennoch für die Delegierung akzeptierte — womit sich unter anderem die Gruppe „Geschützte Benutzer“ umgehen ließ. Microsoft hat die Prüfung des KDC korrigiert; die Durchsetzung war für Mai 2021 vorgesehen. Für heutige Umgebungen ist das gepatcht und erledigt. Erwähnenswert bleibt es, weil es zeigt, worauf die gesamte Sicherheit dieses Modells beruht: darauf, dass der Domänencontroller ein einzelnes Ticketflag korrekt auswertet.

 

Fazit

Der Dreisprung von unconstrained über klassisches KCD zu RBCD ist im Kern keine technische, sondern eine organisatorische Entwicklung. Technisch tun alle drei dasselbe: Sie sorgen dafür, dass ein zweiter Sprung im Namen des Anwenders stattfinden kann. Der Unterschied liegt darin, wer die Entscheidung trifft und wer sie später noch nachvollziehen kann. Unconstrained trifft sie einmal, pauschal und unwiderruflich. Klassisches KCD trifft sie zentral, aber am falschen Ende. RBCD legt sie dorthin, wo das Interesse an einer richtigen Entscheidung am größten ist: zum Eigentümer der Ressource.

Für die Praxis heißt das drei Dinge. Erstens: unconstrained delegation gehört auf die Ausrottungsliste, nicht auf die Prüfliste — jedes solche Konto ist so schützenswert wie ein Domänencontroller. Zweitens: Neue Delegierungen werden als RBCD gebaut, am Backend-Konto, mit einem klar benannten Verantwortlichen. Drittens: Das Schreibrecht auf Computerkonten ist ab sofort ein sicherheitsrelevantes Recht und keine Formsache mehr — wer es hat, kann sich selbst zur Delegierung einladen.

Und wenn doch etwas klemmt: erst die SIDs prüfen, dann den Zwischenspeicher leeren, dann das Anwenderkonto ansehen, dann den SPN. In dieser Reihenfolge. Die allermeisten Fälle sind nach den ersten beiden Schritten erledigt — und die restlichen sind wenigstens interessant.

Häufige Fragen

Muss ich am Frontend-Konto für RBCD irgendetwas einstellen?

Nein, und das ist der ganze Punkt. Weder ein Haken im Reiter „Delegierung“ noch ein Eintrag in msDS-AllowedToDelegateTo, noch ein Bit im userAccountControl. Die einzige Voraussetzung am Frontend ist, dass das Konto einen Dienstnamen besitzt — ohne SPN erkennt der Domänencontroller kein delegierendes Dienstkonto. Bei Maschinenkonten ist diese Voraussetzung ohnehin erfüllt.

Kann ich klassisches KCD und RBCD gleichzeitig für dasselbe Ziel verwenden?

Ja, die beiden Mechanismen schließen sich nicht aus; der Domänencontroller prüft beide Wege. In der Übergangsphase einer Umstellung ist das durchaus sinnvoll. Dauerhaft ist es eine schlechte Idee, weil dann zwei Stellen dieselbe Aussage treffen und irgendwann nur noch eine davon gepflegt wird. Nach erfolgreicher Umstellung gehört der alte Eintrag am Frontend entfernt.

Warum liefert Get-ADComputer eine leere Liste, obwohl das Attribut gefüllt ist?

Weil PrincipalsAllowedToDelegateToAccount eine bequeme Übersetzung ist: Die Eigenschaft löst die gespeicherten SIDs in Objekte auf. Verwaiste SIDs — etwa nach einer Konto-Neuanlage — lassen sich nicht auflösen und erscheinen deshalb gar nicht. Die Rohansicht über msDS-AllowedToActOnBehalfOfOtherIdentity und einen RawSecurityDescriptor zeigt dann, was wirklich dort steht.

Funktioniert RBCD über Domänen- und Waldgrenzen hinweg?

Über Domänengrenzen ja — das war einer der Hauptgründe für die Einführung, denn klassisches KCD scheitert dort. Über Waldgrenzen ist es technisch möglich, aber an deutlich mehr Bedingungen geknüpft und in der Fehlersuche unangenehm. Für Architekturen, die über einen Waldwechsel hinweg delegieren müssten, lohnt es sich, zuerst die Frage zu stellen, ob der zweite Sprung nicht ganz vermeidbar ist.

Wie finde ich heraus, welche Delegierungen in meiner Umgebung überhaupt existieren?

Für unconstrained hilft der LDAP-Filter auf das Bit 524288 im userAccountControl. Für klassisches KCD sucht man nach Objekten mit gefülltem msDS-AllowedToDelegateTo. Für RBCD nach gefülltem msDS-AllowedToActOnBehalfOfOtherIdentity. Drei Abfragen, ein Bericht — und in aller Regel mindestens eine Überraschung. Microsoft Defender for Identity fasst denselben Befund als Empfehlung „Unsichere Kerberos-Delegierung“ zusammen, falls vorhanden.

Nach dem Wiederaufbau eines Servers klemmt die Delegierung. Was ist zuerst zu prüfen?

Die SID. Wurde das Computerkonto beim Wiederaufbau gelöscht und neu angelegt, zeigt der Eintrag am Backend ins Leere, und es hilft nur, ihn neu zu setzen. Danach den Ticket-Zwischenspeicher in der Sitzung des Maschinenkontos leeren (klist purge -li 0x3e7) und erst dann erneut testen. Wer diese Reihenfolge umdreht, misst zweimal dasselbe alte Ergebnis.

Ist RBCD wirklich sicherer, wenn es doch als Angriffstechnik bekannt ist?

Ja — die Angriffstechnik nutzt nicht eine Schwäche von RBCD, sondern zu breit vergebene Schreibrechte plus eine großzügige Voreinstellung bei der Anlage von Computerkonten. Dieselben zu breiten Rechte wären auch ohne RBCD ein Problem, nur wäre der Weg zur Rechteausweitung etwas länger. Wer ms-DS-MachineAccountQuota auf 0 setzt und die Rechte auf Computerobjekte aufräumt, hat den Pfad geschlossen und behält den betrieblichen Vorteil.

Was bedeutet KDC_ERR_BADOPTION in diesem Zusammenhang?

In neunundneunzig von hundert Fällen: „Diese Delegierung ist nicht erlaubt.“ Der Fehlercode taucht bei der S4U2Proxy-Anforderung auf, wenn der Domänencontroller weder in msDS-AllowedToDelegateTo des Frontends noch in msDS-AllowedToActOnBehalfOfOtherIdentity des Backends eine passende Erlaubnis findet. Der Name des Fehlers ist irreführend, seine Aussage nicht.

Quellen

Sämtliche Angaben wurden gegen die folgenden Primärquellen geprüft; Stand der Recherche ist der 2. September 2026.

Microsoft Learn: Kerberos Constrained Delegation Overview in Windows Server — https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constrained-delegation-overview

Microsoft Learn: [MS-SFU] Kerberos Protocol Extensions — Service for User and Constrained Delegation, Abschnitt 1.3.3 Protocol Overview — https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/1fb9caca-449f-4183-8f7a-1a5fc7e7290a

Microsoft Learn: [MS-SFU] Gesamtspezifikation — https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94

Microsoft Learn: Set-ADComputer (ActiveDirectory-Modul) — https://learn.microsoft.com/en-us/powershell/module/activedirectory/set-adcomputer

Microsoft Learn: Accounts security posture assessment — Unsichere Kerberos-Delegierung, Defender for Identity — https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/accounts

Microsoft Support: Updates to TGT delegation across incoming trusts in Windows Server — https://support.microsoft.com/en-us/topic/updates-to-tgt-delegation-across-incoming-trusts-in-windows-server-1a6632ac-1599-0a7c-550a-a754796c291e

Microsoft Security Response Center: CVE-2020-17049, Kerberos KDC Security Feature Bypass Vulnerability — https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-17049

Microsoft Security Blog: Detecting and preventing privilege escalation attacks leveraging Kerberos relaying (KrbRelayUp) — https://www.microsoft.com/en-us/security/blog/2022/05/25/detecting-and-preventing-privilege-escalation-attacks-leveraging-kerberos-relaying-krbrelayup/

Microsoft Learn: Making the second hop in PowerShell Remoting — https://learn.microsoft.com/en-us/powershell/scripting/security/remoting/ps-remoting-second-hop

IETF RFC 4120: The Kerberos Network Authentication Service (V5), Abschnitt 2.8 — https://www.rfc-editor.org/rfc/rfc4120

 

Weiterführend in dieser Serie: /microsoft-kerberos (Pillar-Seite zur gesamten Serie), /spns-richtig-setzen-setspn (Dienstnamen ohne Kollateralschaden setzen), /kerberos-tickets-tgt-und-service-ticket (TGT und Service-Ticket im Klartext).