Uneingeschränkte Delegierung von AD-Servern entfernen

Ein Server, dem für uneingeschränkte Delegierung vertraut wird, behält eine Kopie des Kerberos-TGT jedes Benutzers, der sich bei ihm authentifiziert. Wer lokale Administratorrechte auf diesem Server erlangt, kann diese Tickets extrahieren und überall in der Domäne wiederverwenden. Mit Techniken zur Authentifizierungserzwingung (PrinterBug, PetitPotam und ähnliche) muss ein Angreifer nicht einmal darauf warten, dass sich ein Admin verbindet: Er kann einen Domänencontroller dazu bringen, sich beim Host zu authentifizieren, und das eigene TGT des DC abgreifen. Von dort ist DCSync nur einen Befehl entfernt.

Der Grundlagenleitfaden zur Delegierung erklärt die drei Delegierungsmodelle und ihre Inventarisierung. Dieser Leitfaden vertieft den Teil, an dem die meisten Projekte ins Stocken geraten: herauszufinden, warum ein Server das Flag hat, nachzuweisen, ob tatsächlich etwas darauf angewiesen ist, und es durch eine eingegrenzte Alternative zu ersetzen, ohne die Anwendung zu brechen, die es vor zehn Jahren rechtfertigte.

Messen: die genaue Inventur erstellen

Das Flag ist Bit 0x80000 (TRUSTED_FOR_DELEGATION, dezimal 524288) in userAccountControl. Fragen Sie es mit einem bitweisen LDAP-Filter ab, um Computer, Benutzer und verwaltete Dienstkonten in einem Durchgang zu erfassen, und schließen Sie beschreibbare DCs über ihre primäre Gruppe (516) aus.

Import-Module ActiveDirectory

$filter = '(userAccountControl:1.2.840.113556.1.4.803:=524288)'
Get-ADObject -LDAPFilter $filter -Properties samAccountName, objectClass, primaryGroupID,
        servicePrincipalName, operatingSystem, whenChanged, lastLogonTimestamp |
    Where-Object { $_.primaryGroupID -ne 516 } |
    Select-Object samAccountName, objectClass, operatingSystem, whenChanged,
        @{n='LastLogon';e={[datetime]::FromFileTime($_.lastLogonTimestamp)}},
        @{n='SPNs';e={$_.servicePrincipalName -join '; '}} |
    Sort-Object objectClass, samAccountName |
    Export-Csv .\unconstrained-delegation.csv -NoTypeInformation

Führen Sie das in jeder Domäne der Gesamtstruktur aus: Das Flag gilt pro Konto, und eine untergeordnete Domäne mit einem vergessenen Dateiserver ist für einen Angreifer genauso nützlich wie die Stammdomäne. Erfassen Sie für jedes Ergebnis den Verantwortlichen, die gehosteten Anwendungen und das Datum, an dem das Flag gesetzt wurde. whenChanged ist nur ein Hinweis; wenn Sie die 5136-Überwachung für Computerobjekte aktiviert haben (siehe AD-Überwachung und -Erkennung), suchen Sie nach Änderungen an userAccountControl auf diesem Objekt, um das tatsächliche Datum und das ändernde Konto zu finden.

Notieren Sie auch, welche Konten veraltet sind. Ein deaktiviertes oder längst verwaistes Computerobjekt mit dem Flag ist der einfachste Gewinn: Nichts kann davon abhängen, also entfernen Sie das Flag und deaktivieren oder löschen Sie das Objekt über Ihren normalen Lebenszyklusprozess.

Prüfen: nachweisen, was tatsächlich delegiert

Dass das Flag gesetzt ist, heißt nicht, dass etwas darauf angewiesen ist. Viele Server erhielten es als Pauschallösung während einer alten Fehlersuche. Sie brauchen Nachweise von zwei Seiten.

Auf dem Server: Anmeldungen mit Delegation-Identitätswechselstufe

Ereignis 4624 enthält ab Windows Server 2016 ein Feld ImpersonationLevel. Leitet ein Client sein TGT an den Server weiter, wird die Anmeldung mit der Identitätswechselstufe Delegation (%%1840) protokolliert. Sammeln Sie diese ein bis zwei Wochen lang, einschließlich eines Monatsabschlusses oder Batchzyklus, falls die Anwendung einen hat.

# Auf dem Kandidatenserver ausführen (oder remote mit -ComputerName abfragen)
$xpath = "*[System[EventID=4624] and EventData[Data[@Name='ImpersonationLevel']='%%1840']]"
Get-WinEvent -LogName Security -FilterXPath $xpath -MaxEvents 5000 |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        $d = @{}; $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
        [PSCustomObject]@{
            Time        = $_.TimeCreated
            User        = "$($d.TargetDomainName)\$($d.TargetUserName)"
            LogonType   = $d.LogonType
            Process     = $d.ProcessName
            SourceIP    = $d.IpAddress
        }
    } | Group-Object User, Process | Sort-Object Count -Descending |
    Select-Object Count, Name

