SID-Filterung und selektive Authentifizierung umsetzen

Eine Vertrauensstellung erweitert Ihre Sicherheitsgrenze auf alles, was sich auf der anderen Seite befindet. Wird die vertrauenswürdige Domäne kompromittiert, entscheiden zwei Dinge darüber, wie weit der Angreifer kommt: welche SIDs Ihre Domänencontroller in den Autorisierungsdaten akzeptieren, die über die Vertrauensstellung eintreffen, und welche Ihrer Computer überhaupt Authentifizierungen von vertrauenswürdigen Prinzipalen annehmen. Die SID-Filterung beantwortet die erste Frage, die selektive Authentifizierung die zweite. Beides sind einfache Schalter, und beide stehen nach einer Migration oder einer übereilten Partneranbindung regelmäßig in der falschen Position.

Der Grundlagenartikel zu Vertrauensstellungen und Gesamtstrukturgrenzen erklärt, warum die Gesamtstruktur die Grenze ist. Dieser Leitfaden ist die operative Fortsetzung: wie Sie den tatsächlichen Zustand jeder Vertrauensstellung aus trustAttributes auslesen, wie sich die SID-Filterung bei externen im Vergleich zu Gesamtstruktur-Vertrauensstellungen verhält, wie Sie die selektive Authentifizierung einführen, ohne den gesamtstrukturübergreifenden Zugriff zu unterbrechen, und wie Sie das Ergebnis anhand von Ereignissen überprüfen.

Messen: die Vertrauensflags lesen, nicht die GUI

Der Eigenschaftendialog einer Vertrauensstellung verbirgt mehrere Einstellungen. Maßgeblich ist die Bitmaske trustAttributes auf dem trustedDomain-Objekt in CN=System.

