jlaufenburg
Goto Top

Default Domain Policy kann nicht mehr bearbeitet werden

Hallo Zusammen,
vielleicht kann mir jemand weiter Helfen.

Ich habe das Problem, dass ich in der Gruppenrichtlinien Verwaltung die Default Domain Policy nicht mehr bearbeiten kann.
Fehler: Auf das Gruppenrichtlinienobjekt kann nicht zugegriffen werden, weil Sie keine Leserechte darauf haben.

Ansonsten Funktioniert die Default Domain Policy aber und wird auch von allen Clients gezogen und Angewendet.
Gpresult sagt Angewendete Gruppenrichtlinienobjekte.
Name: Default Domain Policy
Verknüpfungsstandort: dug.local
Revivion: AD (5), Sysvol (5)

Benutzerrechte auf die Policy im Sysvol sind passend.
Dieses wurde bereits vom MS Support gescheckt.
Wir haben hier auch schon ein Ticket Offen, sind aber bisher noch nicht weiter gekommen.
Zurücksetzten ist laut MS Kritisch, da wir Exchange in unserem unternehmen einsetzten.

Hoffe jemand hat eine Idee.

Beste Grüße
Jörg

Content-ID: 259342

Url: https://administrator.de/contentid/259342

Ausgedruckt am: 22.11.2024 um 22:11 Uhr

DerWoWusste
DerWoWusste 09.01.2015 aktualisiert um 15:49:55 Uhr
Goto Top
Hi.

Ändere die Zugriffsrechte auf den Ordner der Policy und alle Unterodner+Dateien:
\\DeinDC\SYSVOL\\DeineDom.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}

({31B2...} ist der Identifier für jene Policy, er ist für die DDP immer gleich)
jlaufenburg
jlaufenburg 09.01.2015 um 16:25:34 Uhr
Goto Top
Hi DerWoWusste,
der Support von MS hat das schon gescheckt.
Die Rechte sind alle passend gesetzt.

Gruß
Jörg
DerWoWusste
Lösung DerWoWusste 09.01.2015, aktualisiert am 13.01.2015 um 11:45:31 Uhr
Goto Top
Das bezweifle ich. Dieser Fehler ist altbekannt, er kommt dann vor, wenn Admins verhindern wollen, dass die DDP von bestimmten Rechnern/Usern übernommen wird und dafür Verweigerungen setzen. Genau dann passiert das.
Ich gebe deshalb mal die korrekten ACLs wieder (mittels icacls auf Policies\{31B2F34...):
CREATOR OWNER:(OI)(CI)(IO)(F)

NT AUTHORITY\Authenticated Users:(OI)(CI)(RX)

NT AUTHORITY\SYSTEM:(OI)(CI)(F)

domain\Domänen-Admins:(OI)(CI)(F)

domain\Organisations-Admins:(OI)(CI)(F)

NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)(RX)
Vergleich das bitte mal.
jlaufenburg
jlaufenburg 09.01.2015 um 16:51:52 Uhr
Goto Top
Hi,
werde ich machen.

Kannst du mir einmal die Syntax geben die du beim icacls angegeben hast, dann poste ich das Ergebnis.

Danke und Gruß
Jörg
DerWoWusste
Lösung DerWoWusste 09.01.2015, aktualisiert am 11.01.2015 um 08:28:55 Uhr
Goto Top
Icalcs Ordnername
DerWoWusste
DerWoWusste 10.01.2015 um 14:57:54 Uhr
Goto Top
Es sollte auch ein leichtes sein, mttels procmon am DC festzustellen, wo der Access denial denn liegt. Wieso das der Support nicht vorschlägt, wüsste ich gerne.
Procmon anwerfen, Policy aufrufen, Log nach "access denied" durchsuchen, schon siehst Du, was zu erwarten ist.
jlaufenburg
jlaufenburg 12.01.2015 aktualisiert um 15:55:50 Uhr
Goto Top
Hallo DerWoWusste,
ich verzweifle....

So sehen aktuell die Berechtigungen aus.

\\dug.local\SysVol\dug.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}
NT-AUTORITÄT\Authentifizierte Benutzer: (OI)(CI)R
NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION: (OI)(CI)R
DUG\Dom„nen-Admins: (OI)(CI)(NP)F
ERSTELLER-BESITZER: (OI)(CI)(IO)F
DUG\Organisations-Admins: (OI)(CI)F
NT-AUTORITÄT\SYSTEM: (OI)(CI)F


Typ Prinzipal Zugriff Geerbt von Anwenden auf
Zulassen NT-AUTORITÄT\Authentifizierte Benutzer Lesen, Ausführen keine Diesen Ordner, Unterordner und Dateien
Zulassen NT-AUTORITÄT\Domänenvontroller der Organisation Lesen, Ausführen keine Diesen Ordner, Unterordner und Dateien
Zulassen DUG\Domänen-Admins Vollzugriff keine Diesen Ordner, Unterordner und Dateien
Zulassen ERSTELLER-BESITZER Vollzugriff keine Nur Unterordner und Dateien
Zulassen DUG\Organisations-Admins Vollzugriff keine Diesen Ordner, Unterordner und Dateien
Zulassen NT-AUTORITÄT\SYSTEM Vollzugriff keine Diesen Ordner, Unterordner und Dateien

