Constrained Delegation Schritt für Schritt einrichten

Delegierung ist eines dieser Themen, bei denen die halbe IT-Welt reflexhaft zusammenzuckt – zu Recht, wenn man die uneingeschränkte Variante meint. Die constrained, also eingeschränkte Delegierung, ist dagegen ein sauberes, gut beherrschbares Werkzeug. Sie löst ein Problem, das in jeder gewachsenen Umgebung irgendwann auftaucht: Ein Dienst muss im Namen des Benutzers auf einen zweiten Dienst zugreifen. Webserver holt Daten aus der Datenbank, Reporting-Frontend fragt das Backend – und plötzlich landet man beim berüchtigten Double-Hop. Dieser Artikel führt Sie ohne Umwege durch die Einrichtung.

Erst die Landkarte: drei Arten von Delegierung

Bevor wir konfigurieren, kurz die Einordnung – sonst richten Sie am Ende das Falsche ein. Active Directory kennt drei Spielarten der Delegierung, und sie unterscheiden sich vor allem darin, wie weit das Vertrauen reicht.

Abbildung 1: Die drei Delegierungs-Arten im Vergleich – von hochriskant bis modern und flexibel.

Die uneingeschränkte Variante geben Sie bitte gleich wieder ab – sie legt das komplette TGT des Benutzers auf dem Zielserver ab, und wer den Server knackt, hat damit die Identität aller Nutzer, die sich je angemeldet haben. Constrained Delegation begrenzt das sauber auf eine Liste erlaubter Zieldienste. Resource-Based Constrained Delegation (RBCD) dreht die Konfiguration um und wird am Ziel statt an der Quelle gepflegt – modern, aber per PowerShell statt GUI. Dieser Artikel konzentriert sich auf die klassische constrained Variante, die Sie in den allermeisten Fällen brauchen.

Das Double-Hop-Problem – warum es das überhaupt braucht

Stellen Sie sich eine ganz normale Web-Anwendung vor. Der Benutzer meldet sich am IIS an – erster Hop, läuft per Kerberos einwandfrei. Jetzt will der Webserver im Namen genau dieses Benutzers Daten aus dem SQL Server holen – zweiter Hop. Und hier ist Schluss: Kerberos gibt das Benutzer-Ticket standardmäßig nicht über zwei Sprünge weiter. Der Webserver kann die Identität nicht weiterreichen, der SQL Server sieht nur einen anonymen Zugriff und winkt ab.

Abbildung 2: Ohne Delegation endet die Benutzer-Identität am ersten Server – mit S4U2Proxy reicht der Webserver sie kontrolliert weiter.

Constrained Delegation löst das über den Mechanismus S4U2Proxy: Der Webserver darf sich beim KDC im Namen des Benutzers ein Ticket holen – aber ausschließlich für die Dienste, die Sie ihm vorher explizit erlaubt haben. Kein Freibrief, sondern eine eng geführte Erlaubnis.

Die Einrichtung in fünf Schritten

Reihenfolge ist hier kein Schönheitsthema, sondern entscheidend. Wenn die SPNs nicht stehen, taucht die Delegierungs-Option in der GUI gar nicht erst auf – und Sie suchen sich dumm und dämlich.

Abbildung 3: Die Einrichtungsreihenfolge – ohne korrekte SPNs (Schritt 1 und 2) fehlt in Schritt 3 schlicht die Auswahl.

Schritt 1 – SPN am Ziel-Dienst setzen

Der Zieldienst (hier SQL Server) braucht einen korrekten SPN auf dem Konto, unter dem er läuft. Ohne ihn gibt es für das Ziel gar keinen Kerberos-Namen, den man delegieren könnte.

Schritt 2 – SPN am Web-Dienst setzen

Damit schon der erste Hop sauber per Kerberos läuft (und nicht heimlich auf NTLM zurückfällt, was Delegierung komplett verhindern würde), braucht auch der Webdienst seinen SPN.

Schritt 3 – Delegierung am Web-Konto erlauben

Jetzt öffnen Sie das Web-Dienstkonto in „Active Directory-Benutzer und -Computer“ (Reiter Delegierung), wählen „Nur zu angegebenen Diensten“ und tragen den SQL-SPN aus Schritt 1 ein. Wer es lieber per PowerShell mag:

