Delegierung in Active Directory: riskante Vertrauen finden

Kerberos-Delegierung erlaubt einem Front-End-Dienst, gegenüber einem Back-End-Dienst im Namen eines Benutzers zu handeln – der klassische Fall ist eine Webanwendung, die einen SQL Server als angemeldeter Benutzer abfragt statt unter eigener Identität. Das ist eine legitime und manchmal notwendige Funktion, aber jede ihrer drei Implementierungen schafft eine Vertrauensbeziehung. Liegt diese auf dem falschen Server oder Konto, erhält ein Angreifer, der diesen einen Rechner kompromittiert, einen Weg, sich als andere Benutzer auszugeben – häufig auch als Administratoren.

Dieser Leitfaden erklärt, wie sich die drei Delegierungstypen unterscheiden, wie Sie jede Delegierungsbeziehung in Ihrer Domäne inventarisieren und wie Sie die Konten absichern, die niemals delegierbar sein sollten.

Die drei Delegierungstypen

Uneingeschränkte Delegierung

Authentifiziert sich ein Benutzer per Kerberos bei einem Server, dem für uneingeschränkte Delegierung vertraut wird, sendet der Client zusammen mit dem Dienstticket eine weitergeleitete Kopie des TGT des Benutzers, und der Server speichert sie im Arbeitsspeicher. Dieser Server kann das TGT nun wiederverwenden, um als dieser Benutzer Tickets für jeden beliebigen Dienst anzufordern – unbegrenzt (bis das TGT abläuft). Authentifiziert sich jemals ein Domain Admin an dieser Maschine – und sei es nur, um eine Dateifreigabe zu durchsuchen –, liegt sein TGT abholbereit im Speicher.

Standardmäßig wird allen Domänencontrollern für uneingeschränkte Delegierung vertraut (für ihre normale Funktion erforderlich). Die entscheidende Regel: Kein Server außer einem Domänencontroller sollte dieses Flag gesetzt haben. Früher war es ein verbreiteter Standard auf Druckservern, älteren IIS-Servern und fehlkonfigurierten Anwendungsservern, und es bleibt einer der wertvollsten Brückenköpfe, die ein Angreifer finden kann.

Eingeschränkte Delegierung

Die mit Windows Server 2003 eingeführte eingeschränkte Delegierung beschränkt das Front-End darauf, Benutzer nur gegenüber einer expliziten Liste von Back-End-SPNs zu imitieren, festgelegt über msDS-AllowedToDelegateTo auf dem Front-End-Konto. Sie unterstützt außerdem den „Protokollübergang“ (TRUSTED_TO_AUTH_FOR_DELEGATION), mit dem das Front-End ein Ticket im Namen eines Benutzers auch ohne vorherigen Kerberos-Hop erhalten kann – nützlich für Webanwendungen, die Benutzer per Formular oder auf anderem Weg authentifizieren, aber dennoch an ein Back-End delegieren müssen. Das ist sicherer als uneingeschränkte Delegierung, aber weiterhin riskant: Wer das Front-End-Konto kontrolliert, kann jeden Benutzer (einschließlich Admins) gegenüber jedem Dienst in dieser Liste imitieren.

Ressourcenbasierte eingeschränkte Delegierung (RBCD)

Die mit Windows Server 2012 eingeführte RBCD dreht den Ort der Vertrauenskonfiguration um: Statt dass das Front-End erklärt, wohin es delegieren darf, erklärt die Back-End-Ressource über msDS-AllowedToActOnBehalfOfOtherIdentity, welche Front-End-Konten in ihrem Namen handeln dürfen. Das ist flexibler (funktioniert über Domänen-/Gesamtstrukturgrenzen hinweg und erfordert zur Konfiguration keine Domain-Admin-Rechte, sondern nur Schreibzugriff auf das Zielcomputerobjekt), doch genau diese Flexibilität ist das Risiko: Jeder mit GenericWrite/WriteProperty auf einem Computerobjekt kann sich selbst RBCD-Rechte gewähren, um Benutzer ihm gegenüber zu imitieren – auch über das Recht zum Erstellen von Computerkonten, das viele Benutzer standardmäßig besitzen (ms-DS-MachineAccountQuota).

