Urban legend: Probleme mit geklonten SIDs

28. März 2017

Für jedes Windows-System wird eine einzigartige ID Nummer angelegt, die sogenannte Security Identifier (SID). Daher galt lange Zeit der Grundsatz: Mehrere Systeme mit identischen SIDs sollten die Systembetreuer im Netzwerk vermeiden. Laut Microsoft könnte es dabei zu unterschiedlichen Problemen kommen. Dies behalten umsichtige Administratoren besonders dann im Hinterkopf, wenn mehrere Systeme gleichzeitig mit einem frischen Windows-Betriebssystem (OS) versehen werden soll. Denn beim „Rollout“ kommt oftmals ein „Master-Image“ zum Einsatz.

Dieses Abbild einer Windows-Installation wurde meist auf einem System installiert, die benötigten Konfigurationsschritte ausgeführt, Anwendungssoftware installiert und das OS mit den benötigten Detailinformationen versehen. So müssen etwa bestimmte Drucker eingerichtet, Browser-Startseiten oder Links zum Intranet der Firma eingetragen werden. danach wird diese OS-Vorlage in der Regel mit dem Systemprogramm „Sysprep“ versiegelt, um unter anderen die SIDs, Benutzerkonten oder Hostmanen  zurückzusetzen.

Nach der Image-Erstellung spielen die Systembetreuer das Abbild auf die unterschiedlichen Systeme auf. Hier können neben manuellen Installationsvorgängen (etwa per DVD oder USB-Stick) auch Remote- und Management-Tools eingesetzt werden. Diese binden in der Regel PXE-Server (Preeboot Execution Enviroment) im Netzwerk ein. Falls allerdings bestimmte Gründe gegeneinen derartigen Einsatz von Sysprep sprechen, oder die SIDs von Windows-Systemen nachträglich geändert werden sollen, helfen Tools wie etwa „NewSID“ von Mark Russinovich, „Ghost Walker“ oder „SID Charger“ weiter. In der Vergangenheit wurden diese Tools meist empfohlen, um Betriebssystemklone nachträglich zu „behandeln“ und die SIDs zu verändern.

Inzwischen ist dies in der Regel nicht mehr nötig. Bei Systemen, die im Active Directory eingebunden werden, fällt das Problem mit den „doppelten“ SIDs nicht ins Gewicht. Denn hier kann Windows (meist) anhand des AD-Benutzernamens beispielsweise Berechtigungen genauere unterschieden. Ansonsten beschreibt Microsoft noch ein Problem, dass bei geklonten SIDs auftreten kann: Dabei kann es auf Systemen innerhalb einer Arbeitsgruppe zu Problemen bei der Berechtigung kommen, wenn Wechselspeichermedien – wie etwa USB-Sticks – auf einem der betroffenen Systemen formatiert werden, Daten darauf kopiert werden, und dieser Stick in einem anderen System mit identischer SID ausgelesen werden.

Denn Windows kann so nicht zwischen den „Besitzern“ der Daten unterscheiden, verlässt sich dabei auf die (geklonte und damit identische SID), und die Daten lassen sich somit auf anderen Systemen auslesen, obwohl dies nicht gewünscht ist. Dies trifft auch auf anderes Ressourcen innerhalb einer lokalen Windows-Arbeitsgruppe zu, etwa auf Netzlaufwerke oder Datei- und Druckserver. In den meisten Unternehmen dürften diese Sonderfälle in der Regel keine Rolle spielen, da hier meist auf das AD gesetzt wird. Nur bei kleineren Büros, Zweit- oder Drittstandorten, die noch mit einer Arbeitsgruppe „betrieben" werden, sollten die Administratoren dies im Hinterkopf behalten.

Geklonte SID? – kein Problem!

Auch von Microsoft selbst werden seit einigen Jahren keine Szenarien bekannt, bei denen identische SIDs tatsächlich zu Problemen geführt haben. Dagegen konnten bei einigen Windows-Installationen Softwarekomponenten Fehler verursachen, falls die SID nachträglich geändert wurden. Somit hat Microsoft inzwischen den Download des Sysinternal-Tools „NewSID“ gestrichen, und verlinkt auf eine entsprechende Zusammenfassung von Mark Russinovich. Somit sollten die Administratoren bei System-Images und Klonvorgängen auf die Empfehlung von Microsoft „hören“ und den Einsatz derartiger Tools besser unterlassen.

Sollten identische, geklonte SIDs den Systembetreuern Kopfzerbrechen verursachen, können sie den Windows-PC neu installieren, oder ein entsprechendes Image (das mit Sysprep neu versiegelt wurde) aufspielen. Auch bieten die meisten Backup- und Restore-Tools in der Regel die Option, SIDs beim Kopiervorgang zu ersetzen (etwa bei Acronis True Image). Besonders wenn dies in Verbindung mit einer hardwareunabhängigen Wiederherstellung (Universal Restore) durchgeführt wird, sollte dieser SID-Wechsel kein Problem darstellen. Schließlich tauschen derartige Restore-Tools auch gleich den kompletten HAL (Hardware Abstraction Layer) aus – stellt dieser Vorgang ja eine viel tiefgreifender Operation dar. Um die SIDs eines Windows-Systems anzuzeigen, können die Systembetreuer unterschiedliche Wege beschreiten. So ist es möglich, die SID mit Hilfe der Powershell auszulesen, allerdings nur falls diese mit Systemberechtigungen gestartet wurde (Administratorberechtigungen reichen nicht aus). Alternativ greifen die Administratoren zu einem weiteren Tool von Russinovich. Denn mit „Psgetsid

Fazit

Zusammenfassend lässt sich feststellen, dass eine nachträgliche Änderung der SID nicht notwendig ist. Bei Images, die mit Sysprep versiegelt wurden, werden automatisch bei der Erstkonfiguration neue SIDs erzeugt und zugewiesen. Bei Klonvorgängen ist dies in der Regel ebenfalls bedeutungslos. Denn die theoretischen Probleme, die bei identischen SIDs auftreten könnten, wurden in der Realität nicht beobachtet. Sollten die Systembetreuer hier ein „flaues“ Gefühl in der Magengegend verspüren, wählen sie beim Klonen eben die entsprechende Funktion im Backupprogramm, und setzen so beim Restore eine neue SID in das System ein. Somit lässt sich die Richtig klar vorgeben. Doppelt oder mehrfach vorhandene SIDs stellen kein Problem dar, besonders nicht in Umgebungen, die das AD einsetzen.

Florian Huttenloher

Lesen Sie auch