Get-ADObject -SearchBase "CN=System,$((Get-ADDomain).DistinguishedName)" `
    -LDAPFilter "(objectClass=trustedDomain)" -Properties trustAttributes, trustDirection, trustType |
  Select-Object Name, trustDirection, trustType,
    @{n='Attr';e={'0x{0:X}' -f $_.trustAttributes}},
    @{n='Forest';e={[bool]($_.trustAttributes -band 0x8)}},
    @{n='Quarantined';e={[bool]($_.trustAttributes -band 0x4)}},
    @{n='SelectiveAuth';e={[bool]($_.trustAttributes -band 0x10)}},
    @{n='SIDHistoryAllowed';e={[bool]($_.trustAttributes -band 0x40)}},
    @{n='TGTDelegationEnabled';e={[bool]($_.trustAttributes -band 0x800)}}

trustDirection 1 ist eingehend (die andere Seite vertraut Ihnen), 2 ist ausgehend (Sie vertrauen der anderen Seite, deren Benutzer können Sie erreichen), 3 ist bidirektional. Die Härtung erfolgt auf der vertrauenden Seite: Die folgenden Maßnahmen schützen die vertrauende Domäne vor Prinzipalen der vertrauenswürdigen Domäne. Führen Sie die Abfrage in jeder Domäne aus, die Vertrauensstellungen besitzt.

Wie sich die SID-Filterung tatsächlich verhält

Gefiltert wird auf den Domänencontrollern der vertrauenden Seite, wenn diese Autorisierungsdaten (die PAC) verarbeiten, die über die Vertrauensstellung eintreffen.

• Externe Vertrauensstellungen mit Quarantäne: Nur SIDs aus der vertrauenswürdigen Domäne selbst bleiben erhalten. SID-Verlauf aus jeder anderen Domäne wird verworfen.
• Gesamtstruktur-Vertrauensstellungen (Standard): SIDs aus beliebigen Domänen der vertrauenswürdigen Gesamtstruktur werden akzeptiert; SIDs, die vorgeben, zu Ihrer oder einer dritten Gesamtstruktur zu gehören, werden verworfen. Das bedeutet: SID-Verlauf, der auf Ihre eigenen Gruppen verweist, wird gefiltert – und genau das vereitelt SID History Injection.
• Gesamtstruktur-Vertrauensstellungen mit /enablesidhistory:yes (TREAT_AS_EXTERNAL): SID-Verlauf von außerhalb der vertrauenswürdigen Gesamtstruktur wird akzeptiert, ausgenommen SIDs mit einer RID unter 1000. Integrierte Gruppen wie Domain Admins und Enterprise Admins sind geschützt, benutzerdefinierte Admin-Gruppen, Exchange-Gruppen und delegierte Helpdesk-Gruppen haben jedoch RIDs über 1000 und können eingeschleust werden.
• Vertrauensstellungen innerhalb der Gesamtstruktur: keine Filterung. Übergeordnet-untergeordnet-Vertrauensstellungen liegen innerhalb der Grenze; sie unter Quarantäne zu stellen, wird nicht unterstützt und beeinträchtigt den Betrieb der Gesamtstruktur.

Wenn ein DC SIDs verwirft, protokolliert er Ereignis 4675 („SIDs were filtered“). Das liefert Ihnen ein direktes Signal – entweder für Nachwirkungen einer Migration oder für einen Injektionsversuch. Legitimer gesamtstrukturübergreifender Zugriff wird im Glossareintrag zur SID-Filterung ausführlicher beschrieben.

Auditieren: wer ist wovon abhängig

Bevor Sie verschärfen, ermitteln Sie, was über jede Vertrauensstellung läuft.

1. Gruppenmitgliedschaften: Fremde Sicherheitsprinzipale (Foreign Security Principals, FSPs) in CN=ForeignSecurityPrincipals stehen für Benutzer und Gruppen der vertrauenswürdigen Domäne, die in Ihre Gruppen aufgenommen wurden. Lösen Sie sie auf und prüfen Sie sie.
2. Anmeldungen: Ereignis 4624 auf Servern mit einem TargetDomainName aus der vertrauenswürdigen Domäne sowie 4769 auf Ihren DCs für Verweistickets zeigen, welche Computer Partnerprinzipale tatsächlich nutzen.
3. Abhängigkeit vom SID-Verlauf: jedes Konto in der vertrauenswürdigen Domäne, dessen sIDHistory SIDs Ihrer Domäne enthält – das funktioniert nur, solange der SID-Verlauf zugelassen ist. Diese Arbeit gehört in die Bereinigung des SID-Verlaufs.

Get-ADObject -SearchBase "CN=ForeignSecurityPrincipals,$((Get-ADDomain).DistinguishedName)" -Filter * -Properties memberOf |
  ForEach-Object {
    $name = try { ([Security.Principal.SecurityIdentifier]$_.Name).Translate([Security.Principal.NTAccount]).Value } catch { 'unresolved' }
    [pscustomobject]@{ SID = $_.Name; Account = $name; MemberOf = ($_.memberOf -join '; ') }
  }

Nicht auflösbare FSPs deuten meist auf gelöschte Partnerobjekte oder stillgelegte Vertrauensstellungen hin und können aus den Gruppen entfernt werden.

Durchsetzen: SID-Filterung

Führen Sie netdom auf einem DC der vertrauenden Domäne als Domain Admin dieser Domäne aus. Für externe Vertrauensstellungen:

netdom trust corp.example.com /domain:partner.example.net /quarantine
netdom trust corp.example.com /domain:partner.example.net /quarantine:yes

Die erste Form zeigt den aktuellen Zustand an, die zweite aktiviert die Quarantäne. Für Gesamtstruktur-Vertrauensstellungen stellen Sie nach einer Migration die Standardfilterung wieder her:

netdom trust corp.example.com /domain:partner.example.net /enablesidhistory
netdom trust corp.example.com /domain:partner.example.net /enablesidhistory:no

Wenn Sie ohnehin mit netdom arbeiten, prüfen Sie auch die TGT-Delegierung. Seit den Updates vom Juli 2019 ist uneingeschränkte Delegierung über Gesamtstruktur-Vertrauensstellungen standardmäßig blockiert, und das Flag 0x800 in der Messabfrage zeigt, ob jemand sie wieder aktiviert hat. Microsofts Anleitung für diesen Schalter nennt die vertrauenswürdige Gesamtstruktur zuerst; bestätigen Sie die Reihenfolge der Argumente mit netdom trust /? auf Ihrem DC:

netdom trust <TrustedForestName> /domain:<TrustingForestName> /EnableTGTDelegation:No

Würde die TGT-Delegierung zugelassen, könnte ein Server mit uneingeschränkter Delegierung in einer Gesamtstruktur TGTs aus der anderen abgreifen.

Durchsetzen: selektive Authentifizierung

Die selektive Authentifizierung (CROSS_ORGANIZATION) ändert den Standard für vertrauenswürdige Prinzipale von „authentifizierte Benutzer erreichen jeden Computer“ zu „kein Computer, sofern nicht ausdrücklich erlaubt“. Führen Sie sie in dieser Reihenfolge ein.

1. Freigabegruppen auf der Ressourcenseite anlegen

Legen Sie in der vertrauenden Domäne pro Ressourcengruppe eine domänenlokale Gruppe an, zum Beispiel SA-Partner-FileServers, und nehmen Sie die globalen Gruppen des Partners darin auf. Wenn Zugriffe über Gruppen laufen, die Ihnen gehören, bleiben die ACLs lesbar.

2. Allowed to Authenticate auf jedem Zielcomputer erteilen

Das Recht ist das erweiterte Recht Allowed to Authenticate (68b1d179-0d15-4d4f-ab71-46152e79a7bc) auf Computerobjekten. Erteilen Sie es per PowerShell:

$group   = Get-ADGroup "SA-Partner-FileServers"
$sid     = [Security.Principal.SecurityIdentifier]$group.SID
$guid    = [Guid]"68b1d179-0d15-4d4f-ab71-46152e79a7bc"
$targets = "FS01","FS02"

foreach ($t in $targets) {
    $dn  = (Get-ADComputer $t).DistinguishedName
    $acl = Get-Acl "AD:$dn"
    $ace = New-Object DirectoryServices.ActiveDirectoryAccessRule($sid, "ExtendedRight", "Allow", $guid)
    $acl.AddAccessRule($ace)
    Set-Acl "AD:$dn" $acl
}

Damit Partnerbenutzer Mitgliedsserver erreichen, sind in der Regel keine Berechtigungen auf Ihren Domänencontrollern nötig. Erteilen Sie das Recht auf einem DC nur, wenn Partnerprinzipale eine auf diesem DC gehostete Ressource nutzen müssen – und niemals pauschal auf der OU Domain Controllers.

3. Den Schalter umlegen

netdom trust corp.example.com /domain:partner.example.net /SelectiveAuth:yes

Die Änderung wird wirksam, sobald sie repliziert ist. Halten Sie /SelectiveAuth:no als Rollback bereit und nehmen Sie die Änderung in einem Zeitfenster vor, in dem der Partner testen kann.

Die Einführung mit dem Partner planen

Änderungen an Vertrauensstellungen betreffen Personen, die Sie nicht verwalten. Behandeln Sie sie daher als gemeinsame Änderung und nicht als lokale Einstellung.

• Zuerst die Fakten teilen. Schicken Sie dem Partner die Liste der fremden Sicherheitsprinzipale und der Server, bei denen sich seine Benutzer tatsächlich authentifizieren – aus den obigen 4624-Daten. Häufig entdeckt er veraltete Konten und ungenutzte Zugriffe, die Sie streichen können, statt sie freizugeben.
• Erst die Richtung reduzieren, dann Maßnahmen ergänzen. Wenn nur seine Benutzer Ihre Ressourcen benötigen, sollte die Vertrauensstellung von Ihrer Domäne aus unidirektional ausgehend sein; eine bidirektionale Vertrauensstellung verdoppelt die Angriffsfläche ohne Nutzen. Erstellen Sie die Vertrauensstellung in der benötigten Richtung neu, statt eine Seite zu härten, die niemand nutzt.
• Bevorzugen Sie Gesamtstruktur- gegenüber externen Vertrauensstellungen zwischen Gesamtstrukturen, die Sie kontrollieren: Gesamtstruktur-Vertrauensstellungen verwenden standardmäßig Kerberos, unterstützen Einschränkungen des Namenssuffixroutings und filtern SIDs gesamtstrukturbewusst. Externe Vertrauensstellungen fallen häufiger auf NTLM zurück, was sich mit jedem Plan überschneidet, NTLM einzuschränken.
• Schränken Sie das Namenssuffixrouting auf Gesamtstruktur-Vertrauensstellungen ein, damit der Partner keine Authentifizierung für Suffixe weiterleiten kann, die Sie nicht akzeptieren wollten.
• Vereinbaren Sie einen Überprüfungszyklus. Vertrauensstellungen überdauern die Projekte, die sie geschaffen haben. Versehen Sie jede Vertrauensstellung mit einem Verantwortlichen und einem Überprüfungsdatum, und entfernen Sie sie mit netdom trust /remove, sobald der geschäftliche Bedarf endet.

Überprüfen

# Die trustAttributes-Abfrage oben erneut ausführen und dann mit Get-ADTrust abgleichen
Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, SIDFilteringQuarantined, SIDFilteringForestAware, SelectiveAuthentication

# Wer sich an einem bestimmten Server authentifizieren darf
(Get-Acl "AD:$((Get-ADComputer FS01).DistinguishedName)").Access |
  Where-Object { $_.ObjectType -eq '68b1d179-0d15-4d4f-ab71-46152e79a7bc' } |
  Select-Object IdentityReference, AccessControlType

Steht SIDFilteringForestAware auf einer Gesamtstruktur-Vertrauensstellung auf True, ist der SID-Verlauf zugelassen – genau der Zustand, den Sie rückgängig machen wollen. Testen Sie anschließend von der Partnerseite aus: Ein berechtigter Benutzer erreicht FS01; derselbe Benutzer sollte bei einem anderen Server scheitern, und dort sollte Ereignis 4625 mit Status 0xC0000413 erscheinen. Leiten Sie 4675 sowie 4625 mit diesem Status an Ihr SIEM weiter – mit dem Sammlungsdesign aus Windows Event Forwarding.

Was dadurch nicht mehr funktioniert

• Alles, was auf implizitem Zugriff über eine offene Vertrauensstellung beruht: Dateifreigaben, SQL-Anmeldungen, Webanwendungen mit Kerberos und Druckserver schlagen für Partnerbenutzer fehl, bis jeder Zielcomputer eine Allowed-to-Authenticate-Berechtigung besitzt.
• Interaktive Anmeldungen von Partnerbenutzern an Arbeitsstationen oder RDS-Hosts in Ihrer Domäne erfordern eine Berechtigung auf jedem dieser Computer; ist diese Liste lang, verdient das Design der Vertrauensstellung selbst eine Überprüfung.
• Laufende Migrationen brechen ab, wenn die SID-Verlaufsfilterung zurückkehrt, da migrierte Benutzer den über alte SIDs gewährten Zugriff verlieren.
• Gesamtstrukturübergreifende uneingeschränkte Delegierung funktioniert nicht mehr, wenn die TGT-Delegierung deaktiviert ist; stellen Sie diese Szenarien auf eingeschränkte Delegierung oder RBCD um.
• Identitätswerkzeuge von Drittanbietern, die von beliebigen Servern aus über die Vertrauensstellung hinweg aufzählen oder sich authentifizieren, benötigen eigene Berechtigungen.

Weiterführende Lektüre: das Thema Vertrauensstellungen & Gesamtstruktur, der Glossareintrag zum SID-Verlauf und Eingeschränkte Delegierung und RBCD sicher umsetzen, um gesamtstrukturübergreifende uneingeschränkte Delegierung zu ersetzen.