Anmeldungen mit Delegation-Stufe von interaktiven Administratoren (RDP, Konsole) belegen keinen Anwendungsbedarf; hier legen lediglich Admins ihre TGTs offen. Netzwerkanmeldungen (Typ 3), die von w3wp.exe, sqlservr.exe oder einem Fachanwendungsdienst verarbeitet werden, sind diejenigen, denen Sie nachgehen müssen.

In der Anwendung: wohin geht der zweite Hop?

Ermitteln Sie für jeden Prozess, der delegierte Anmeldungen erhält, das Back-End, mit dem er als Benutzer spricht: eine Dateifreigabe, eine SQL-Instanz, eine HTTP-API, ein anderes LDAP-Verzeichnis. Fragen Sie den Anwendungsverantwortlichen, lesen Sie die Konfiguration (web.config mit <identity impersonate="true" />, SSRS-Datenquellen mit „Windows integrated security“, SQL-Verbindungsserver mit „Be made using the login's current security context“) und bestätigen Sie das bei Bedarf mit einem Netzwerkmitschnitt. Ergebnis dieses Schritts ist eine kurze Liste von Ziel-SPNs, etwa cifs/fs01.corp.example.com oder MSSQLSvc/sql01.corp.example.com:1433.

Zeigt der Server über das gesamte Zeitfenster keine Netzwerkanmeldungen mit Delegation-Stufe von Dienstprozessen, braucht er mit ziemlicher Sicherheit überhaupt keine Delegierung.

Durchsetzen: das Flag entfernen oder ersetzen

Server ohne Abhängigkeit

Entfernen Sie das Flag und machen Sie weiter. Das Konfigurieren von Delegierung (Setzen des Flags oder Bearbeiten von msDS-AllowedToDelegateTo) erfordert SeEnableDelegationPrivilege auf den Domänencontrollern, das standardmäßig nur Administratoren auf DCs besitzen – führen Sie diese Änderungen daher aus einer Tier-0-Admin-Sitzung aus.

Set-ADComputer -Identity FS-LEGACY01 -TrustedForDelegation $false
# Für ein benutzerbasiertes Dienstkonto
Set-ADAccountControl -Identity svc-legacyapp -TrustedForDelegation $false

Vorhandene Kerberos-Tickets auf dem Server behalten ihre weitergeleiteten TGTs bis zum Ablauf. Planen Sie daher im selben Änderungsfenster einen Neustart des Servers ein. Das leert die zwischengespeicherten Tickets aus LSASS und stellt sicher, dass nichts stillschweigend mit alten Anmeldeinformationen weiterläuft und so eine echte Abhängigkeit bis zum nächsten Tag verbirgt.

Server mit echtem Double Hop

Ersetzen Sie die uneingeschränkte Delegierung durch ein eingegrenztes Modell. Sie haben zwei Optionen, ausführlich behandelt in Eingeschränkte Delegierung und RBCD sicher einsetzen:

• Kerberos-eingeschränkte Delegierung (KCD), konfiguriert auf dem Front-End-Konto über msDS-AllowedToDelegateTo. Verwenden Sie die Variante „Kerberos only“, wann immer Benutzer das Front-End per Kerberos erreichen; der Protokollübergang ist nur nötig, wenn sie sich per Formular, Zertifikat oder NTLM authentifizieren.
• Ressourcenbasierte eingeschränkte Delegierung, konfiguriert auf dem Back-End über msDS-AllowedToActOnBehalfOfOtherIdentity. Nützlich, wenn das Back-End in einer anderen Domäne liegt oder der Back-End-Verantwortliche steuern soll, wer an es delegieren darf.

# Option 1: KCD, nur Kerberos, von WEB01 zur benötigten Dateifreigabe und SQL-Instanz
Set-ADComputer -Identity WEB01 -TrustedForDelegation $false
Set-ADComputer -Identity WEB01 -Add @{
    'msDS-AllowedToDelegateTo' = @(
        'cifs/fs01.corp.example.com', 'cifs/fs01',
        'MSSQLSvc/sql01.corp.example.com:1433'
    )
}

# Option 2: RBCD, das Back-End vertraut dem Front-End
Set-ADComputer -Identity SQL01 -PrincipalsAllowedToDelegateToAccount (Get-ADComputer WEB01)

Läuft die Anwendung unter einem Domänendienstkonto statt unter dem Computerkonto, legen Sie die Delegierung auf dieses Konto und nutzen Sie die Gelegenheit, es auf ein gMSA umzustellen (siehe Härtung von Dienstkonten). Delegierung auf einem Benutzerkonto mit statischem Kennwort ist eine schwächere Kontrolle als dieselbe Einstellung auf einem verwalteten Konto.

Nehmen Sie die Änderung Server für Server vor, starten Sie neu und testen Sie den Double Hop als normaler Benutzer. Halten Sie den vorherigen userAccountControl-Wert im Change-Eintrag fest, damit der Rollback ein einziger Befehl ist.

Gesamtstrukturübergreifende Abhängigkeiten

Seit den Windows-Updates vom Juli 2019 ist die TGT-Delegierung über Gesamtstruktur-Vertrauensstellungen standardmäßig deaktiviert (das Vertrauensattribut wird mit netdom trust <trust> /domain:<forest> /EnableTGTDelegation:No gesteuert). Hat sich eine alte Anwendung für Benutzer aus einer vertrauenswürdigen Gesamtstruktur auf uneingeschränkte Delegierung verlassen, ist sie bereits gebrochen oder umgebaut worden. Aktivieren Sie die TGT-Delegierung auf der Vertrauensstellung nicht wieder, um sie zu retten; verwenden Sie stattdessen RBCD, das über Vertrauensgrenzen hinweg funktioniert. Die Vertrauensseite behandelt der Leitfaden zur Härtung von Vertrauensstellungen und Gesamtstrukturen.

Kompensierende Maßnahmen während der Migration

Manche Server brauchen Monate bis zur Behebung. Verringern Sie bis dahin, was sie einsammeln können:

• Nehmen Sie jedes Tier-0- und Tier-1-Admin-Konto in Protected Users auf oder setzen Sie „Account is sensitive and cannot be delegated“. Deren TGTs werden dann nie an den Server weitergeleitet.
• Beenden Sie die Druckwarteschlange auf Domänencontrollern und wenden Sie die Coercion-Gegenmaßnahmen aus Authentifizierungserzwingung blockieren an. Das entfernt den Schritt „DC zur Verbindung mit mir zwingen“.
• Behandeln Sie die verbleibenden Server in Ihrem Admin-Modell als Tier 0: Beschränken Sie, wer lokaler Administrator ist, und lassen Sie keine Tier-1- oder Helpdesk-Konten sich dort anmelden.

Überprüfen

Führen Sie die Inventurabfrage in jeder Domäne erneut aus. Die einzigen Ergebnisse sollten beschreibbare DCs (bereits herausgefiltert) und eine explizit dokumentierte Ausnahmeliste sein, die jedes Quartal kürzer wird.

Get-ADObject -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=524288)' `
    -Properties primaryGroupID |
    Where-Object { $_.primaryGroupID -ne 516 } |
    Measure-Object | Select-Object Count