Im Procmon kann ich nichts sehen was mir einen Anhaltspunkt gibt, wo der Access denial liegt.

Danke und Gruß
Jörg
DerWoWusste
DerWoWusste 12.01.2015 um 16:01:48 Uhr
Goto Top
Setz doch bitte mal die Zugriffsrechte so wie empfohlen. Deine sind verstellt.
->dom admins: full mit Vererbung
->auth. Benutzer UND Domänencontroller: Read und Execute
jlaufenburg
jlaufenburg 12.01.2015 aktualisiert um 16:09:49 Uhr
Goto Top
Hi,
bis auf das NP bei Domänen-Admins sieht es jetzt aus wie bei dir.

\\dug.local\SysVol\dug.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}
NT-AUTORITŽT\Authentifizierte Benutzer: (OI)(CI)(RX)
NT-AUTORITŽT\DOMŽNENCONTROLLER DER ORGANISATION: (OI)(CI)(RX)
DUG\Dom„nen-Admins: (OI)(CI)(NP)(F)
ERSTELLER-BESITZER: (OI)(CI)(IO)(F)
DUG\Organisations-Admins: (OI)(CI)(F)
NT-AUTORITŽT\SYSTEM: (OI)(CI)(F)
DerWoWusste
DerWoWusste 12.01.2015 um 16:25:43 Uhr
Goto Top
Und, wo ist das Problem, das NP noch wegzubekommen? Das steht für "Vererbung ist ausgeschaltet". Stell also dort in den erweiterten Berechtigungen bei Dom. Admins ein, dass es auch für Dateien und Unterordner übernommen wird.
jlaufenburg
jlaufenburg 12.01.2015 um 16:51:07 Uhr
Goto Top
Gib mir bitte nochmal einen TIpp wie.
Über die Windows GUI bringt das nichts. Da ist es eingeschaltet, das dir rechte runter vererbt werden.
DerWoWusste
DerWoWusste 12.01.2015 um 17:01:10 Uhr
Goto Top
Nimm mal icacls. Bin gerade unterwegs.
jlaufenburg
jlaufenburg 12.01.2015 um 17:10:44 Uhr
Goto Top
Ich habs mit folgeden Befehl versucht, bringt aber immer noch nichts.
icacls \\dug.local\SysVol\dug.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\ /inheritance:e /t
DerWoWusste
Lösung DerWoWusste 12.01.2015, aktualisiert am 13.01.2015 um 11:45:18 Uhr
Goto Top
icacls  \\dug.local\SysVol\dug.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9} /grant "domänen-admins":(OI)(CI)(F)  
jlaufenburg
jlaufenburg 13.01.2015 aktualisiert um 09:04:53 Uhr
Goto Top
Hi,
auf Anhieb hat es mit dem Befehl nicht geklappt.
Erst nach dem ich die Domänen-Admins einmal entfernt habe, konnte ich die Berechtigungen entsprechend setzten.

\\dug.local\SysVol\dug.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}
DUG\Domänen-Admins: (OI)(CI)(F)
NT-AUTORITÄT\Authentifizierte Benutzer: (OI)(CI)(RX)
NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION: (OI)(CI)(RX)
ERSTELLER-BESITZER: (OI)(CI)(IO)(F)
DUG\Organisations-Admins: (OI)(CI)(F)
NT-AUTORITŽT\SYSTEM: (OI)(CI)(F)

Aber funktionieren tut es leider immer noch nicht wieder. face-sad
DerWoWusste
DerWoWusste 13.01.2015 um 09:41:11 Uhr
Goto Top
Ok, weitere Denkanstöße:

-kannst Du die xml-Dateien im Policyordner fehlerfrei öffnen? (nicht modifizieren!)
-was spuckt procmon denn aus im Moment des Fehlers, wenn man Focus setzt auf mmc.exe?
-ist die mmc gestartet mit einem Konto, das nun Zugriff haben müsste?
-Geht es zufällig mit einem anderen Domänenadmin?
-kannst Du die Policy noch exportieren?
-Wenn Du RSAT nutzen solltest, geht es evtl. am DC selbst besser?
-Hast Du mehrere DCs, bearbeitest Du auch wirklich die Policy, deren Rechte Du angepasst hast?
jlaufenburg
jlaufenburg 13.01.2015 um 10:10:21 Uhr
Goto Top
-kannst Du die xml-Dateien im Policyordner fehlerfrei öffnen? (nicht modifizieren!)
XML Dateien liegen in dem Ordner nicht, aber alle anderen kann ich öffnen und auch bearbeiten.

-was spuckt procmon denn aus im Moment des Fehlers, wenn man Focus setzt auf mmc.exe?
Jede menge, aber nichts was auf die Richtlinie verweist.

