Vorsicht beim SMB-Zugriff auf geklonte VMs/(PCs) unter Win11 Version (24H2)/25H2

[crogge]

Microsoft hat mit den neuen Patches für Windows 24H2 (Mit KB5065426 oder KB5068221?) sowie standardmäßig in Windows 25H2 diverse Änderungen am SMB-Protokoll vorgenommen. Dieses arbeitet nun sicherer und prüft unter anderem die SID der jeweiligen Windows Installation.

Problem:
Die SID bleibt identisch, wenn z. B. eine VM geklont wird, was bei uns auf einem ESXi-System beobachtet wurde. Während dies in der Vergangenheit kein Problem darstellte, treten seit dem neuen Update nun Zugriffsprobleme auf: VMs können nicht mehr gegenseitig über SMB aufeinander zugreifen. Der Zugriff wird verweigert und im Ereignisprotokoll erscheint der Fehler mit Event ID 6167 auf dem Ziel. Dies betrifft wohl auch den RDP-Zugriff (Bisher nicht getestet).

Fehlermeldung (6167):
"Es gibt eine teilweise Diskrepanz in der Maschinen-ID. Dies deutet darauf hin, dass das Ticket entweder manipuliert wurde oder zu einer anderen Boot-Sitzung gehört. Authentifizierung fehlgeschlagen."

Auf der Englischen VM: "There is a partial mismatch in the machine ID...".

Wichtig:
Der Zugriff auf andere Windows-Installationen funktioniert weiterhin problemlos, vorausgesetzt, die SID unterscheidet sich. Es spielt dabei keine Rolle, ob das SMB-Ziel auf Windows 10, Windows 11 oder Linux läuft.

Aktueller Stand:
Eine Lösung gibt es derzeit nicht. Die Änderung der SID ist zwar technisch möglich, mit den Windows eigenen Bordmitteln jedoch keine gute Idee, da sie mehr oder weniger einer Neuinstallation gleichkommt. Alternativ bleibt nur der Einsatz kostenpflichtiger Software wie SIDCHG.


Ich hoffe diese Info hilft jemandem, der auf ein ähnliches Problem stößt.

 

[Don_2020]

Lösung auf NFS wechseln.
SMB ist eh veraltert.

 

[mibbio]

Warum sollte SMB veraltet sein, zumal NFS sogar noch älter ist - NFS gibt es seit 1984 und SMB erst seit Windows 2000.
Veraltet sind höchstens SMBv1 und SMBv2, weil die nicht mehr als sicher gelten. Aber sowohl SMB als auch NFS werden noch weiterentwickelt. Bei SMB ist v3 der Stand der Technik (kam mit Windows 8) und mit Windows 10 wurde SMBv3.1.1 eingeführt.

Übrigens hat NFS auch einen Nachteil gegenüber SMB, nämlich die fehlende Nutzerauthentifizierung (kam erst mit NFSv4). Auch hat SMB seit v3 implizit eine Transportverschlüsselung, während NFS das erst seit v4.2 bietet und explizit konfiguriert/aktiviert werden muss (die meisten Systeme haben das nicht). Was auch der Grund ist, weshalb NFS potentiell schneller als SMB ist, denn es fällt meist die Transportverschlüsselung weg.

 

[Rego]

Das "Problem" mit der gleichen SID ist schon aus den 90ern bekannt. Geklonte Maschinen konnten in Domänen nicht sauber eingebunden werden, wenn man die SID nicht geändert hat.
https://www.andysblog.de/windows-probleme-mit-doppelter-sid-erkennen-und-beheben

Früher gab es von Sysinternals das Tool "NewSID". Mittlerweile muss man (offiziell) Sysprep verwenden.

Stellt sich grundsätzlich die Frage, warum man noch Images verteilt. Es gibt so gute, schnelle und einfach Möglichkeiten der PC Installation, bzw. der Softwareverteilung.

 

[AGB-Leser]

Interessant, danke für die Warnung. Das könnte mich ja auch betreffen. Leider hat SMBv3 den großen Vorteil, pro Übertragung mehrere Verbindungen zu öffnen, was das Kopieren drastisch beschleunigen kann

 

[Tamron]

Also das ist ja ein Admin Fehler und nicht der von MS. VMs dürfen nicht die gleiche SID haben und wenn man richtige Templates in VMware baut mit zusätzlicher Anpassungsspezifikationen, dann erstellt er ja auch automatisch eine neue SID.

 

[eRacoon]

Da wirst du von MS leider ein RTFM bekommen mit dem Hinweis auf Sysprep.
Wundert mich dass ihr nie Probleme hattet, gleiche IDs können gerade im Domänenumfeld zu diversen Problemen führen.