Stellen Sie dann sicher, dass nichts das Flag wieder einführt. Aktivieren Sie die Überwachung von userAccountControl-Änderungen an Computer- und Benutzerobjekten und alarmieren Sie bei jedem Ereignis 4742 (Computer geändert) oder 4738 (Benutzer geändert), dessen Feld User Account Control auf einem Nicht-DC „'Trusted For Delegation' - Enabled“ zeigt. Neue Server-Builds sollten in Ihrer Bereitstellungspipeline mit derselben Abfrage geprüft werden, und die Prüfung ist auch Teil eines PingCastle-Assessments, sodass der regelmäßige Scan Abweichungen erkennt.

Testen Sie abschließend die migrierten Anwendungen durchgängig als Standardbenutzer von einem Client ohne zwischengespeicherte Tickets, einschließlich aller geplanten Berichte oder Batchjobs, die über Nacht laufen.

Was dabei bricht

• IIS-Anwendungen mit Windows-Authentifizierung und Identitätswechsel, die als Benutzer einen UNC-Pfad lesen, SQL abfragen oder eine andere Kerberos-geschützte API aufrufen, scheitern beim zweiten Hop mit „Zugriff verweigert“ oder Fehlern zur anonymen Anmeldung, bis KCD oder RBCD mit den korrekten SPNs konfiguriert ist.
• SSRS und SharePoint mit Datenquellen auf Windows integrated security rendern für Benutzer keine Berichte mehr, wenn der Delegierungspfad ohne Ersatz entfernt wird.
• SQL-Server-Verbindungsserver, die den aktuellen Sicherheitskontext der Anmeldung verwenden, scheitern mit „Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'“.
• Alte Druck-, Fax- und Dokumentenmanagementserver verließen sich gelegentlich auf weitergeleitete TGTs, um Ausgaben in Benutzer-Basisfreigaben zu schreiben; das zeigt sich als fehlgeschlagene Jobs statt als klare Fehlermeldung.
• Anwendungen, die SPNs per IP oder Alias registrieren: Verbinden sich Benutzer über einen CNAME oder den Namen eines Load Balancers ohne passenden SPN, hilft KCD erst, wenn der SPN korrigiert ist, denn der Client fällt auf NTLM zurück, und ein KCD-Pfad „Kerberos only“ kann keine NTLM-Anmeldung delegieren.

Weiterführende Lektüre: das Thema Delegierung für die gesamte Serie, ms-DS-MachineAccountQuota auf 0 setzen, um den Pfad zur Erstellung von Computerkonten zu schließen, mit dem Angreifer RBCD missbrauchen, sobald die uneingeschränkte Delegierung verschwunden ist, und der Glossareintrag uneingeschränkte Delegierung als kurze Definition für Anwendungsverantwortliche.