Delegierung in Ihrer Domäne finden

Führen Sie eine vollständige Inventur durch, bevor Sie entscheiden, was zu beheben ist. Das sollte eine wiederkehrende Prüfung sein, keine einmalige Übung.

# Uneingeschränkte Delegierung – Computer und Benutzer (sollte außer DCs leer sein)
Get-ADComputer -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation, servicePrincipalName |
    Select-Object Name, DistinguishedName

Get-ADUser -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation |
    Select-Object Name, DistinguishedName

# Eingeschränkte Delegierung – Konten mit befülltem msDS-AllowedToDelegateTo
Get-ADComputer -Filter * -Properties msDS-AllowedToDelegateTo, TrustedToAuthForDelegation |
    Where-Object { $_."msDS-AllowedToDelegateTo" } |
    Select-Object Name, msDS-AllowedToDelegateTo, TrustedToAuthForDelegation

Get-ADUser -Filter * -Properties msDS-AllowedToDelegateTo, TrustedToAuthForDelegation |
    Where-Object { $_."msDS-AllowedToDelegateTo" } |
    Select-Object Name, msDS-AllowedToDelegateTo, TrustedToAuthForDelegation

# Ressourcenbasierte eingeschränkte Delegierung – PrincipalsAllowedToDelegateToAccount ist die
# vom ActiveDirectory-Modul decodierte Ansicht des Deskriptors msDS-AllowedToActOnBehalfOfOtherIdentity
Get-ADComputer -LDAPFilter '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)' `
    -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object @{n='Computer';e={$_.Name}},
        @{n='DelegatedFrom';e={$_.PrincipalsAllowedToDelegateToAccount -join '; '}}

Behandeln Sie jeden Treffer mit uneingeschränkter Delegierung außerhalb der OU Domain Controllers als kritischen Befund, der sofort zu beheben ist. Gleichen Sie jeden Treffer mit eingeschränkter Delegierung und RBCD mit einem Change-Eintrag ab – Delegierung sollte dokumentiert, gewollt und geprüft sein, nicht das Überbleibsel eines vergessenen Proof of Concept.

Unerwünschte Delegierung entfernen

# Uneingeschränkte Delegierung von einem Nicht-DC-Computerkonto entfernen
Set-ADComputer -Identity "APP01" -TrustedForDelegation $false

# Einträge der eingeschränkten Delegierung entfernen
Set-ADComputer -Identity "APP02" -Clear msDS-AllowedToDelegateTo

# RBCD auf einer Ressource leeren
Set-ADComputer -Identity "SQL01" -Clear msDS-AllowedToActOnBehalfOfOtherIdentity

Privilegierte Konten schützen: „vertraulich und kann nicht delegiert werden“

Unabhängig davon, welche Delegierung sonst in der Domäne existiert, sollten privilegierte Konten ausdrücklich von jeder Delegierung ausgeschlossen werden – mit dem Flag NOT_DELEGATED (ein userAccountControl-Bit, in ADUC als „Account is sensitive and cannot be delegated“ angezeigt). Das verhindert, dass irgendein Dienst – selbst eine legitim konfigurierte eingeschränkte Delegierung – ein Ticket erhält, um dieses Konto zu imitieren.

# Auf ein einzelnes privilegiertes Konto anwenden
Set-ADAccountControl -Identity "adm-t0-famette" -AccountNotDelegated $true

# Auf jedes Mitglied von Domain Admins und Enterprise Admins anwenden
"Domain Admins", "Enterprise Admins" | ForEach-Object {
    Get-ADGroupMember -Identity $_ -Recursive |
        Where-Object { $_.objectClass -eq 'user' } |
        ForEach-Object { Set-ADAccountControl -Identity $_.SamAccountName -AccountNotDelegated $true }
}

Überprüfen

Get-ADUser -Identity "adm-t0-famette" -Properties userAccountControl |
    Select-Object Name, @{n='NotDelegated';e={
        [bool]($_.userAccountControl -band 0x100000)
    }}

Die Mitgliedschaft in Protected Users (behandelt in Tier 0 & privilegierter Zugriff) bietet einen noch stärkeren, überlappenden Schutz: Sie blockiert NTLM sowie uneingeschränkte und eingeschränkte Delegierung für das Konto vollständig, ohne dass das Flag NOT_DELEGATED separat gesetzt werden muss, und härtet zusätzlich die Lebensdauer und die Verschlüsselungsanforderungen der Kerberos-Tickets.

Warum uneingeschränkte Delegierung auf einem Nicht-DC kritisch ist

Es verdient eine eigene Wiederholung, weil es die mit Abstand folgenreichste Fehlkonfiguration der Delegierung ist: Ein kompromittierter Server mit uneingeschränkter Delegierung wird zur Anmeldeinformationsfalle, die das TGT jedes Administrators in dem Moment einsammelt, in dem dieser den Server berührt – ohne dass der eigene Rechner des Admins angegriffen werden muss. Zusammen mit Schulungen zur uneingeschränkten Delegierung für Infrastrukturteams sollte dies ein fester Punkt jeder AD-Sicherheitsprüfung sein – geprüft bei jeder Bereitstellung eines neuen Servers, nicht nur bei periodischen Audits.

Was dabei bricht

• Webanwendungen, die per Kerberos-Delegierung Back-End-Datenbanken als angemeldeter Benutzer abfragen (verbreitet bei SharePoint, SSRS und eigenen Intranet-Anwendungen), sind auf eingeschränkte Delegierung angewiesen. Wird ein Eintrag aus msDS-AllowedToDelegateTo entfernt, ohne ihn durch den korrekt eingegrenzten Eintrag zu ersetzen, bricht die Funktion „als Benutzer ausführen“, und die Anwendung fällt auf einen Dienstkontokontext zurück oder scheitert ganz.
• SQL-Server-Verbindungsserver, die für delegierte Authentifizierung (statt gespeicherter Anmeldeinformationen) konfiguriert sind, funktionieren nicht mehr, wenn die Delegierungseinträge des SQL-Dienstkontos geleert werden. Prüfen Sie sie und grenzen Sie sie auf eingeschränkte Delegierung mit expliziten SPNs ein, statt sie ganz zu entfernen.
• Druckserver und ältere Anwendungsproxys, denen früher pauschal uneingeschränkte Delegierung gewährt wurde, waren oft stillschweigend darauf angewiesen. Das Entfernen des Flags kann sich als sporadische „Zugriff verweigert“-Fehler in Double-Hop-Szenarien äußern (z. B. ein Benutzer, der über einen Druckserver auf eine Freigabe zugreift, der sich dann weiter authentifizieren muss) – testen Sie in einem Wartungsfenster und seien Sie bereit, auf korrekt eingegrenzte eingeschränkte Delegierung umzukonfigurieren.
• RBCD für legitimen domänenübergreifenden Ressourcenzugriff (z. B. in einem Migrationsszenario oder bei einer Anwendung über mehrere Gesamtstrukturen) bricht, wenn sie geleert wird, ohne die Beziehung zuvor über eine dokumentierte Änderungssteuerung neu bereitzustellen.

Weiterführende Lektüre: Kerberos-Härtung zu den Ticketfälschungstechniken, mit denen Delegierungsmissbrauch häufig verkettet wird, und Tier 0 & privilegierter Zugriff zum Konto-Tiering, das delegierbare Dienstkonten von Tier-0-Anmeldeinformationen fernhält. Siehe auch DCSync dazu, was ein Angreifer tut, nachdem er per Delegierungsmissbrauch ein Domain-Admin-TGT erlangt hat.