Kaputt: GPEdit und GPMC am Client - Stand 05.2026
Ich habe es Ende März bei MS Reserach eingekippt, aber ausser einer automatischen Antwort “Wir haben es erhalten, Danke schön” bis jetzt keine weitere Rückmeldung.
Submission number: VULN-180447, Case number: 111952
Ich kann es auf einem Windows 11 24H2 und 25H2 reproduzieren. Vielleicht möchte es jemand unter Windows 10 probieren und mir dann berichten.
Worum gehts?
Sowohl GPedit als auch die GPMC aus den RSAT Tools zeigen einen gravierenden Fehler auf einem Client OS. Der Fehler ist auf einem Server OS nicht vorhanden. Auf einem Server wird das DWord korrekt gesetzt.
Beschreibung, Reproduktion:
Es ist egal, welcher GPEditor zum Einsatz kommt. Der Fehler kann mit gpedit.msc am Client für die Lokale Gruppenrichtlinie oder nach Installation der RSAT Tools in der GPMC für Domänenweite Gruppenrichtlinien nachgestellt werden. Als Beispiel kann folgende Richtlinie dienen:
Delay Foreground download from http (in seconds)
Computer Configuration\ Administrative Templates\ Windows Components\ Delivery Optimization\
Vordergrunddownload von HTTP verzögern (in Sekunden)
Computer Configuration\ Administrative Templates\ Windows-Komponenten\ Übermittlungsoptimierung\
Als Wert muss “4294967295” dezimal eingetragen werden (FFFF FFFF). Der Wert reduziert sich auf “2147483647” (7FFF FFF).
Der Editor schreibt “2147483647” in das Richtlinien registry.pol file, das der Client bei Richtlinienübernahme importiert, obwohl das ADMx es anders definiert. Die Fehlermeldung behauptet sogar das “2147483647” der Maximalwert sei, was definitiv nicht stimmt.
<elements>
<decimal
id="DelayForegroundDownloadFromHttp"
maxValue="4294967295"
minValue="0"
valueName="DODelayForegroundDownloadFromHttp"
/>
</elements>
Es gibt über 50 Richtlinien mit dem MaxValue problem, verteilt über OS, Defender und Office Richtlinien.
- C:\Windows\PolicyDefinitions\appv.admx (1 Treffer)
- C:\Windows\PolicyDefinitions\DeliveryOptimization.admx (8 Treffer)
- C:\Windows\PolicyDefinitions\Netlogon.admx (2 Treffer)
- C:\Windows\PolicyDefinitions\office16.admx (1 Treffer)
- C:\Windows\PolicyDefinitions\OfflineFiles.admx (1 Treffer)
- C:\Windows\PolicyDefinitions\outlk16.admx (3 Treffer)
- C:\Windows\PolicyDefinitions\Power.admx (12 Treffer)
- C:\Windows\PolicyDefinitions\Printing2.admx (3 Treffer)
- C:\Windows\PolicyDefinitions\tcpip.admx (1 Treffer)
- C:\Windows\PolicyDefinitions\UserProfiles.admx (1 Treffer)
- C:\Windows\PolicyDefinitions\W32Time.admx (4 Treffer)
- C:\Windows\PolicyDefinitions\WindowsDefender.admx (14 Treffer)
- C:\Windows\PolicyDefinitions\WindowsFileProtection.admx (1 Treffer)
Richtig kaputt geht es dann aber, wenn man die Security Channel / SCHANNEL Einstellungen aus den SecurityProviders per ADMx festzurrt.
Ich nutze seit Jahren:
https://github.com/Crosse/SchannelGroupPolicy
C:\Windows\PolicyDefinitions\schannel.admx (20 Treffer)
Unter HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\* liegen diverse Unter-Keys für Cipher, CipherSuites, Hashes, KeyExchangeAlgorithms etc. diese haben bei "Enabled" = 4294967295 als RegDword und bei Disabled = 0
SHA256-512, Diffie-Hellman und Protocols, wie PKCS. Viele von denen werden per "FFFF FFFF" (4294967295) aktiviert.
Der GPEditor (gpedit und gpmc) auf Windows 11 behandelt das REG_DWORD falsch und erstellt ein Dez:2147483647, Hex:7FFFFFFF, statt Dez:4294967295, Hex:0xFFFFFFFF
Die klassische Empfehlung ein Workstation OS als PAW zum editieren von Gruppenrichtlinien, Active Directory etc kann Fehler und eine Misskonfiguration verursachen. Das ist jetzt schon der 3te mir bekannte grosse Bug in der Gruppenrichtlinienveraltung/Konsole auf einem Client OS.[1]
Wie schon gesagt, die GPMC auf dem Server macht es richtig. Somit sind die Editoren, der Parser des ADMx oder was auch immer nicht identisch auf den beiden Systemem.
Funfact:
erstellt und editiert man die Richtlinie am ServerOS, dann wird der Wert richtig eingetragen und am CLient importiert. Soweit alles logisch.
Erstellt man dann einen HTML Report der Richtlinienübernahme per "gpresult /h test.html /f", dann werden diese Werte als "Zusätzl. Reg.-Einst." deklariert, da der Client die "4294967295" nicht auflösen kann und VICE VERSA!
Erstellt man die Richtlinie am Client, dann meckert der HTML Report am Server über "2147483647", womit er dann total richtlg liegt.
Bei Thema SCHANNEL ergibt sich jetzt das Problem, die Richtlinien haben keinen "MaxValue", sondern definieren schlicht AN (aktiviert) /AUS (deaktiviert)
<enabledValue>
decimal value="4294967295"
</enabledValue>
Bei Aktiviert im Editor erscheint KEINE! Fehlermeldung, diese kommt nur bei einem Eingabe-/Auswahlfenster.
Warum ist das kritisch?
Die kontrollierte Komponente ist schlicht nicht kontrolliert. Es gibt einen Grund, warum der Entwickler “FFFF FFFF”, alle Bits auf “an” definiert hat, um diese zu aktivieren. Im Falle von 7FFF FFFF sind aber nicht alle Schalter auf “an” und somit ist die Komponente wahrscheinlich nicht aktiv. MAn stelle sich vor, im Falle der SCHANNEL Konfiguration, werden alle alten Dinge deaktiviert. Der Wert wird auf “0" gesetzt, das funktioniert einwandfrei. Ihr möchtet aber SHA256,384,512 aktivieren. Das fliegt euch jetzt u.U. um die Ohren.
Lösungmöglichkeiten:
- Der zu setzende Registry Wert muss im Falle einer Domänen Richtlinie per Powershell in die GPO geschrieben werden (Set-GPRegistryValue)
- Der zu setzende Registry Wert muss im Falle einer Domänen Richtlinie per Group Policy Preference gesetzt werden
- Ihr verwendet ein Server OS mit GPMC zum editieren der Domänen Richtlinie
- Der zu setzende Registry Wert wird per LGPO.exe aus dem Microsoft Security Compliance Toolkit 1.0 in die Lokale Richtlinie geschrieben.
- Ihr ignoriert den Fehler, weil er exotisch ist und nicht alle betrifft :-)
[1]
Weitere Bugs, die Fehlkonfigurationen verursachten: Es wurden andere Zeiten, 1 Stunde plus für Geplante Tasks der Group Policy Preferences am Client erzeugt. Unter “Zuweisen von Benutzerrechten” aus den Sicherheitsoptionen wurde der Name eines Benutzers oder einer Gruppe eingetragen, anstelle der SID (gpttmpl.inf). Was in einem mehrsprachigem System lustig war, da sich “Administratoren” dann nicht mehr anmelden durften, da es nur “Administrators” erlaubt ist. Ein Königreich für Wellknown-SIDs!