Eingeschränkte Delegierung und RBCD sicher in AD einsetzen

Sobald die uneingeschränkte Delegierung verschwunden ist, bleibt die eingegrenzte Art übrig: Kerberos-eingeschränkte Delegierung (KCD) und ressourcenbasierte eingeschränkte Delegierung (RBCD). Beide sind legitim und oft notwendig. Beide werden aber auch zu Werkzeugen für Identitätswechsel, wenn sie zu locker konfiguriert sind oder die falschen Personen sie ändern können. Angreifer nutzen Werkzeuge wie Rubeus und Impacket, um S4U-Tickets anzufordern; dieser Leitfaden konzentriert sich auf die Verteidigerseite, also auf die Konfigurationsentscheidungen und Prüfungen, die bestimmen, ob diese Anfragen etwas Brauchbares liefern.

Er setzt voraus, dass Sie die drei Modelle aus dem Grundlagenleitfaden zur Delegierung kennen. Hier geht es um die zugrunde liegenden Kerberos-Erweiterungen, die Einstellungen, die jedes Modell riskant machen, und eine wiederholbare Prüfung, wer RBCD auf Ihren Computerobjekten schreiben kann.

Wie S4U Delegierung ermöglicht

Beide eingegrenzten Modelle beruhen auf zwei Kerberos-Erweiterungen, zusammen Service for User (S4U) genannt:

• S4U2Self erlaubt einem Dienst, im Namen eines beliebigen Benutzers ein Ticket für sich selbst anzufordern, ohne dessen Anmeldeinformationen. Es existiert, damit ein Dienst die Gruppenmitgliedschaften eines Benutzers erfahren kann.
• S4U2Proxy erlaubt einem Dienst, ein Ticket, das er für einen Benutzer hält (das „Evidence“-Ticket), gegen ein Ticket für einen anderen Dienst einzutauschen, weiterhin als dieser Benutzer.

Der KDC prüft S4U2Proxy gegen die Delegierungskonfiguration: msDS-AllowedToDelegateTo auf dem Front-End bei KCD oder msDS-AllowedToActOnBehalfOfOtherIdentity auf dem Back-End bei RBCD. Zwei Details bestimmen, wie gefährlich eine bestimmte Konfiguration ist.

Protokollübergang

Bei KCD mit „Kerberos only“ gelingt S4U2Proxy nur, wenn das Evidence-Ticket weiterleitbar ist – in der Praxis heißt das, dass sich der Benutzer wirklich per Kerberos beim Front-End authentifiziert hat. Mit „Use any authentication protocol“ (dem Flag TRUSTED_TO_AUTH_FOR_DELEGATION, 0x1000000) kann das Front-End allein über S4U2Self ein weiterleitbares Ticket für jeden Benutzer erhalten. Der Benutzer muss nie in Erscheinung treten.

Das bedeutet: Wer ein Front-End-Konto mit Protokollübergang kontrolliert, kann jederzeit jeden nicht geschützten Benutzer, einschließlich Domain Admins, gegenüber jedem SPN seiner Liste imitieren. Protokollübergang wird für Formularauthentifizierung, von der Anwendung verarbeitete Zertifikat- oder Smartcard-Anmeldung und manche SSO-Gateways benötigt. Für eine Intranetseite mit integrierter Windows-Authentifizierung wird er nicht benötigt.

RBCD und weiterleitbare Tickets

Bei RBCD akzeptiert der KDC ein nicht weiterleitbares Evidence-Ticket, solange das Back-End dem Front-End vertraut. Ein Angreifer, der irgendein Konto mit SPN kontrolliert (ein selbst erstelltes Computerkonto genügt) und RBCD auf einem Zielcomputer schreiben kann, kann also Benutzer gegenüber diesem Ziel imitieren. Deshalb dreht sich RBCD-Hygiene vor allem um Schreibberechtigungen, und deshalb ist ms-DS-MachineAccountQuota hier so wichtig.

