Ausgangslage: ein alter Komfortschalter mit zu viel Vertrauen

Kerberos-Delegation ist in AD-Umgebungen nicht automatisch schlecht. Viele legitime Anwendungen brauchen einen kontrollierten Double-Hop: ein Webserver nimmt die Benutzeranmeldung entgegen und greift danach im Namen des Benutzers auf ein Backend zu, zum Beispiel SQL, Fileservices oder eine interne API.

Problematisch wird es, wenn für diesen Zweck Unconstrained Delegation genutzt wird. Dann ist das Objekt nicht auf konkrete Zielservices begrenzt. Historisch war das bequem, weil alte Anwendungen damit "einfach funktionierten". Aus Sicht eines heutigen AD-Hardening-Programms ist es aber eine zu breite Vertrauensentscheidung.

In Projekten sieht man typische Muster:

  • alte IIS-, SharePoint-, SQL- oder Middleware-Server mit Delegation "to any service",
  • Service-Accounts mit SPNs und ungeprüften Delegationseinstellungen,
  • fehlende Owner für Legacy-Applikationen,
  • privilegierte Admin-Logons auf Servern, die nie als Tier-0-relevant behandelt wurden,
  • Ausnahmen, die niemand mehr fachlich begründen kann.

Domain Controller sind ein Sonderfall und müssen getrennt betrachtet werden. Der Hardening-Fokus liegt auf Member Servern und Service-Accounts, die ohne klare Notwendigkeit breit delegieren dürfen.

Zielbild: keine breite Delegation außerhalb klarer Ausnahmefälle

Ein belastbares Zielbild ist konkret:

  1. Keine Unconstrained Delegation auf Member Servern und Service-Accounts, außer es gibt eine dokumentierte, zeitlich begrenzte Ausnahme.
  2. Anwendungsflüsse sind verstanden: welcher Frontend-Service muss zu welchem Backend-Service delegieren?
  3. Delegation ist eingeschränkt: Kerberos Constrained Delegation oder Resource-based Constrained Delegation nur für definierte Zielservices.
  4. Sensitive Accounts sind nicht delegierbar: privilegierte Benutzer, Admin-Konten und Break-Glass-Konten sind mit "Account is sensitive and cannot be delegated" geschützt; Protected Users wird dort eingesetzt, wo die Abhängigkeiten getestet sind.
  5. Änderungen sind messbar: Inventar, Owner, Change-Fenster, Monitoring und Rollback sind Teil des Projekts.

Das Ziel ist nicht, Delegation pauschal zu verbieten. Das Ziel ist, Delegation wieder auf einen bewusst entschiedenen Vertrauenspfad zu begrenzen.

Praktische Umsetzung: erst Inventar, dann gezielte Änderung

1) Bestand read-only erfassen

Starte mit einer reinen Bestandsaufnahme. Keine Bulk-Änderung, keine automatische Bereinigung.

Import-Module ActiveDirectory

Get-ADComputer -LDAPFilter '(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))' `
  -Properties DNSHostName,OperatingSystem,ServicePrincipalName,DistinguishedName |
  Select-Object Name,DNSHostName,OperatingSystem,DistinguishedName

Get-ADUser -LDAPFilter '(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=524288))' `
  -Properties ServicePrincipalName,Enabled,DistinguishedName |
  Select-Object SamAccountName,Enabled,DistinguishedName

Diese Abfragen zeigen Objekte mit dem Delegation-Flag. Domain Controller sollten im Report separat markiert werden, nicht als normale Findings. Für Member Server und Service-Accounts brauchst du danach Owner, Anwendung, SPNs und echten Authentifizierungsfluss.

2) Treffer klassifizieren

Jeder Treffer bekommt eine einfache Entscheidung:

  • entfernen: keine fachliche Notwendigkeit oder System ist außer Betrieb,
  • ersetzen: Double-Hop wird gebraucht, aber nur zu definierten Services,
  • befristet akzeptieren: Legacy-Abhängigkeit mit Owner, Ablaufdatum und Migrationspfad,
  • Sonderfall: Domain Controller oder Plattformkomponente, die nicht wie ein Member Server behandelt wird.

Die häufigste saubere Zielkonfiguration ist nicht "keine Delegation", sondern eingeschränkte Delegation zu konkreten Zielservices. Wo möglich, sollten Service-Accounts zudem in Richtung gMSA, klare SPN-Ownership und getrennte Betriebsrollen gebracht werden.

3) Privilegierte Konten vor Delegation schützen

Parallel zur Serverbereinigung müssen privilegierte Konten sauber stehen. Für Admin-Konten ist "Account is sensitive and cannot be delegated" ein wichtiger Mindestschutz.

Set-ADAccountControl -Identity "adm.example" -AccountNotDelegated $true

