SIDHistory nach AD-Migrationen bereinigen

sIDHistory existiert aus einem guten Grund: Wenn ein Benutzer oder eine Gruppe von einer Domäne in eine andere wechselt, behält das Objekt seine alten SIDs, damit Ressourcen, die noch für die alte Identität berechtigt sind, weiter funktionieren. In der Praxis werden Migrationen abgeschlossen, Quelldomänen stillgelegt – und die alten SIDs bleiben ein Jahrzehnt lang auf Tausenden Objekten stehen. Jeder dieser Werte ist eine zusätzliche Identität im Token des Benutzers und ein Ort, an dem ein Angreifer mit ausreichenden Rechten Privilegien verstecken kann: Ein SID-Verlauf-Wert, der auf Domain Admins zeigt, verleiht Domain-Admins-Rechte, ohne in der Mitgliederliste der Gruppe aufzutauchen.

Der Grundlagenartikel zu Vertrauensstellungen und Gesamtstrukturgrenzen behandelt die Filterung des SID-Verlaufs an der Vertrauensstellung. Dieser Leitfaden befasst sich mit den Objekten selbst: jeden sIDHistory-Wert finden, gefährliche Einträge von Migrationsresten trennen, Ressourcen neu berechtigen, sodass alte SIDs nicht mehr benötigt werden, Werte in Etappen entfernen und so überwachen, dass neue Werte nicht unbemerkt auftauchen.

Bevor Sie etwas anfassen, klären Sie die Zuständigkeiten. Die Bereinigung des SID-Verlaufs betrifft Identitäts-, Dateiserver-, Anwendungs- und Sicherheitsteams, und Fehler sind für Endbenutzer sichtbar. Benennen Sie einen Verantwortlichen für das Programm, einen Ansprechpartner pro Anwendung und einen Kommunikationsplan, der Pilotbenutzern sagt, was sie melden sollen und wo.

Warum verbliebener SID-Verlauf ein Risiko ist

• Versteckte Privilegien. Tokens enthalten den SID-Verlauf. Ein normaler Benutzer mit der SID einer privilegierten Gruppe in sIDHistory ist damit faktisch Mitglied. Überprüfungen von Gruppenmitgliedschaften, adminCount und die meisten Admin-Berichte zeigen das nicht.
• Persistenz. Das Hinzufügen von SID-Verlauf erfordert normalerweise die Migrations-API mit Domain-Admin-Rechten in der Zieldomäne. Ein Angreifer, der Tier 0 bereits erreicht hat, kann ihn jedoch mit Werkzeugen wie Mimikatz oder DSInternals direkt schreiben. Er übersteht Kennwortzurücksetzungen und wird bei der Incident Response leicht übersehen.
• Aufgeblähte Tokens. Benutzer mit vielen alten SIDs und vielen Gruppen können die Grenzwerte für die Kerberos-Tokengröße überschreiten, was zu sporadischen Authentifizierungsfehlern führt.
• Exposition über Vertrauensstellungen. Soll der SID-Verlauf über eine Vertrauensstellung weiter funktionieren, müssen Sie die SID-Filterung gelockert lassen, was die Vertrauensstellung selbst schwächt. Siehe SID-Filterung und selektive Authentifizierung.

Messen: jeden Wert inventarisieren

$forestSids = (Get-ADForest).Domains | ForEach-Object { (Get-ADDomain $_).DomainSID.Value }

Get-ADObject -LDAPFilter "(sIDHistory=*)" -Properties sIDHistory, objectClass, samAccountName, whenChanged |
  ForEach-Object {
    $obj = $_
    foreach ($sid in $obj.sIDHistory) {
        $prefix = $sid.AccountDomainSid.Value
        [pscustomobject]@{
            Object       = $obj.samAccountName
            Class        = $obj.objectClass
            HistorySid   = $sid.Value
            SourceDomain = $prefix
            Rid          = [int]($sid.Value.Split('-')[-1])
            Builtin      = $sid.Value.StartsWith('S-1-5-32-')
            SameForest   = $forestSids -contains $prefix
            WhenChanged  = $obj.whenChanged
        }
    }
  } | Export-Csv .\sidhistory-inventory.csv -NoTypeInformation