Ersetzung des Dienstnamens

Der SPN in einem Dienstticket ist nicht durch die Ticketverschlüsselung geschützt. Ein für cifs/fs01 ausgestelltes Ticket ist ebenso gültig für host/fs01, http/fs01 oder ldap/fs01, wenn diese Dienste unter demselben Konto laufen – und auf einem Computerkonto tun das alle. Grenzen Sie entsprechend ein: Ein Eintrag, der auf irgendeinen Dienst eines Domänencontrollers zeigt, ist faktisch eine Delegierung an den gesamten DC.

Messen: die eingegrenzte Delegierung inventarisieren

Erfassen Sie beide Modelle in jeder Domäne, einschließlich des Flags für den Protokollübergang.

Import-Module ActiveDirectory

# KCD: Front-End-Konten mit msDS-AllowedToDelegateTo
Get-ADObject -LDAPFilter '(msDS-AllowedToDelegateTo=*)' `
    -Properties samAccountName, objectClass, msDS-AllowedToDelegateTo, userAccountControl |
    Select-Object samAccountName, objectClass,
        @{n='ProtocolTransition';e={[bool]($_.userAccountControl -band 0x1000000)}},
        @{n='Targets';e={$_.'msDS-AllowedToDelegateTo' -join '; '}}

# RBCD: Back-End-Ressourcen und wer an sie delegieren darf
Get-ADComputer -LDAPFilter '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)' `
    -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object Name,
        @{n='AllowedFrom';e={$_.PrincipalsAllowedToDelegateToAccount -join '; '}}

PrincipalsAllowedToDelegateToAccount ist die lesbare Ansicht des ActiveDirectory-Moduls auf den Sicherheitsdeskriptor msDS-AllowedToActOnBehalfOfOtherIdentity, sodass Sie ihn nicht von Hand parsen müssen. RBCD kann auch auf Benutzer- und Dienstkonten gesetzt werden; für eine vollständige Abdeckung führen Sie denselben Filter mit Get-ADObject aus.

Kennzeichnen Sie Folgendes als kritisch:

• Jedes KCD-Ziel oder jede RBCD-Ressource, die ein Domänencontroller, AD-CS-Server oder ein anderes Tier-0-Asset ist.
• Jedes Front-End mit Protokollübergang, dessen Bedarf nicht dokumentiert ist.
• Jeden RBCD-Eintrag, der auf ein von einem normalen Benutzer erstelltes Computerkonto zeigt (prüfen Sie mS-DS-CreatorSID auf dem Front-End).
• Jede Delegierung, die auf einem Benutzerkonto mit statischem Kennwort konfiguriert ist.

Prüfen: wer RBCD schreiben kann

Ein RBCD-Eintrag, den Sie kennen, ist nur die halbe Wahrheit. Die andere Hälfte ist, wer morgen einen hinzufügen könnte. Suchen Sie nach diesen Rechten auf Computerobjekten, insbesondere auf Servern und Tier-0-Rechnern:

• GenericAll, GenericWrite, WriteDacl oder WriteOwner auf dem Objekt oder Besitz daran.
• WriteProperty für alle Eigenschaften oder für das Attribut msDS-AllowedToActOnBehalfOfOtherIdentity (schemaIDGUID 3f78c3e5-f79a-46bd-a0b8-9d18116ddc79).
• WriteProperty auf dem Eigenschaftssatz Account Restrictions (4c164200-20c0-11d0-a768-00aa006e0529), der häufig dem Konto gewährt wird, das einen Rechner in die Domäne aufgenommen hat, und dieses Attribut enthält.

$rbcdAttr   = [guid]'3f78c3e5-f79a-46bd-a0b8-9d18116ddc79'
$acctRestr  = [guid]'4c164200-20c0-11d0-a768-00aa006e0529'
$expected   = 'NT AUTHORITY\\SYSTEM|\\Domain Admins$|\\Enterprise Admins$|BUILTIN\\Administrators|\\Key Admins$|\\Enterprise Key Admins$|NT AUTHORITY\\SELF'

