[English]Microsoft hat zum 21. Oktober 2025 zu einem Problem im Umfeld der NTLM-/Kerberos-Authentifizierung Stellung genommen. In diesen Betriebssystemen kommt es zu Authentifizierungsfehlern, wenn SIDs auf mehreren Rechnern gleich und bestimmten Updates von August oder September 2025 installiert sind. Ein Problem, welches beim Clonen von Installationsabbildern auftauchen kann.
Admin-Passwörter schützen mit Windows LAPS. eBook jetzt herunterladen » (Anzeige)
Die SID (steht für Security ID) ist ein eindeutiger Sicherheits-Identifikator, den Microsoft Windows automatisch vergibt. Zweck ist es, jedes System, jeden Benutzer und jede Gruppe dauerhaft zu identifizieren. Hier im Blog gibt es mit diesem Kommentar eine umfangreichere Diskussion, ob SID-Duplikate im gleichen Netzwerk ein Problem sein können. Und auch in diesem Kommentar spielen doppelte SIDs im Netzwerk eine Rolle. Das lässt sich verhindern, indem nach dem Clonen einer Windows-Installation ein Sysprep durchgeführt wird. So viel als Vorbemerkung, auch wenn die nachfolgenden Ausführungen ein Problem im Zusammenhang mit Windows-Updates von August oder September 2025 ansprechen.
Kerberos/NTLM-Authentifizierungsprobleme durch SIDs
Microsoft hat zum 21. Oktober 2025 den Supportbeitrag Kerberos and NTLM authentication failures due to duplicate SIDs (via) veröffentlicht, der sich mit den Folgen von SID-Duplikaten auseinandersetzt. Im Beitrag heißt es, dass bei Geräten mit doppelten Sicherheits-IDs (SIDs) Fehler bei der Kerberos- und NTLM-Authentifizierung auftreten können. Dieses Problem tritt auf, wenn in Windows 11 24H2 und 25H2 sowie in Windows Server 2025 folgende Windows-Updates installiert sind:
- August 29, 2025—KB5064081 (OS Build 26100.5074) Preview
- September 9, 2025—KB5065426 (OS Build 26100.6584)
Bei betroffenen Systemen äußern die Authentifizierungsfehler sich folgendermaßen:
- Benutzer werden wiederholt zur Eingabe ihrer Anmeldedaten aufgefordert.
- Zugriffsanfragen mit gültigen Anmeldedaten schlagen mit folgenden Fehlermeldungen auf dem Bildschirm fehl:
- Anmeldeversuch fehlgeschlagen
- Die Maschinen-ID stimmt teilweise nicht überein
- Der Benutzername oder das Passwort ist falsch
- Auf freigegebene Netzwerkordner kann nicht über die IP-Adresse oder den Hostnamen zugegriffen werden.
- Remotedesktopverbindungen können nicht hergestellt werden, einschließlich RDP-Sitzungen (Remote Desktop Protocol), die über PAM-Lösungen (Privileged Access Management) oder Tools von Drittanbietern initiiert wurden.
- Failover-Clustering schlägt mit der Fehlermeldung "Zugriff verweigert" fehl.
- Die Ereignisanzeige zeigt möglicherweise einen der folgenden Fehler in den Windows-Protokollen an:
- Das Sicherheitsprotokoll enthält den Fehler SEC_E_NO_CREDENTIALS.
- Das Systemprotokoll enthält die Ereignis-ID 6167 des Local Security Authority Server Service (lsasrv.dll) mit dem Meldungstext: There is a partial mismatch in the machine ID. This indicates that the ticket has either been manipulated or it belongs to a different boot session.
Hintergrund ist, dass die Windows-Updates, die am oder nach dem 29. August 2025 veröffentlicht wurden, zusätzliche Sicherheitsmaßnahmen enthalten, die SID-Prüfungen erzwingen. Dadurch schlägt die Authentifizierung bei NTLM und Kerberos fehl, sobald Geräte doppelte SIDs haben. Diese Designänderung blockiert Authentifizierungs-Handshakes zwischen solchen Geräten.
Fehlgeschlagene Authentifizierungsanfragen im Zusammenhang mit diesen Sicherheitsmaßnahmen werden durch die Ereignis-ID 6167 des Local Security Authority Server Service (lsasrv.dll) im Systemereignisprotokoll identifiziert.
Diese doppelten SIDs können in Installationen entstehen, wenn eine nicht unterstützte Klonung oder Duplizierung einer Windows-Installation ohne Ausführung von Sysprep durchgeführt wird. Die durch Sysprep aktivierte SID-Eindeutigkeit ist für die Betriebssystemduplizierung unter Windows 11, Versionen 24H2 und 25H2, sowie Windows Server 2025 nach der Installation von Windows-Updates ab dem 29. August 2025 zwingend erforderlich (siehe The Microsoft policy for disk duplication of Windows installations).
Eine Lösung des obigen Problems erfordert, dass Administratoren die betroffenen Maschinen mit einer neuen SID aufsetzen. IT-Administratoren können dieses Problem vorübergehend beheben, indem sie eine spezielle Gruppenrichtlinie installieren und konfigurieren (die wohl die erwähnte Prüfung außer Kraft setzen). Um diese spezielle Gruppenrichtlinie zu erhalten, wenden Sie sich bitte an den Microsoft-Support für Unternehmen.
MVP: 2013 – 2016
Gab es jemals eine andere Empfehlung als das die SID nicht identisch sein sollte ? Das gab doch schon immer irgendwelche merkwürdigen Seiten effekte.
Stellte sich damals als unnötig heraus: https://learn.microsoft.com/de-de/sysinternals/downloads/newsid . Das sie es jetzt wieder forcieren ist schon sehr nervig. Hatte letztens erst zwei Rechner die gegenseitig nicht auf die Freigaben konnten (ohne Domäne). Mit Sidchg gings dann https://www.andysblog.de/sidchg-windows-eine-neue-sid-ohne-sysprep-vergeben .
bissl teuer, wenn ich einmalig eine einzige sid ändern will
Die 30-Tage-Testversion ist kostenlos und meistens ändert man die SID ja nur einmal pro PC ;-) .
https://www.stratesave.com/html/sidchg.html
Keys werden jeden Monat neu ausgewürfelt.
+1 Danke!
+ Betr. "Stellte sich damals als unnötig heraus:":
Was, was, was? Das Gegenteil ist der Fall, lese Deine Quellen bevor Du sie angibst. Dort steht glasklar: "The SID Duplication Problem. The problem with cloning is that it is only supported by Microsoft in a very limited sense.".
+ Betr. "Das sie es jetzt wieder forcieren ist schon sehr nervig.":
Was soll das? Wer forciert hier was womit?
+ Betr. "Hatte letztens erst zwei Rechner die gegenseitig nicht auf die Freigaben konnten (ohne Domäne).":
Ach ne, und das überrascht Dich? Du musst die Quellen, die Du angibst, schon lesen. Dort steht unmissverständlich: "Thus, if two computers have users with the same SID, the Workgroup will not be able to distinguish between the users."
Gut, dass EDV nur Dein Hobby ist.
Für einen Domainjoin oder gegenseitigen Zugriff war das nie von Belang, Mark Russinovich sprach damals von Wsus:
The New Best Practice
It's a little surprising that the SID duplication issue has gone unquestioned for so long, but everyone has assumed that someone else knew exactly why it was a problem. To my chagrin, NewSID has never really done anything useful and there's no reason to miss it now that it's retired. Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so Microsoft's support policy will still require cloned systems to be made unique with Sysprep.
Jetzt wird die SID geprüft, das meinte ich mit "forciert". Was mich nervt ist die fehlende Kommunikation seitens MS. Einfach mal machen und schauen was passiert. Vielleicht gibt es aber auch irgendeine schlaue Seite die ich noch nicht kenne wo das alles mit Roadmap schön aufgeschlüsselt ist.
Das hat mich schon überascht, da es bis jetzt immer ging da sich die Computer eben durch den Computernamen als der SID gegenseitig unterschieden (ist ja auch der Grund warum Günter hier das eingestellt hat, oder?).
Komm, lass das oder bist du der Zweitaccount von TJ oder Luzifer?
WSUS bzw der SUSClient generiert pro PC die SUSID die auch sysprep nicht ändert, da reichts es aber den Registrykey dafür zu löschen und es wird eine neue SUSID generiert.
Wer duplicate SIDs als kein Problem bezeichnet hat den Schuß aber schon vor mehr als 20 Jahren nicht gehört. Wie schon andere in anderen Foren schrieben wundert es mich, dass es so lange immer irgendwie doch funktioniert hat.
SIDCHG64 hat bei mir geholfen. Vielen Dank für diesen Tipp.
Ja früher.
Bei einem Domain-Joins sollte aber spätestens eine neue SID generiert werden.
Oder Clont jemand etwa Domain Joint Devices….
Bei einem Domain Join wird keine neue SID erstellt.
Die SID ist ja Teil von allen ACLs im System.
Betr. "Bei einem Domain Join wird keine neue SID erstellt."
Da blickt aber einer durch, Ironie aus.
Zutreffend ist vielmehr, aus Svidergol/Allen: Active Directory Cookbook, 4th ed. (2013), O' Reilly, S. 51:
"All security principals in Active Directory have an SID, which is used to uniquely identify the object in the Windows security system. There are two parts of an SID: the domain identifier and the RID. Domain controllers are allocated a RID pool from the RID FSMO for the domain. When a new security principal (user, group, or computer) is created, the domain controller takes an RID from its pool to generate an SID for the account."
Das gilt nur für Objekte im AD. Diese bekommen eine ID welche sich vom AD ableitet.
Das hat aber nichts mit der SID des Systems zu tun.
In einer Domain bekommt jedes Objekt im AD eine ID die besteht aus SID der Domain und RID die ID des Objektes selbst.
.
Wie man aber vielleicht weiß, hat ein Domain gejointer Rechner immer noch auch lokale User
Die wiederum bekommen nach dem gleichen Schema ihre ID.. also SID des Rechners + RID des lokalen Benutzers.
Das betrifft aber nicht nur Cloned devices. Seit august haben wir das Phänomen auch bei uns das sporadisch sich Nutzer melden mit dem Kommentar das ihr Kennwort als falsch deklariert wird. Auf den TS geht es dann. Wir werfen die Geräte dann einmal aus der Domänen wieder rein danach geht es wieder.
Bei uns ebenso, sporadisch.
Habt ihr verschiedene DC's mit unterschiedlichen Serverversionen? 2022 und 2025? Hab meine 2025 DC's wieder rausgeworfen. Seit dem Ruhe.
Es gab einen 2025 DC welcher seit ca. 3 Wochen entfernt wurde und trotzdem noch sporadisch das Verhalten auftritt.
Kennt jemand jemanden, der den MS-Support um die ADMX/ADML gebeten hat?
es heißt:
Um diese spezielle Gruppenrichtlinie zu erhalten, wenden Sie sich bitte an den Microsoft-Support für Unternehmen.
Ich denke,es geht um HKEY_LOCAL_MACHINE\SYSTEM\currentcontrolset\control\lsa\msv1_0\BlockNtlmv1SSO, siehe https://windowsforum.com/threads/preventing-duplicate-sid-kerberos-ntlm-failures-after-windows-updates.385702/
Die 90er haben angerufen und wollen ihr Sysprep zurück?
Das ist ja wie bei Mode und Musik, irgendwann kommt alles wieder, besser wird es dadurch aber auch nicht ;-)
Sysprep war nie weg! Selbst wenn du über Citrix oder VMWare eine VM oder Citrrix-Terminalserver cloned, wird das automatisch mit Sysprep behandelt, damit der Clone eine neue SID bekommt.
Ich verstehe nicht, wie man im Jahre 42 nach Einführung des Windows-Domäenen-Konzepts von Windows NT 3.x das Syspreppen noch vergessen kann!
Das sind Grundlagen unseres Handwerks!
Mir ist das klar :-), nur anscheinend einigen anderen da draußen nicht ;-).
Ich bin eh generell davon weg Systemimages zum Clonen zu verteilen.
Das Masterimage ist mit Erstellung im heuten Updatewahnsinn quasi schon veraltet, da kann man besser das Betriebssystem sauber neu installieren und die Software aktuell per Deploy Tool verteilen.
Evtl. sollte man am Updatewahnsinn arbeiten…
Hallo Zusammen,
ich konnte das Problem mit dem SIDCHG SID changer tool von https://www.stratesave.com/html/downloads.html beheben. Nachdem der ursprünglich mal geklonte Rechner eine neue SID erhalten hat, klappt der Netzwerkzugriff wieder. [GB: Korrektur durch den Leser:]Dabei ist noch zu sagen, dass das Problem nur zwischen den Maschinen bestand, welche dieselbe SID hatten (Vorlage VM und Klon VM), dies wurde mit psGetsid.exe nachvollzogen.
Beim Versuch per Netzwerk \\Computername\freigabe zuzugreifen erschien immer die Anforderung der Zugangsdaten. Diese schlug fehl mit der Meldung "Das angegebene Netzwerkkennwort ist falsch"
Am Remoterechner erschien diese Meldung unter Windows-Protokolle | Sicherheit:
Ereignis-ID: 4625
Fehler beim Anmelden eines Kontos.
Antragsteller:
Sicherheits-ID: NULL SID
Kontoname: –
Kontodomäne: –
Anmelde-ID: 0x0
Anmeldetyp: 3
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: administrator
Kontodomäne: ACME.LOCAL
Fehlerinformationen:
Fehlerursache: Bei der Anmeldung ist ein Fehler aufgetreten.
Status: 0xC000006D
Unterstatus:: 0x0
Prozessinformationen:
Aufrufprozess-ID: 0x0
Aufrufprozessname: –
Netzwerkinformationen:
Arbeitsstationsname: –
Quellnetzwerkadresse: 192.168.10.71
Quellport: 58134
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: Kerberos
Authentifizierungspaket: Kerberos
Übertragene Dienste: –
Paketname (nur NTLM): –
Schlüssellänge: 0
Früher gab's von sysinternals mal NewSID.
Geht das nicht mehr?
Mark Russinovich hat schon vor einigen Jahren "NewSID" als deprecated angegeben, seither findet keine Pflege bzw. Weiterentwicklung mehr statt. Man kann es aber nach wie vor auf eigene Gefahr bei z. B. Chip
https://www.chip.de/downloads/NewSID_21127671.html
herunterladen und nutzen, sollte allerdings die Infos vom Microsoft bzw. Mark dazu berücksichtigen.
https://learn.microsoft.com/de-de/sysinternals/downloads/newsid
Die GPO setzt folgenden RegKey:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides]
"1517186191"=dword:00000000
Damit wird das KB5065426 ausser Kraft gesetzt