Das ersetzt kein Tiering und keine Admin-Workstation-Hygiene. Es verhindert aber, dass ein sensitives Konto delegiert werden kann, selbst wenn es versehentlich an einem delegationsfähigen Dienst auftaucht. Vor breitem Rollout muss getestet werden, ob Admin-Workflows, Services oder geplante Aufgaben dadurch brechen. Konten, die als Service laufen, gehören nicht nebenbei in diese Kategorie, sondern brauchen eine eigene Migrationsentscheidung.

4) Service-Flows auf eingeschränkte Delegation umstellen

Bei Anwendungen mit echtem Double-Hop brauchst du den fachlichen Pfad:

  • Frontend-Servicekonto oder Computerobjekt,
  • Zielservice und SPN,
  • beteiligte Domains,
  • Authentifizierungstyp,
  • Owner und Testfall.

Danach wird die Delegation auf die konkreten Zielservices begrenzt. In modernen Umgebungen ist Resource-based Constrained Delegation oft betriebsfreundlicher, weil der Ressourceneigentümer steuern kann, wem er Delegation erlaubt. Klassische Constrained Delegation bleibt in vielen Bestandsumgebungen trotzdem relevant. Beide Varianten sind besser als "any service", wenn sie sauber berechtigt und dokumentiert sind.

5) Unconstrained Delegation gezielt entfernen

Erst wenn Owner, Testfall und Zielzustand klar sind, wird die breite Delegation entfernt.

Set-ADAccountControl -Identity "APP01$" -TrustedForDelegation $false

Das sollte pro Anwendung oder pro kleiner Welle passieren, nicht domainweit in einem Skriptlauf. Danach gehören Anmeldepfade, Applikationsfunktionen und Kerberos-Fehlerbilder für ein definiertes Beobachtungsfenster ins Monitoring.

Vorteile

  • Reduziert den Blast Radius kompromittierter Member Server und Service-Accounts.
  • Schützt Tier 0 indirekt, weil privilegierte Logons nicht mehr auf breit delegierbare Systeme treffen sollten.
  • Erzwingt Ownership für alte Applikationsflüsse, SPNs und Service-Accounts.
  • Verbessert Kerberos-Hygiene als Grundlage für weitere Maßnahmen wie AES-Only, Protected Users und saubere Admin-Tiers.
  • Ist gut messbar: Anzahl Treffer, Anzahl entfernter Flags, Anzahl befristeter Ausnahmen.

Nachteile und Grenzen

  • Legacy-Anwendungen können brechen, wenn der echte Double-Hop nicht verstanden wurde.
  • Constrained Delegation ist kein Selbstläufer: falsche SPNs, falsche Zielobjekte oder zu breite RBCD-ACLs schaffen neue Risiken.
  • Domain Controller bleiben Sonderfälle und dürfen nicht blind mit Member Servern verglichen werden.
  • Der sichtbare Nutzen ist für Fachbereiche gering, weil erfolgreiche Härtung meist "nichts ist ausgefallen" bedeutet.
  • Es ersetzt keine Logon-Hygiene: Admins dürfen trotzdem nicht auf beliebigen Applikationsservern arbeiten.

Typische Stolperfallen

  • Alle Treffer gleich behandeln: DCs, Member Server und Service-Accounts brauchen getrennte Bewertung.
  • Bulk-Disable ohne Owner: das wirkt effizient, endet aber schnell in Produktionsstörungen.
  • SPNs nicht prüfen: Delegation hängt praktisch an Service-Identitäten und SPNs.
  • RBCD zu breit setzen: Resource-based heisst nicht automatisch sicher; die ACL entscheidet.
  • Admin-Konten vergessen: wenn sensitive Konten delegierbar bleiben, ist der Sicherheitsgewinn unvollständig.
  • Ausnahmen ohne Ablaufdatum: "temporär" wird sonst zur neuen Baseline.

Projekt-Checkliste

  • [ ] Computer und User mit Unconstrained Delegation read-only inventarisieren.
  • [ ] Domain Controller separat markieren und aus der Member-Server-Bereinigung herausnehmen.
  • [ ] Für jeden Treffer Owner, Anwendung, SPNs und echten Authentifizierungsfluss dokumentieren.
  • [ ] Privilegierte Benutzer und Break-Glass-Konten auf AccountNotDelegated prüfen.
  • [ ] Double-Hop-Anwendungen auf Constrained Delegation oder Resource-based Constrained Delegation migrieren.
  • [ ] Service-Accounts auf gMSA-Eignung, SPN-Ownership und minimale Rechte prüfen.
  • [ ] Unconstrained Delegation nur in kleinen Wellen entfernen.
  • [ ] Kerberos-Fehler, Login-Pfade und Applikationsfunktionen nach jeder Welle überwachen.
  • [ ] Befristete Ausnahmen mit Owner, Risiko, Zieltermin und nächstem Review erfassen.