Get-ADComputer -Filter * -SearchBase 'OU=Servers,DC=corp,DC=example,DC=com' |
    ForEach-Object {
        $dn  = $_.DistinguishedName
        $acl = Get-Acl -Path "AD:\$dn"
        $acl.Access | Where-Object {
            $_.AccessControlType -eq 'Allow' -and
            $_.IdentityReference -notmatch $expected -and (
                $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner' -or
                ($_.ActiveDirectoryRights -match 'WriteProperty' -and
                 $_.ObjectType -in @([guid]::Empty, $rbcdAttr, $acctRestr))
            )
        } | Select-Object @{n='Computer';e={$dn}}, IdentityReference, ActiveDirectoryRights, ObjectType, IsInherited
    } | Export-Csv .\rbcd-writers.csv -NoTypeInformation

Prüfen Sie auch $acl.Owner für jedes Objekt: Ein Besitzer kann die DACL jederzeit neu schreiben. Geerbte ACEs weisen auf zu weit gefasste Delegierung auf OU-Ebene hin; beheben Sie diese an der OU statt Objekt für Objekt. Für eine Graphansicht über die gesamte Domäne zeigt der Leitfaden zu Attack Path Management, wie Sie dieselben Beziehungen in BloodHound abfragen.

Beachten Sie den obigen Ausschluss von SELF. Ein Computerkonto kann in Standardkonfigurationen RBCD auf seinem eigenen Objekt schreiben. Das ist für sich genommen harmlos, aber genau das nutzen Relay-Ketten wie KrbRelayUp aus: Sie leiten die Authentifizierung des Rechners an LDAP weiter und schreiben RBCD als der Rechner. Die Lösung ist keine ACL-Änderung, sondern LDAP-Signierung und Channel Binding auf jedem DC.

Durchsetzen: eingegrenzte Delegierung sicher konfigurieren

KCD mit „Kerberos only“

Wenn Benutzer das Front-End per Kerberos erreichen, verwenden Sie KCD ohne Protokollübergang, mit der kleinsten funktionierenden SPN-Liste.

Set-ADComputer -Identity WEB01 -Replace @{
    'msDS-AllowedToDelegateTo' = @('MSSQLSvc/sql01.corp.example.com:1433','MSSQLSvc/sql01.corp.example.com')
}
Set-ADAccountControl -Identity (Get-ADComputer WEB01) -TrustedToAuthForDelegation $false

Ist der Protokollübergang wirklich erforderlich, betreiben Sie das Front-End unter einem gMSA, halten Sie es in einem dedizierten Tier, beschränken Sie lokale Administratorrechte auf seinen Hosts und stellen Sie sicher, dass die SPN-Liste keinen DC, AD-CS- oder Managementserver enthält.

RBCD

Setzen Sie RBCD mit dem dafür vorgesehenen Parameter, damit der Sicherheitsdeskriptor korrekt aufgebaut ist, und bevorzugen Sie eine Gruppe, wenn mehrere Front-Ends Zugriff benötigen – so erfolgen Änderungen über die Mitgliedschaft statt im Deskriptor.

$front = Get-ADGroup 'GG-SQL01-Delegation-Frontends'
Set-ADComputer -Identity SQL01 -PrincipalsAllowedToDelegateToAccount $front

Entfernen Sie veraltete Einträge mit Set-ADComputer -Identity <name> -PrincipalsAllowedToDelegateToAccount $null.

Identitäten schützen, die nie imitiert werden dürfen

