Ausgangslage: alte SIDs bleiben im Token

sIDHistory ist kein Fehler im Active Directory. Das Attribut wurde fuer Migrationsszenarien gebaut: Ein Benutzer, eine Gruppe oder ein Computer bekommt nach der Migration eine neue SID, traegt aber alte SIDs weiter im Token, damit Zugriffe auf nicht migrierte Ressourcen weiter funktionieren. Das ist waehrend 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 spaeter liegen alte SIDs noch auf produktiven Accounts, obwohl die Ursprungsdomain abgeschaltet wurde oder niemand mehr weiss, 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 koennen 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 loeschen. Das Ziel ist, Migrationsreste sichtbar zu machen, benoetigte Uebergangsrechte 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 geprueft.
  2. Jede SID hat einen erklaerten 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. Benoetigte Zugriffe werden nativ neu berechtigt. Alte SIDs bleiben nicht bestehen, nur weil niemand die ACLs anfassen will.
  5. Entfernung laeuft in Wellen. Erst Pilot, dann Fachbereich, dann breitere Bereinigung.
  6. Trusts und SID Filtering sind geprueft. Externe oder Forest-Trusts werden nicht als stiller Kompensationsmechanismus behandelt.
  7. Die Bereinigung ist reversibel geplant. Vorherige Werte, Change-Fenster, Tests und Rueckfallweg sind dokumentiert.

Der Zielzustand ist einfach: In einer abgeschlossenen Migration gibt es keine dauerhaft benoetigte SID History auf normalen produktiven Objekten. Wo sie noch benoetigt 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 pruefen. Gruppen und Computer koennen 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 gehoert nicht in ein ungeschuetztes Share. Sie enthaelt Identitaets- und Berechtigungsinformationen. Lege das Ergebnis in einem eingeschraenkten Projektordner ab und behandle es wie andere AD-Auditdaten.

Fuer 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 koennen. Eine rein alphabetische Bereinigung erzeugt Aufwand, aber nicht zwingend Risikoreduktion.

3) Migrationskontext und Trusts klaeren

Vor dem Entfernen muss klar sein, warum die SID ueberhaupt existiert. Fragen fuer 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 pruefen kann, ist das ein starkes Cleanup-Signal. Wenn die Quelle noch lebt, braucht die Entfernung einen engeren Testplan.

4) Zugriff nicht aus Bauchgefuehl bewerten

Der haeufigste 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,
  • benoetigte 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 noetig, weil Berechtigungen in Datenbanken, Rollenmodellen oder lokalen Konfigurationsdateien liegen koennen.

5) Pilot mit niedriger Blast-Radius waehlen

Beginne nicht mit Domain Admins und nicht mit einer grossen Fachbereichsgruppe. Ein brauchbarer Pilot hat:

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

Fuer 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 koennen.

6) Entfernung gezielt und mit Vorschau vorbereiten

Entferne nicht pauschal alle Werte aus allen Objekten. Arbeite pro Objekt und pro SID oder pro sauber gepruefter 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 koennen 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 gehoeren drei Checks dazu:

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

Pruefe zusaetzlich die fachlichen Zugriffe, Helpdesk-Tickets, Authentifizierungsereignisse und Applikationslogs. Ein leeres Attribut ist nur dann gut, wenn die benoetigten Zugriffe nun ueber aktuelle Gruppen funktionieren.

Fuer den Dauerbetrieb sollte sIDHistory in regelmaessigen AD-Health-Checks auftauchen. Neue Treffer nach abgeschlossener Migration sind erklaerungspflichtig.

8) In den Migrationsprozess einbauen

SID-History-Bereinigung ist kein einmaliger Hygienejob. Sie gehoert 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 fuer 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-Abhaengigkeiten: Historische Forest- oder Domain-Beziehungen verlieren Bedeutung fuer den Tagesbetrieb.

Nachteile und Grenzen

  • Hoher Analyseaufwand: Ohne Ressourceninventar und Owner ist die Entfernung riskant.
  • Altanwendungen koennen brechen: Manche Systeme pruefen noch gegen alte SIDs oder lokale Rollenmodelle.
  • Sessions aktualisieren sich nicht sofort: Bestehende Logons koennen alte Token weiterfuehren, bis sie erneuert werden.
  • Kein Ersatz fuer 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 Rueckbau noetig waere.

Typische Stolperfallen

  • Nur Benutzer pruefen: Gruppen und Computer koennen ebenfalls sIDHistory tragen.
  • Alles global loeschen: Pauschale Entfernung ohne Pilot erzeugt vermeidbare Betriebsrisiken.
  • Privilegierte Gruppen spaet anfassen: Gerade dort ist der Sicherheitsnutzen am groessten.
  • 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 koennen.
  • Keine Ausnahmen befristen: Dauerhafte Ausnahmeobjekte werden schnell wieder zum Normalzustand.
  • Keine Aufnahme in den Migrationsabschluss: Dann taucht dasselbe Problem bei der naechsten 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 benoetigte Zielberechtigungen pro Objektgruppe dokumentieren.
  • [ ] Alte ACLs auf Fileservern, Applikationen und Spezialplattformen identifizieren.
  • [ ] Pilotgruppe mit niedriger Blast-Radius auswaehlen.
  • [ ] Vorher-Werte eingeschraenkt sichern und Change-Fenster festlegen.
  • [ ] Entfernung mit -WhatIf vorbereiten und pro Objekt oder Welle ausfuehren.
  • [ ] Neue Logons, Kerberos-Tickets und fachliche Zugriffe testen.
  • [ ] Restobjekte und Ausnahmen mit Ablaufdatum fuehren.
  • [ ] SID-History-Pruefung in AD-Health-Checks und Migrationsabschluss aufnehmen.