Ausgangslage: alte SIDs bleiben im Token

sIDHistory ist kein Fehler im Active Directory. Das Attribut wurde für Migrationsszenarien gebaut: Ein Benutzer, eine Gruppe oder ein Computer bekommt nach der Migration eine neue SID, trägt aber alte SIDs weiter im Token, damit Zugriffe auf nicht migrierte Ressourcen weiter funktionieren. Das ist während einer kontrollierten Domain- oder Forest-Migration praktisch und oft notwendig.

Das Problem beginnt nach der Migration. Alte Fileserver, Applikations-ACLs, Share-Berechtigungen und Gruppenmodelle werden nicht konsequent bereinigt. Jahre später liegen alte SIDs noch auf produktiven Accounts, obwohl die Ursprungsdomain abgeschaltet wurde oder niemand mehr weiß, welche Ressource diese SIDs angeblich noch braucht. Damit wird sIDHistory zu einem kaum sichtbaren Berechtigungsanker.

Sicherheitsseitig ist das relevant, weil Windows bei der Zugriffsbewertung nicht nur die aktuelle Objekt-SID betrachtet. SIDs aus sIDHistory können weiterhin Zugriff vermitteln. Besonders kritisch wird das bei privilegierten Konten, alten Trust-Beziehungen, historischen Migrationen mit breiten Berechtigungen und Umgebungen, in denen Berechtigungsmodelle nicht zentral dokumentiert sind.

Das Ziel ist nicht, sIDHistory blind zu löschen. Das Ziel ist, Migrationsreste sichtbar zu machen, benötigte Übergangsrechte sauber abzulösen und alte SIDs kontrolliert aus den Tokens zu entfernen.

Zielbild: SID History ist Ausnahme, nicht Dauerzustand

Ein belastbares Zielbild hat klare Eigenschaften:

  1. Alle Objekte mit sIDHistory sind bekannt. Benutzer, Gruppen und Computer werden nicht nur stichprobenartig geprüft.
  2. Jede SID hat einen erklärten Zweck. Es gibt Owner, Migrationskontext, betroffene Ressourcen und ein Ablaufdatum.
  3. Privilegierte Objekte sind priorisiert. Admins, Servicekonten, Gruppen mit Tier-0-Bezug und alte Migrationsgruppen werden zuerst bewertet.
  4. Benötigte Zugriffe werden nativ neu berechtigt. Alte SIDs bleiben nicht bestehen, nur weil niemand die ACLs anfassen will.
  5. Entfernung läuft in Wellen. Erst Pilot, dann Fachbereich, dann breitere Bereinigung.
  6. Trusts und SID Filtering sind geprüft. Externe oder Forest-Trusts werden nicht als stiller Kompensationsmechanismus behandelt.
  7. Die Bereinigung ist reversibel geplant. Vorherige Werte, Change-Fenster, Tests und Rückfallweg sind dokumentiert.

Der Zielzustand ist einfach: In einer abgeschlossenen Migration gibt es keine dauerhaft benötigte SID History auf normalen produktiven Objekten. Wo sie noch benötigt wird, ist sie eine dokumentierte Ausnahme mit Enddatum.

Umsetzung: erst beweisen, dann entfernen

1) Bestand read-only erfassen

Starte mit einer breiten, lesenden Abfrage. Es reicht nicht, nur Benutzer zu prüfen. Gruppen und Computer können ebenfalls betroffen sein.

Import-Module ActiveDirectory