Führen Sie das Skript in jeder Domäne der Gesamtstruktur aus. Die CSV-Datei ist Ihre Ausgangsbasis und der Nachweis, den Sie später brauchen, denn entfernte Werte lassen sich nicht einfach zurückschreiben.

Gruppieren Sie die Ergebnisse nach SourceDomain. Meist sehen Sie ein oder zwei alte Domänen-SIDs – eine pro historischer Migration – und jeweils die Anzahl der Objekte. Ordnen Sie jedes Präfix anhand der Migrationsunterlagen einer bekannten Quelldomäne zu; existiert die Quelle noch und besteht eine Vertrauensstellung, löst Translate() eine Beispiel-SID auf.

Auditieren: nach Risiko einstufen

Ordnen Sie jeden Wert einer von drei Kategorien zu.

Kritisch: als Sicherheitsvorfall untersuchen

• SameForest ist True. Legitime Migrationen kopieren SIDs aus der Quelldomäne in die Zieldomäne; ein Wert aus Ihrer eigenen Gesamtstruktur, erst recht aus derselben Domäne, ist kein Migrationsartefakt.
• Rid liegt unter 1000, gleich aus welcher Domäne, insbesondere 500, 512, 518 und 519, oder Builtin ist True, insbesondere S-1-5-32-544 (Administrators). Integrierte SIDs haben kein Domänenpräfix, daher ist SourceDomain bei ihnen leer. Integrierte privilegierte RIDs und SIDs im SID-Verlauf sind eine klassische Persistenztechnik.
• Werte auf Objekten, deren whenChanged lange nach der letzten bekannten Migration liegt.

Löschen Sie diese nicht einfach. Sichern Sie das Objekt und seine Metadaten (repadmin /showobjmeta liefert den ursprünglichen DC und den Zeitpunkt der sIDHistory-Änderung) und durchsuchen Sie Ihre Ereignisprotokolle rund um diesen Zeitpunkt nach 4765 und 4766. Entfernen Sie anschließend den Wert und erneuern Sie die Anmeldeinformationen des Kontos.

Altlasten mit aktiven Abhängigkeiten

Werte aus einer Quelldomäne, deren SIDs noch auf Ressourcen berechtigt sind: Dateiserver, die mit intakten Berechtigungen migriert wurden, Anwendungen mit ACLs auf alte SIDs, SQL-Anmeldungen. Diese müssen zuerst neu berechtigt werden.

Altlasten ohne Abhängigkeiten

Werte aus einer Quelldomäne, die vor Jahren stillgelegt wurde und deren Ressourcen neu aufgebaut wurden. In der Regel die Mehrheit – und nach einem Pilot sicher entfernbar.

Durchsetzen: vor dem Entfernen neu berechtigen

Ziel ist es, jeden ACE, der eine alte SID referenziert, durch einen zu ersetzen, der die aktuelle SID desselben Prinzipals referenziert. Werkzeuge:

• ADMT-Sicherheitsübersetzung (Assistent „Translate Objects“) funktioniert, sofern ADMT und die Migrationsdatenbank noch existieren.
• icacls /substitute ersetzt in NTFS-ACLs eine SID durch eine andere: icacls D:\Shares /substitute <OldSID> <NewSID> /t /c. Verwenden Sie zuvor /save, um eine wiederherstellbare Kopie der ACLs zu behalten.
• Berechtigungen auf Anwendungsebene (SQL-Anmeldungen, die alten SIDs zugeordnet sind, Exchange-Postfachberechtigungen, SharePoint-Websiteberechtigungen) erfordern eigene Werkzeuge.

Ermitteln Sie vor und nach der Übersetzung, was auf Dateiservern alte SIDs referenziert:

$oldPrefix = "S-1-5-21-1111111111-2222222222-3333333333"   # SID der alten Quelldomäne
Get-ChildItem D:\Shares -Directory -Recurse -ErrorAction SilentlyContinue |
  ForEach-Object {
    $rules = (Get-Acl $_.FullName).GetAccessRules($true, $true, [Security.Principal.SecurityIdentifier])
    $hits  = $rules | Where-Object { $_.IdentityReference.Value -like "$oldPrefix-*" }
    if ($hits) { [pscustomobject]@{ Path = $_.FullName; Count = @($hits).Count } }
  }

Ein ACE für einen Prinzipal, dessen einzige Verbindung zur alten SID der SID-Verlauf ist, wird in der GUI zum aktuellen Kontonamen aufgelöst. Deshalb müssen ACL-Scans mit rohen SIDs statt mit Anzeigenamen arbeiten. Beziehen Sie auch ACLs von AD-Objekten ein: Delegierungen auf OUs referenzieren migrierte Gruppen mitunter über die alte SID. Der Leitfaden zur ACL-Prüfung zeigt, wie Sie diese auslesen.

Durchsetzen: gestaffeltes Entfernen

Entfernen Sie in Wellen: zuerst ein Pilot mit IT-Benutzern, dann Abteilungen, Gruppen zuletzt (der SID-Verlauf einer Gruppe betrifft jedes Mitglied).

# Gesamten SID-Verlauf von einem Objekt entfernen und protokollieren, was entfernt wurde
$user = Get-ADUser "jdoe" -Properties sIDHistory
$user.sIDHistory | ForEach-Object { "{0};{1}" -f $user.SamAccountName, $_.Value } |
  Add-Content .\sidhistory-removed.log
foreach ($sid in $user.sIDHistory) {
    Set-ADUser $user -Remove @{ sIDHistory = $sid.Value }
}

# Nur Werte aus einer bestimmten alten Domäne entfernen, für eine Pilotgruppe
$oldPrefix = "S-1-5-21-1111111111-2222222222-3333333333"
Get-ADGroupMember "SIDH-Pilot" | Get-ADUser -Properties sIDHistory |
  ForEach-Object {
    $u = $_
    $u.sIDHistory | Where-Object { $_.AccountDomainSid.Value -eq $oldPrefix } |
      ForEach-Object { Set-ADUser $u -Remove @{ sIDHistory = $_.Value } }
  }

Für Gruppen verwenden Sie Set-ADGroup mit derselben -Remove-Syntax. Benutzer übernehmen die Änderung bei der nächsten Anmeldung, wenn ein neues TGT ausgestellt wird; bitten Sie Pilotbenutzer, sich ab- und wieder anzumelden, oder warten Sie den Ablauf der Tickets ab. Lassen Sie jede Welle einen vollen Geschäftszyklus lang bestehen, einschließlich der Monatsabschlussprozesse, bevor Sie fortfahren.

Ein Rollback ist nur eingeschränkt möglich. Sie können sIDHistory nicht mit Set-ADUser -Add zurückschreiben. Die Optionen sind eine erneute Migration mit ADMT (nur wenn die Quelldomäne noch existiert) oder eine autoritative Wiederherstellung der betroffenen Objekte aus einer Sicherung. Deshalb kommen Neuberechtigung und Pilotphasen zuerst.

Das Programm realistisch planen

In einer großen Umgebung dauert die Bereinigung Monate, nicht Tage, und die Reihenfolge ist entscheidend:

1. Woche 1: kritische Befunde. SIDs aus derselben Gesamtstruktur und privilegierte RIDs werden sofort als Sicherheitsbefunde behandelt, unabhängig vom Rest.
2. Monat 1: Nachweise. Schließen Sie die Inventarisierung in jeder Domäne ab, ordnen Sie jede Quelldomäne zu und führen Sie ACL-Scans auf Dateiservern und Anwendungsdatenbanken durch. Schätzen Sie die Anzahl der zu übersetzenden ACEs pro Quelldomäne; diese Zahl, nicht die Anzahl der Objekte, bestimmt den Aufwand.
3. Monate 2–3: Übersetzung. Berechtigen Sie zuerst die Dateiserver neu, da sie die meisten ACEs mit alten SIDs tragen, dann die Anwendungen. Bewahren Sie ACL-Exporte von vorher und nachher auf.
4. Monate 3–6: Entfernungswellen. Pilot, Abteilungen, dann Gruppen – mit mindestens einem Monatsabschluss zwischen den Wellen.
5. Zum Schluss: die Vertrauensstellung. Sobald keine Werte aus einer vertrauenswürdigen Quelldomäne mehr übrig sind, aktivieren Sie die SID-Filterung auf dieser Vertrauensstellung wieder oder entfernen die Vertrauensstellung ganz, wenn sie nur für die Migration existierte.

Verfolgen Sie den Fortschritt mit zwei Kennzahlen, die Sie an die Leitung berichten: verbleibende Objekte mit sIDHistory und ACEs, die noch alte SIDs referenzieren. Beide sollten auf null fallen; eine flache Kurve bedeutet meist, dass ein Anwendungsteam blockiert ist und Hilfe braucht statt einer Erinnerung.

Überprüfen und überwachen

# Verbleibende Werte, nach Quelldomäne
Import-Csv .\sidhistory-inventory.csv | Group-Object SourceDomain | Select-Object Name, Count
(Get-ADObject -LDAPFilter "(sIDHistory=*)").Count

# Noch SID-Verlauf aus derselben Domäne vorhanden? Sollte null sein
$domainSid = (Get-ADDomain).DomainSID.Value
Get-ADObject -LDAPFilter "(sIDHistory=*)" -Properties sIDHistory |
  Where-Object { $_.sIDHistory.AccountDomainSid.Value -contains $domainSid } | Select-Object Name

Für die laufende Erkennung sollten Sie bei folgenden Ereignissen alarmieren:

• 4765 (SID History was added to an account) und 4766 (an attempt to add SID History failed). Außerhalb einer geplanten Migration ist jedes 4765 ein Sicherheitsvorfall.
• 5136 auf dem Attribut sIDHistory; das erfordert die Überwachung von Directory Service Changes und eine SACL auf Benutzer- und Gruppenobjekten.
• 4738 und 4742, wenn sich das Feld SID History ändert.

Werkzeuge wie BloodHound und PingCastle melden ebenfalls SID-Verlauf, der auf privilegierte Gruppen verweist; nehmen Sie diese Prüfungen in Ihre regelmäßige Bewertung auf.

Was dadurch nicht mehr funktioniert

• Zugriff auf Ressourcen, die noch mit alten SIDs berechtigt sind: Dateifreigaben, Drucker, Anwendungsrollen und SQL-Anmeldungen verweigern Benutzern den Zugriff, deren SID-Verlauf vor der Übersetzung entfernt wurde.
• Das Entfernen des SID-Verlaufs von Gruppen betrifft alle Mitglieder gleichzeitig; eine übersehene ACL kann eine ganze Abteilung aussperren.
• Zugriffe über Vertrauensstellungen, die stillschweigend über eine gelockerte Vertrauensstellung auf den SID-Verlauf angewiesen waren, funktionieren nicht mehr – das ist zugleich der Punkt, an dem Sie die Filterung wieder aktivieren können.
• Erneute ADMT-Läufe als Rollback benötigen Quelldomäne, Vertrauensstellung und Migrationsdatenbank, die oft nicht mehr existieren.
• Skripte und Berichte, die alte SIDs über den SID-Verlauf in Namen aufgelöst haben, zeigen stattdessen rohe SIDs an.

Weiterführende Lektüre: das Thema Vertrauensstellungen & Gesamtstruktur, der Grundlagenartikel zu Auditing und Erkennung für die Überwachungsrichtlinie hinter 4765 und 5136 sowie Attack Path Management, um versteckte Privilegien zusammen mit ACL-Pfaden zu verfolgen.