Noch ein kleiner Nachtrag von dieser Woche zu einem Thema um Umfeld des Januar 2026-Patchday. Microsoft schränkt aus Sicherheitsgründen die Funktionalität des Windows Deployment Services (WDS) ein. Die Unterstützung einer unattended.xml zur Windows-Installation von Netzlaufwerken endet ab April 2026.
WDS über unattend.xml
Die Windows Deployment Services, kurz WDS (engl. Windows Bereitstellungsdienste) ermöglichen die automatisierte Bereitstellung (Installation) von Windows-Installationen. Administratoren können WDS verwenden, um neue Windows-Clients mit einer netzwerkbasierten Installation einzurichten.
Dies erspart Administratoren Windows auf jedem Computer mittels DVD- oder USB-Medien installieren müssen. Die Steuerung der Installationsmethode erfolgt dabei über eine Steuer- bzw. Antwortdatei unattended.xml, die die entsprechenden Vorgaben zur Installation enthält. Ich hatte im September 2025 im Beitrag Windows 11 24H2: Sicherheitsproblem durch unattend.xml? über das Thema und über Sicherheitsrisiken geschrieben.
Änderung bei WDS angekündigt
In den Supportartikeln der Updates zum Patchday am 13. Januar 2026 findet sich (z.B. bei Update KB5074109 für Windows 11 24H2-25H2) der Passus, dass das bei den Windows-Bereitstellungsdiensten eine Änderung eingeführt werden.
Obiger Screenshot zeigt die deutschsprachige Fassung – die nette Umschreibung der "Freisprechbereitstellungsfunktionen" entspricht dem englischen "hands-free deployment" – also der automatischen Bereitstellung per Antwortdatei, d.h. ohne Administratoreingriff bei der Installation.
WDS-Einschränkung aus Sicherheitsgründen
Die Verwendung einer unattended.xml-Antwortdatei von einer Netzwerkfreigabe stellt ein Sicherheitsrisiko dar, das zum 13. Januar 2026 unter CVE-2026-0386: Windows Deployment Services Remote Code Execution Vulnerability beschrieben wurde. Eine unsachgemäße Zugriffskontrolle in den Windows-Bereitstellungsdiensten ermöglicht es einem nicht autorisierten Angreifer, Code über ein erreichbares Netzwerk auszuführen.
Der WDS-Workflow überträgt die Datei unattend.xml über nicht authentifiziertes RPC . Dadurch werden sensible Anmeldeinformationen während des PXE-Starts preisgegeben. Dies stellt ein Sicherheitsrisiko beispielsweise durch potenzieller Man-in-the-Middle-Angriffe (MITM) dar.
Um die Sicherheit zu erhöhen, erzwingt Microsoft standardmäßig authentifiziertes RPC und entfernt den unsicheren WDS-Workflow. Die Details sind im Supportbeitrag Windows Deployment Services (WDS) Hands‑Free Deployment Hardening Guidance beschrieben.
- Phase 1 (13. Januar 2026): Die "hands-free" Bereitstellung wird weiterhin unterstützt und kann zur Erhöhung der Sicherheit explizit deaktiviert werden. Aber es werden Ereignisprotokollwarnungen eingeführt. Und ein Registry-Schlüssel mit Optionen zur Auswahl des sicheren oder unsicheren Modus ist nach Installation des Januar 2026-Updates verfügbar.
- Phase 2 (April 2026): Die "hands-free" Bereitstellung ist standardmäßig deaktiviert, kann jedoch bei Bedarf unter Berücksichtigung der damit verbundenen Sicherheitsrisiken wieder aktiviert werden. Das Standardverhalten ändert sich zu "standardmäßig sicher".
Die Umstellung auf Phase 2 erfolgt wohl zum 14. April 2026 mit einem Sicherheitsupdate. Der Modus findet sich im Registrierungsschlüssel:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WdsServer\Providers\WdsImgSrv\Unattend
wo der 32-Bit-DWORD-Wert AllowHandsFreeFunctionality das Verhalten steuert. Der Wert 0x0 sperrt den nicht authentifizierten Zugriff auf die unattend.xml und damit die hands-free-Bereitstellung. Mit dem Wert 0x1 kann ab April 2026 die hands-free-Bereitstellung von Administratoren bei Bedarf wieder aktiviert werden.
Mit den Sicherheitsupdates von Januar 2026 wurden neue Ereignisse in Windows hinzugefügt, um Administratoren bei der Überwachung des Bereitstellungsverhaltens zu unterstützen. Die Ereignisse werden im Protokoll "Microsoft-Windows-Deployment-Services-Diagnostics/Debug" protokolliert. Details finden sich im Supportbeitrag Windows Deployment Services (WDS) Hands‑Free Deployment Hardening Guidance.
MVP: 2013 – 2016
der Administrator ist doch dafür verantwortlich den Share abzusichern, seit wann kümmert sich M$ um Sachen die sein könnten?
Finde die Argumentation aufgrund von Sicherheit hanebüchen
Es geht nicht um die Berechtigung auf deiner Share. es ist die Art, wie die boot.wim über PXE die unattended.xml abholt.
Hier kann es zu einem MitM kommen.
du kannst es als Admin, mit ordentlicher Administration (Rechte Vergabe) nicht verhindern
Es handelt sich dabei ja nur um eine elementar notwendige Funktion zum automatisierten installieren von Windows. Wäre halt schön wenn man, statt einfach nur was zu deaktivieren, auch eine alternative Funktion zur Verfügung stellen würde die sicher genutzt werden kann.
Keine Ahnung wie WDS das steuert, für die Bereitstellung über unser PXE Tool gibt es ein eigenen ReadOnly User der nur auf das eine Verzeichnis zugreifen darf wo die Installationsdateien liegen. Also selbst wenn die Credentials abgegriffen werden, könnte man mit dem User nichts machen, außer die Installationsdaten aufrufen. Man kann keine Dateien austauschen oder ändern. Und der lokale "Admin" Benutzer in der unattend.xml hinterlegt ist, ist nur ein temporärer Admin der auf allen PCs nach dem Domainbeitritt gelöscht wird, also auch diese Information wäre keine Angriffsfläche.
ich komme hier nicht klar …
es geht doch w11 24h2 sowie so nicht per WDS (ohne Tricks):
https://learn.microsoft.com/en-us/windows/deployment/wds-boot-support
hier wird also was abgeschalteter was eh abgeschaltet ist ?
es soll halt auch was verkauft werden.
die haben als vorbereitung dazu die boot.wim auf den win11 datenträgern verknüppelt und man kann zur zeit ausweichsweise die variante von win10 benutzen.
mal gucken was noch kommt in der sache.
Das Übel dürfte hier doch eindeutig das SMB-Share sein. Solange MS das nicht wie der Rest der Welt mit TLS absichert und Cert auch prüft, sehe ich nicht, wie man das MitM Problem lösen könnte. Die .XML ist doch da nur noch das i-Tüpfelchen. Jeder Samba mit "All-Auth-Allow" kann einem da was unterschieben sobald der DNS/Netbios Name manipuliert ist.