-ist die mmc gestartet mit einem Konto, das nun Zugriff haben müsste?
Ja, ich bin als Domänen Administrator angemeldet.

-Geht es zufällig mit einem anderen Domänenadmin?
Leider auch nicht.

-kannst Du die Policy noch exportieren?
nein geht auch nicht mehr.

-Wenn Du RSAT nutzen solltest, geht es evtl. am DC selbst besser?
Die Änderungen habe ich jetzt nicht vom Basisdomänencontroller aus gemacht.
Aber auch auf diesem ist der Zugriff nicht möglich.

-Hast Du mehrere DCs, bearbeitest Du auch wirklich die Policy, deren Rechte Du angepasst hast?
Ja wir haben mehrer DC`s und ich bin mir sicher, dass ich diese Policy bearbeite.
Die ID steht in der Fehlermeldung mit drin {31B2F340-016D-11D2-945F-00C04FB984F9}

Hast du Lust mit Teamviewer einmal drauf zu schauen?
Gerne auch Offiziell mit Rechnung, etc. face-wink
DerWoWusste
DerWoWusste 13.01.2015 um 10:17:32 Uhr
Goto Top
Ok,

ich könnte nach Feierabend und Sport raufschauen, aber das kann heute spät werden. Da Microsoft schon nicht weiterkommt, gebe ich dem auch nur geringe Chancen.
Morgen Abend Zeit, evtl. 18 Uhr?
jlaufenburg
jlaufenburg 13.01.2015 um 10:30:40 Uhr
Goto Top
Hört sich gut an, schicke dir dann meine Kontakdaten. face-wink

MS hat noch einen neuen Aktionsplan geschickt, den werde ich aber erst nochmal durch probieren.
DerWoWusste
DerWoWusste 13.01.2015 um 10:34:57 Uhr
Goto Top
Hab ihn gelesen. Ja, die SACLS können es natürlich auch sein, unbedingt machen.
jlaufenburg
jlaufenburg 13.01.2015 um 11:45:00 Uhr
Goto Top
Problem gelöst!

Zum einen waren es mit Sicherheit die Berechtigungen, zum anderen der folgende Aktionsplan von MS.

Aktionsplan:
Copy the GUID from the Default Domain Policy
1. Go to Start > Run.
2. Open the GPMC.msc
3. Go to the Default Domain Policy that is “Inaccessible”.


Figure 1: Select "Inaccessible".
4. Copy the GUID which appears under the scope tab in the content view of the Group Policy console.

Figure 2: Copy the GUID (Unique ID) from the content view.
Recover Procedure

1. Start the cmd as Administrator
2. Type the following command: dsacls cn={GUID},cn=policies,cn=system,dc=domain,dc=domain

Example: cn={31B2F340-016D-11D2-945F-00C04FB984F9},cn=Policies,cn=system,dc=contoso,dc=com


Figure 3: Run the “dsacls” commandline tool
You’ll now be shown a list with 2 columns. First part lists the users and groups and the second column lists the permissions.
In the example provided here you should simply look for “Deny” permission.

Figure 4: View Rights on the GPO

3. If the object has been denied for the specific group or user you can run the following command: dsacls cn={GUID},cn=policies,cn=system,dc=domain,dc=domain /R USER/GROUP

Example: dsacls cn={31B2F340-016D-11D2-945F-00C04FB984F9},cn=Policies,cn=system,dc=contoso,dc=com /R “Authenticated Users”

Info:
/R {User | Group} [{User | Group}]...
Deletes all ACEs for the specified users or groups. User can be specified as User@Domain or as Domain\User. Group can be specified as Group@Domain or as Domain\Group.
You can delete ACEs for multiple users and groups in a single /R parameter

4. If you want you can give the user/group who were denied some more rights. You’ll have to adjust this to whatever you’re trying to recover in your environment.

Please type the following line: dsacls cn={GUID},cn=policies,cn=system,dc=domain,dc=domain /G USER/GROUP:GA

Example: dsacls cn={31B2F340-016D-11D2-945F-00C04FB984F9},cn=Policies,cn=system,dc=contoso,dc=com /G “Authenticated Users”:GA


Figure 5: Grant "Generic All" to Authenticated Users
Info:
Syntax for PermissionStatement
PermissionStatement values use the following format:

{User | Group}:Permissions[;{ObjectType | Property}][;InheritedObjectType]
Parameters

{User | Group}
Specifies the user or group to whom the rights apply. User can be specified as a distinguished name, User@Domain, or Domain\User. Group can be specified as a distinguished name, Group@Domain, or Domain\Group.

Permissions
Type one or more of the values in the following tables (without spaces).

Generic Permissions
Value Description
GR Generic Read
GE Generic Execute
GW Generic Write
GA Generic All

5. Head back to the Group Policy Management Console and find the place where the GPO is linked to, or check the Group Policy Objects container.
Now it should be possible to edit the group policy object again since rights has been “restored”.
Dsacls
http://msdn.microsoft.com/de-de/library/cc779257%28v=ws.10%29.aspx

Besten Dank für die Hile!!!