Jedes Tier-0-Konto sollte Mitglied von Protected Users sein oder als „Account is sensitive and cannot be delegated“ gekennzeichnet werden. Beides veranlasst den KDC, S4U-Tickets für diese Benutzer zu verweigern, was den meisten Delegierungsmissbrauch neutralisiert, selbst wenn ein Front-End kompromittiert ist. Setzen Sie zusätzlich das Flag NOT_DELEGATED, auch auf dem integrierten Administrator und auf Break-Glass-Konten, die möglicherweise nicht in Protected Users sind: Es wird vom KDC unabhängig von der Gruppenmitgliedschaft durchgesetzt und übersteht eine versehentliche Bereinigung der Gruppe. Halten Sie DCs für CVE-2020-17049 (das Bronze-Bit-Problem) gepatcht, das einem kompromittierten Front-End erlaubte, beide Schutzmaßnahmen durch Manipulation des Forwardable-Flags zu umgehen.

Überprüfen

• Führen Sie die Inventur erneut aus. Jeder KCD- und RBCD-Eintrag ist einem Change-Eintrag und einem Verantwortlichen zugeordnet; kein Eintrag zielt auf einen Tier-0-Host.

• Führen Sie die Prüfung der Schreibberechtigten auf Server- und Tier-0-OUs erneut aus. Die einzigen nicht standardmäßigen Schreibberechtigten sind dokumentierte Bereitstellungsgruppen.

• Bestätigen Sie, dass privilegierte Konten NOT_DELEGATED tragen oder Mitglied von Protected Users sind. Diese Abfrage sollte nichts zurückgeben:

  PowerShell

  # Protected Users hat den RID 525; verschachtelte Mitglieder zählen ebenfalls
  $protected = (Get-ADGroupMember -Identity "$((Get-ADDomain).DomainSID)-525" -Recursive).SID.Value
  Get-ADUser -Filter 'AccountNotDelegated -eq $false' -SearchBase '<admin OU>' |
      Where-Object { $_.SID.Value -notin $protected }

• Aktivieren Sie eine SACL für Schreibvorgänge auf msDS-AllowedToActOnBehalfOfOtherIdentity und msDS-AllowedToDelegateTo am Domänenstamm (Überwachung von Verzeichnisdienständerungen) und alarmieren Sie bei Ereignis 5136 für eines der beiden Attribute.

• Auf DCs enthält Ereignis 4769 ein Feld Transited Services, das bei S4U2Proxy-Anfragen befüllt wird. Erstellen Sie eine Baseline der dort auftauchenden Front-Ends; ein neues ist eine Untersuchung wert. Die Referenz der Ereignis-IDs listet die weiteren sammelnswerten Felder auf.

Was dabei bricht

• Das Entfernen des Protokollübergangs bricht Anwendungen, die Benutzer per Formular, in der Anwendung verarbeiteten Clientzertifikaten oder Claims eines externen IdP authentifizieren und dann ein Kerberos-Back-End aufrufen. Sie scheitern beim zweiten Hop mit Fehlern zur anonymen Anmeldung oder „Zugriff verweigert“.
• Das Kürzen von SPN-Listen bricht den Zugriff über Aliase: Rufen Benutzer sql01 über den Kurznamen auf und ist nur der FQDN-SPN aufgeführt, schlägt die Delegierung fehl. Nehmen Sie beide Formen auf, wo Clients beide verwenden.
• Die Aufnahme von Admins in Protected Users oder NOT_DELEGATED bedeutet, dass diese Admins delegierende Anwendungen nicht mehr unter eigener Identität nutzen können, etwa Webkonsolen, die Back-Ends mit der Identität des Benutzers abfragen. Für diese Werkzeuge sollten sie ein Standardkonto verwenden.
• Das Verschärfen der OU-Delegierung nimmt Helpdesk- oder Bereitstellungskonten die Möglichkeit, Computerattribute zu ändern, die sie bisher bearbeitet haben. Das kann Reimaging-Skripte brechen, die Computerobjekte zurücksetzen oder neu schreiben.

Weiterführende Lektüre: das Thema Delegierung, der Glossareintrag ressourcenbasierte eingeschränkte Delegierung und ACLs in Active Directory prüfen für die umfassendere Berechtigungsprüfung, zu der diese Prüfung gehört.