Get-ADObject `
  -LDAPFilter '(sIDHistory=*)' `
  -Properties sIDHistory,objectClass,sAMAccountName,distinguishedName |
  Select-Object `
    objectClass,
    name,
    sAMAccountName,
    distinguishedName,
    @{Name = 'SIDHistory'; Expression = {
      ($_.sIDHistory | ForEach-Object { $_.Value }) -join ';'
    }}

Diese Ausgabe gehört nicht in ein ungeschütztes Share. Sie enthält Identitäts- und Berechtigungsinformationen. Lege das Ergebnis in einem eingeschränkten Projektordner ab und behandle es wie andere AD-Auditdaten.

Für die Priorisierung ist eine SID-Prefix-Sicht hilfreich. Der Domain-SID-Anteil zeigt, aus welcher alten Domain die SID wahrscheinlich stammt:

Get-ADObject `
  -LDAPFilter '(sIDHistory=*)' `
  -Properties sIDHistory,objectClass,sAMAccountName |
  ForEach-Object {
    $object = $_
    foreach ($sid in $object.sIDHistory) {
      [pscustomobject]@{
        ObjectClass     = $object.objectClass
        Name            = $object.Name
        SamAccountName  = $object.sAMAccountName
        DistinguishedName = $object.DistinguishedName
        SIDHistory      = $sid.Value
        SourceDomainSid = ($sid.Value -replace '-\d+$', '')
      }
    }
  }

2) Risiko statt Menge priorisieren

Viele Treffer bedeuten nicht automatisch hohes Risiko. Ein einzelnes privilegiertes Konto mit alter SID kann wichtiger sein als hunderte normale Benutzer aus einer alten Migration. Priorisiere:

  • Domain Admins, Enterprise Admins und delegierte Admin-Gruppen,
  • Servicekonten, die auf Servern, Tasks, IIS, SQL, Backup oder Middleware laufen,
  • Gruppen, die auf Fileservern oder Applikationen breit berechtigt sind,
  • Konten mit Tier-0-Zugriff oder Admin-Logon auf Management-Systemen,
  • deaktivierte, aber noch berechtigte Altobjekte,
  • Objekte mit mehreren alten SIDs aus mehreren Migrationen.

Setze zuerst dort an, wo alte SIDs privilegierte oder schwer nachvollziehbare Zugriffe vermitteln können. Eine rein alphabetische Bereinigung erzeugt Aufwand, aber nicht zwingend Risikoreduktion.

3) Migrationskontext und Trusts klären

Vor dem Entfernen muss klar sein, warum die SID überhaupt existiert. Fragen für jeden SID-Prefix:

  • Aus welcher Alt-Domain oder welchem Alt-Forest stammt der SID-Prefix?
  • Existiert die Quelle noch?
  • Gibt es noch Trusts, externe Ressourcen oder Archivsysteme?
  • Wurde SID Filtering auf Trusts bewertet?
  • Sind alte Fileserver, NAS-Systeme, SharePoint-Farmen oder Applikationen noch auf alte SIDs berechtigt?
  • Gibt es laufende Migrationswellen, die SID History noch brauchen?

Wenn die alte Domain bereits abgeschaltet ist und keine Ressource mehr auf diese SID prüfen kann, ist das ein starkes Cleanup-Signal. Wenn die Quelle noch lebt, braucht die Entfernung einen engeren Testplan.

4) Zugriff nicht aus Bauchgefühl bewerten

Der häufigste Fehler ist eine technische Entfernung ohne fachlichen Zugriffstest. Baue pro Objektgruppe eine kleine Matrix:

  • Objekt oder Gruppe mit sIDHistory,
  • alte SID und vermutete Quelle,
  • bekannte Ressourcen mit alten ACLs,
  • fachlicher Owner,
  • benötigte Zielberechtigung ohne SID History,
  • Testkonto oder Testgruppe,
  • Testdatum und Ergebnis,
  • Entscheidung: entfernen, migrieren, befristet behalten.

Bei Fileservern ist die Zielrichtung meist klar: Alte SID-ACEs aus ACLs entfernen und aktuelle Gruppen oder Rollen sauber berechtigen. Bei Applikationen ist mehr Vorsicht nötig, weil Berechtigungen in Datenbanken, Rollenmodellen oder lokalen Konfigurationsdateien liegen können.

5) Pilot mit niedriger Blast-Radius wählen

Beginne nicht mit Domain Admins und nicht mit einer großen Fachbereichsgruppe. Ein brauchbarer Pilot hat:

  • wenige Objekte,
  • klaren Owner,
  • bekannte Ressourcen,
  • reproduzierbare Zugriffstests,
  • kurzes Change-Fenster,
  • dokumentierte Vorher-Werte,
  • schnellen Rückfallweg.

Für die Vorher-Sicherung reicht am Anfang eine kontrollierte CSV-Ausgabe mit Distinguished Name und SID-Werten. Der Punkt ist nicht, ein Vollbackup von AD zu ersetzen. Der Punkt ist, dass die entfernten Werte nachvollziehbar bleiben und im Notfall gezielt bewertet werden können.

6) Entfernung gezielt und mit Vorschau vorbereiten

Entferne nicht pauschal alle Werte aus allen Objekten. Arbeite pro Objekt und pro SID oder pro sauber geprüfter Welle. Bei Benutzern sieht ein defensiver Start so aus:

$account = 'CN=Example User,OU=Users,DC=corp,DC=example'
$sidToRemove = 'S-1-5-21-0000000000-0000000000-0000000000-12345'

Set-ADUser `
  -Identity $account `
  -Remove @{ SIDHistory = $sidToRemove } `
  -WhatIf

Bei Gruppen oder Computern nutzt du entsprechend Set-ADGroup oder Set-ADComputer. Entscheidend ist der Ablauf: erst identifizieren, dann Testzugriff herstellen, dann -WhatIf, dann Change-Freigabe, dann produktive Entfernung im kleinen Scope.

Nach der Entfernung muss der Benutzer ein neues Logon-Token bekommen. Bestehende Sessions können alte Token weiter nutzen, bis sie neu angemeldet werden oder relevante Tickets ablaufen. Plane das in Tests und Change-Kommunikation ein.

7) Nachweis und Monitoring nachziehen

Nach jeder Welle gehören drei Checks dazu:

Get-ADObject `
  -LDAPFilter '(sIDHistory=*)' `
  -SearchBase 'OU=Pilot,DC=corp,DC=example' `
  -Properties sIDHistory |
  Select-Object name,objectClass,sIDHistory

Prüfe zusätzlich die fachlichen Zugriffe, Helpdesk-Tickets, Authentifizierungsereignisse und Applikationslogs. Ein leeres Attribut ist nur dann gut, wenn die benötigten Zugriffe nun über aktuelle Gruppen funktionieren.

Für den Dauerbetrieb sollte sIDHistory in regelmäßigen AD-Health-Checks auftauchen. Neue Treffer nach abgeschlossener Migration sind erklärungspflichtig.

8) In den Migrationsprozess einbauen

SID-History-Bereinigung ist kein einmaliger Hygienejob. Sie gehört in den Abschluss jeder Domain- und Forest-Migration:

  1. Migration mit begrenztem SID-History-Zweck planen.
  2. Alte ACLs parallel auf neue Gruppen migrieren.
  3. Applikations- und Fileserver-Zugriffe testen.
  4. sIDHistory pro Welle entfernen.
  5. Trusts und SID Filtering separat bewerten.
  6. Abschlussreport mit Restobjekten, Ausnahmen und Enddaten erstellen.

Wenn diese Schritte erst Jahre nach der Migration passieren, ist die Bereinigung deutlich schwerer. Trotzdem lohnt sie sich, weil sie alte, kaum sichtbare Berechtigungspfade aus AD-Tokens entfernt.

Vorteile

  • Weniger stille Berechtigungsanker: Alte SIDs vermitteln nicht mehr unbemerkt Zugriff.
  • Klarere Zugriffsbewertung: Berechtigungen liegen wieder auf aktuellen Gruppen, Rollen und Ressourcen.
  • Besseres Token-Hygiene: Tokens werden kleiner und leichter nachvollziehbar.
  • Starkes Signal für abgeschlossene Migrationen: Eine Migration gilt erst als abgeschlossen, wenn alte Zugriffsanker weg sind.
  • Bessere Auditierbarkeit: Owner, Quelle, Zweck und Entfernung werden sichtbar dokumentiert.
  • Reduzierte Trust-Abhängigkeiten: Historische Forest- oder Domain-Beziehungen verlieren Bedeutung für den Tagesbetrieb.

Nachteile und Grenzen

  • Hoher Analyseaufwand: Ohne Ressourceninventar und Owner ist die Entfernung riskant.
  • Altanwendungen können brechen: Manche Systeme prüfen noch gegen alte SIDs oder lokale Rollenmodelle.
  • Sessions aktualisieren sich nicht sofort: Bestehende Logons können alte Token weiterführen, bis sie erneuert werden.
  • Kein Ersatz für ACL-Cleanup: Wenn Ressourcen weiter alte SIDs in ACLs tragen, bleibt das Berechtigungsmodell unsauber.
  • Trust-Sicherheit braucht eigene Arbeit: SID History Cleanup ersetzt keine Bewertung von Trusts, SID Filtering und Admin-Grenzen.
  • Rollback ist nicht nur technisch: Selbst wenn Werte dokumentiert sind, muss fachlich klar sein, warum ein Rückbau nötig wäre.

Typische Stolperfallen

  • Nur Benutzer prüfen: Gruppen und Computer können ebenfalls sIDHistory tragen.
  • Alles global löschen: Pauschale Entfernung ohne Pilot erzeugt vermeidbare Betriebsrisiken.
  • Privilegierte Gruppen spät anfassen: Gerade dort ist der Sicherheitsnutzen am größten.
  • Keine neuen Logons testen: Zugriffstests mit alten Sessions liefern falsche Sicherheit.
  • Alte ACLs stehen lassen: Dann verschwindet zwar die SID History, aber nicht die technische Schuld auf Ressourcen.
  • Trusts ignorieren: Externe und Forest-Trusts beeinflussen, wie riskant alte SIDs noch sein können.
  • Keine Ausnahmen befristen: Dauerhafte Ausnahmeobjekte werden schnell wieder zum Normalzustand.
  • Keine Aufnahme in den Migrationsabschluss: Dann taucht dasselbe Problem bei der nächsten Migration erneut auf.

Projekt-Checkliste

  • [ ] Alle AD-Objekte mit sIDHistory per LDAP-Filter inventarisieren.
  • [ ] SID-Prefixe alten Domains, Forests oder Migrationswellen zuordnen.
  • [ ] Privilegierte Benutzer, Gruppen, Servicekonten und Computer priorisieren.
  • [ ] Trusts, SID Filtering und noch aktive Altressourcen bewerten.
  • [ ] Owner und benötigte Zielberechtigungen pro Objektgruppe dokumentieren.
  • [ ] Alte ACLs auf Fileservern, Applikationen und Spezialplattformen identifizieren.
  • [ ] Pilotgruppe mit niedriger Blast-Radius auswählen.
  • [ ] Vorher-Werte eingeschränkt sichern und Change-Fenster festlegen.
  • [ ] Entfernung mit -WhatIf vorbereiten und pro Objekt oder Welle ausführen.
  • [ ] Neue Logons, Kerberos-Tickets und fachliche Zugriffe testen.
  • [ ] Restobjekte und Ausnahmen mit Ablaufdatum führen.
  • [ ] SID-History-Prüfung in AD-Health-Checks und Migrationsabschluss aufnehmen.