Schritt 4 – Protocol Transition bewusst entscheiden

Hier gibt es zwei Optionen, und der Unterschied ist sicherheitsrelevant. „Nur Kerberos verwenden“ ist die strengere Variante – der erste Hop muss zwingend Kerberos sein. „Beliebiges Authentifizierungsprotokoll verwenden“ aktiviert S4U2Self (Protocol Transition) und erlaubt dem Webserver, auch dann ein Ticket zu erzeugen, wenn der Benutzer sich vorne per NTLM oder Formular angemeldet hat – flexibler, aber mächtiger. Nehmen Sie im Zweifel die strengere Kerberos-only-Variante.

Schritt 5 – Testen

Erst den Ticket-Cache leeren, dann die Anwendung durchklicken, dann nachsehen, ob das delegierte Ticket gezogen wurde:

In der klist-Ausgabe muss jetzt ein Ticket für MSSQLSvc/sql01.contoso.de auftauchen. Ist es da, läuft die Delegierung. Bleibt sie aus, gehen Sie die SPNs durch – in neun von zehn Fällen liegt es daran.

Schnelle Fehlersuche, wenn es nicht läuft

Häufige Fragen

Was ist der Unterschied zwischen constrained und resource-based constrained delegation?

Bei der klassischen constrained Delegation pflegen Sie die Erlaubnis an der Quelle – das delegierende Konto bekommt eine Liste erlaubter Zieldienste (msDS-AllowedToDelegateTo). Bei RBCD pflegen Sie sie am Ziel: Das Ressourcen-Konto legt fest, wer sich ihm gegenüber ausgeben darf. RBCD funktioniert auch domänenübergreifend und braucht keine Domänen-Admin-Rechte am Quell-Server, läuft dafür aber nur per PowerShell. Für klassische Single-Domain-Szenarien ist die constrained Variante oft der kürzere Weg.

Brauche ich Protocol Transition zwingend?

Nein. Wenn sich der Benutzer am ersten Hop sauber per Kerberos anmeldet – was bei integrierter Windows-Authentifizierung im Intranet der Normalfall ist – reicht die strengere „Nur Kerberos“-Variante völlig. Protocol Transition (S4U2Self) brauchen Sie nur, wenn die Anmeldung vorne eben nicht per Kerberos läuft, etwa bei Formular- oder Zertifikats-Login, der hinten trotzdem in eine Windows-Identität übersetzt werden soll.

Funktioniert das auch mit Gruppen-verwalteten Dienstkonten (gMSA)?

Ja, und das ist sogar die empfohlene Kombination. gMSAs können ebenso Delegierungsziele tragen wie normale Dienstkonten, ersparen Ihnen aber die Passwortpflege. Die Einrichtung läuft analog – SPN setzen, msDS-AllowedToDelegateTo befüllen, fertig. Achten Sie nur darauf, dass die Server, die das gMSA nutzen dürfen, korrekt in der PrincipalsAllowedToRetrieveManagedPassword stehen.

Warum sehe ich den Delegierungs-Reiter nicht im AD-Konto?

Der Reiter „Delegierung“ erscheint erst, wenn dem Konto mindestens ein SPN zugewiesen ist. Solange das Konto keinen SPN trägt, blendet die Konsole den Reiter komplett aus – ein häufiger Stolperstein. Setzen Sie zuerst den SPN (Schritt 1 bzw. 2), schließen Sie das Eigenschaftenfenster und öffnen es neu. Dann ist der Reiter da.

Kann eine falsch konfigurierte Delegation ein Sicherheitsrisiko sein?

Durchaus – deshalb die Sorgfalt. Uneingeschränkte Delegierung ist das größte Risiko und sollte vermieden werden. Aber auch bei constrained Delegation gilt: Tragen Sie nur die Zieldienste ein, die wirklich gebraucht werden, und halten Sie die Liste sauber. Je weniger ein delegierendes Konto darf, desto kleiner der Schaden, falls es kompromittiert wird. Prüfen Sie bestehende Delegierungen regelmäßig – Altlasten sammeln sich hier gerne an.