Die Windows SID – und ein altes Problem

Die Windows SID wird bei der Installation von Windows erstellt. Diese SID existiert nur auf dem Computer. Das Computerobjekt im Active Director hat eine eigene SID. Diese Lokale SID soll es ermöglichen jedes Windows eindeutig zu identifizieren. Unteranderem wird Sie für den Microsoft Key Management Service (KMS) genutzt. Also 10 Geräte mit einer SID sind für den KMS nur 1 Gerät. Bevor sich jetzt Sparfüchse freuen, nicht immer klappt in einem solchen Fall die Aktivierung und im Falle einer Lizenzüberprüfung verlässt sich Microsoft nicht darauf.
Auch gibt es weitere Probleme mit doppelten SID. Zum Beispiel übernimmt der WSUS-Client die SID als „SusClientId“. Diese wird aber neu gewürfelt, wenn ich den Schlüssel lösche.
Auch andere Microsoft Dienste nutzen die SID und viel wichtiger: Der Betrieb von mehreren Geräten mit der gleichen SID ist nicht von Microsoft supportet. Im schlimmsten Fall bekomme ich keine Unterstützung bis ich das gelöst habe.
Wer noch mehr zu dem Problem erfahren möchte, dem empfehle ich den englischen Artikel „The Machine SID Duplication Myth (and Why Sysprep Matters)“ von Mark Russinovich.

Am einfachsten? Neuinstallieren.
Technisch kann auch ein Sysprep /generalize helfen, aber damit ist das auch eine „neue“ Maschine. Diese muss erneut in die Domäne aufgenommen werden, und….
Auch ist immer die Frage ob nach dem Sysprep noch alles 100% läuft. Hier bleibt auch ein Restrisiko für Seiteneffekte die dadurch verursacht werden, die aber nicht oder nur schwer darauf zurückzuführen sind.
Meine Empfehlung aus über 20 Jahren Microsoft: Neu machen, aber richtig. Statt klonen könnte MDT verwendet werden. Bei VMware gibt es beim Klonen eine extra Checkbox die das System „Generalisiert“ und somit eine neue SID erzeugt.

Das geht nicht über das Active Directory, auch wenn es einige Artikel (Hier ein Beispiel) gibt die es gerne meinen. Vielleicht meinen die aber auch eine andere SID, man weiß es nicht..
Gerne genannte Attribute sind:
SID: Das ist die SID des Computerobjektes, also die SID für das Gerät in der Domäne
ObjectGUID: Ist die GUID des Computerobjektes im AD
objectSid: Entspricht üblicherweise der SID
SIDHistory: Enthalt alte SID wenn das Objekt migriert wurde, zum Beispiel in eine andere Domäne
Technisch gesehen sind das, bis auf die GUID, auch SID’s, aber nicht die Windows SID. Hier sieht man die Domänen SID, prüfen kann man das, wenn man sich das mal für mehrere Computer anzeigen lässt.

In der Windows Registry sollte die Windows Sid im Hive HKEY_LOCAL_MACHINE\SECURITY\SAM\Domains\Account liegen, aber selbst als Administrator hat man keinen Zugriff.
Eine Möglichkeit wäre über Sysinternals PSExec als Systemaccount die Berechtigung zu ändern, aber davon rate ich entschieden ab.

Aber ein anderes SysInternal Tool kann helfen, PSGetsid, diese kann unter anderem die Windows SID auslesen. Dazu einfach das Programm starten, dann wird die lokale Windows SID ausgelesen.
Der Vorteil an PSGetsid ist auch, dass es über das Netzwerk die SID auslesen kann, dazu muss der Rechnername mit angegeben werden und das System erreichbar sein.

Jetzt ist das einzeln etwas aufwändiger zu prüfen, da muss es doch auch einfacher gehen? Ja, ich habe das Ganze in ein PowerShell Skript integriert. Basis war ein Projekt wo wir Probleme beim Prozess für das klonen von Servern hatten. Die einzeilige Variante ist recht einfach:
ForEach ($Computer in $(Get-ADComputer -Filter "Enabled -eq 'true'" -Properties name)) { Write-Host "$($Computer.name): $((& .\psgetsid64.exe \\$($Computer.name) -nobanner) | Select-String -Pattern "S-1-5-21-") "}