Wer IT-Infrastruktur für Augenoptiker betreut, könnte bald mit folgendem Problem konfrontiert werden:
Vor ein paar Monaten rief mich ein Kunde an, dass einer seiner Clients nicht mehr auf die winIPRO Datenbank zugreifen kann.
IPRO ist Marktführer im Bereich Branchensoftware für Augenoptik und Hörgeräteakustik.
Der Kunde – seines Zeichens Augenoptiker – greift über eine einfache SMB Verbindung vom Client auf den Server zu. Diese Verbindung konnte nun aber die Software nicht mehr aufbauen.
Allerdings nicht nur die Software. Auch ein Verbindungsversuch über den Windows Explorer wurde mit der Meldung „Benutzername oder Passwort falsch“ quittiert.
Da Benutzername und Passwort aber definitiv richtig waren, musste ein Netzwerkproblem vorliegen.
Auch eine RDP-Verbindung zum Server war nicht möglich. Ein Ping ging aber in beide Richtungen problemlos durch.
Zum Test die Firewall auf beiden Maschinen deaktiviert -> Fehler bleibt dennoch bestehen.
In einem Nebensatz erwähnt der Kunde, das der Client heute Windows Updates bekommen hatte.
Nach kurzer Recherche stellte sich heraus: KB5064081 wurde heute installiert.
Nach Deinstallation des Updates funktionierte auch der SMB Zugriff wieder wie gehabt.
Die Updates für fünf Wochen pausiert um Microsoft die Möglichkeit zu geben, den Fehler zu fixen und einen glücklichen Kunden mit dieser Lösung zurückgelassen.
Fürs erste…
Fünf Wochen später kam, was kommen musste: Der Fehler taucht wieder auf.
Also den Workaround wiederholt und nochmals die Windows Updates pausiert.
Dann war für ein paar Monate Ruhe.
Bis Microsoft das Feature Update für XXX ausrollte. Dieses enthielt den Fehler erneut.
Da sich ein Feature Update aber nicht einfach deinstallieren lässt, war jetzt die Zeit für Ursachenforschung gekommen. War es wirklich ein Fehler im Update oder war das Verhalten gewünscht? Und falls ja, warum hatte nur dieser eine Client Verbindungsprobleme?
Die Antwort gibt folgender Blogpost von Microsoft: https://support.microsoft.com/en-us/topic/kerberos-and-ntlm-authentication-failures-due-to-duplicate-sids-76f7394d-c460-4882-9ed1-d27e0960f949
Um Windows weiter abzuhärten, darf jede SecurityID (SID) nur einmal im Netzwerk vorhanden sein. Clients mit identischer SecurityID können nicht mehr miteinander kommunizieren.
Eine identische SID auf zwei Geräten kommt zustande, wenn das Gerät aus einem „golden Image“ geklont wird, ohne sysprep auf dem Zielgerät auszuführen. Das Zielgeräte ist in diesem Fall eine 1-zu-1 Kopie des Ausgangsgerätes. Und eben auch mit identischen IDs.
Vermutlich benutzt(e) IPRO diesen Klonmechanismus um die Endgeräte für ihre Kunden bereitzustellen.
Daher dürfte einige Optiker in nächster Zeit eben dieses Problem ereilen.
Es gibt allerdings zwei Lösungen für dieses Problem:
In beiden Fällen empfiehlt sich im Vorfeld ein Backup des gesamten Gerätes. Da hier tief ins System eingegriffen wird, besteht die reale Chance eines Datenverlustes
Lösung 1: Sysprep – Die von Microsoft vorgeschlagene Lösung.
sysprep /generalize
Dieser Befehl entfernt alle gerätespezifischen Informationen wie die SID, welche im Anschluss neu vergeben wird. Normalerweise wird sysprep bereits bei der Erstellung des golden Images verwendet, damit dieses bereits standardisiert ausgeliefert wird.
Lösung 2: Das Programm SIDCHG von Stratesave Systems
mit diesem Programm ist es möglich, die SID ohne Datenverlust zu ändern.
Die notwendige .exe kann einfach unter https://www.stratesave.com/html/downloads.html heruntergeladen werden. Innerhalb eines administrativen Prompts kann mit einem
sidchg64-3.0n.exe /R
die Änderung der SID gestartet werden. Der Schalter /R sorgt für einen Reboot nach Abschluss des Vorgangs. Den notwendigen Lizenzkey findet man ebenfalls auf der Seite von Stratesave unter https://www.stratesave.com/html/sidchg.html
Da der PC bei meinem Kunden schon länger in Verwendung war, habe ich mich für Option 2 entschieden. Nach einem Neustart konnte ich sowohl per Windows Explorer als auch per winIPRO wieder auf das Datenverzeichnis auf dem Server zugreifen.