Symptom
You have a team of dedicated group policy operators. You have existing policies that are currently managed by the domain administrators. When the ownership of a certain group policy should be transferred from the Domain Administrators to the group policy operator team, you change the owner of the group policy in Group Policy Management Console (GPMC) in advanced security settings. This is succeeding.
The new owner later goes into the security settings of the policy and grants himself full control on the policy. This is succeeding, there is no error message.
When the new owner edits the group policy, they will receive an error “Access Denied”. The actual message will depend on the extension editor used, for example for Administrative Templates:
Error 0x80070005 writing registry.pol in “Policies\{C2FFD6A0-21A0-4A74-A874-EE261B42BF96}\User
The new owner later goes into the security settings of the policy and grants himself full control on the policy. This is succeeding, there is no error message.
When the new owner edits the group policy, they will receive an error “Access Denied”. The actual message will depend on the extension editor used, for example for Administrative Templates:
Error 0x80070005 writing registry.pol in “Policies\{C2FFD6A0-21A0-4A74-A874-EE261B42BF96}\User
Cause
When GPMC changes the owner of a policy, it updates the entry only on the root object of the policy in Active Directory and on SYSVOL. For the policy GUID quoted in the error message above this would be:
- Cn={C2FFD6A0-21A0-4A74-A874-EE261B42BF96},cn=policies,cn=system,dc=contoso,dc=com
- \\contoso.com\sysvol\contoso.com\Policies\{C2FFD6A0-21A0-4A74-A874-EE261B42BF96}
Later, when the new owner changes the Discretionary Access Control List (DACL), they are allowed to do so by default unless “Owner Rights” are set differently. The permissions are set successfully in Active Directory, and the Security Descriptor Propagator (SDPROP), running within the Directory Server, forwards the new permission to the subordinate objects. The owner of the root object does not have to have permissions on the subordinate objects.
On SYSVOL with NTFS, the permissions are also set successfully on the policy root folder. But with NTFS, the client is responsible for inheriting the new permissions to the subordinate object. This is failing with “Access Denied”, because the user is not Owner of the children objects (ADM, USER, MACHINE, GPT.INI).
This can be seen in a network trace of the procedure, or with a process monitor log of the Microsoft Management Console (MMC) instance running the GPMC. Example from PROCMON LOG:
12 13:48:26,3189199 mmc.exe 1980 CreateFile \\dc1.contoso.com\SysVol\contoso.com\Policies\{C2FFD6A0-21A0-4A74-A874-EE261B42BF96}\Adm ACCESS DENIED Desired Access: Read Attributes, Read Control, Write DAC, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
The “Write DAC” Access Flag will cause the operation on this subordinate object to fail.
- Cn={C2FFD6A0-21A0-4A74-A874-EE261B42BF96},cn=policies,cn=system,dc=contoso,dc=com
- \\contoso.com\sysvol\contoso.com\Policies\{C2FFD6A0-21A0-4A74-A874-EE261B42BF96}
Later, when the new owner changes the Discretionary Access Control List (DACL), they are allowed to do so by default unless “Owner Rights” are set differently. The permissions are set successfully in Active Directory, and the Security Descriptor Propagator (SDPROP), running within the Directory Server, forwards the new permission to the subordinate objects. The owner of the root object does not have to have permissions on the subordinate objects.
On SYSVOL with NTFS, the permissions are also set successfully on the policy root folder. But with NTFS, the client is responsible for inheriting the new permissions to the subordinate object. This is failing with “Access Denied”, because the user is not Owner of the children objects (ADM, USER, MACHINE, GPT.INI).
This can be seen in a network trace of the procedure, or with a process monitor log of the Microsoft Management Console (MMC) instance running the GPMC. Example from PROCMON LOG:
12 13:48:26,3189199 mmc.exe 1980 CreateFile \\dc1.contoso.com\SysVol\contoso.com\Policies\{C2FFD6A0-21A0-4A74-A874-EE261B42BF96}\Adm ACCESS DENIED Desired Access: Read Attributes, Read Control, Write DAC, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
The “Write DAC” Access Flag will cause the operation on this subordinate object to fail.
Resolution
The issue is that the GPMC does not update the owner for all objects in the Active Directory and in NTFS that belong to the policy. The second issue is the function in ntmarta.dll, used by GPMC, does not return an error to the caller when the inheritance operation fails. This is why the GPMC does not notify the user about the failure.
To work around this issue, the Domain Administrators should grant permissions to the Group Policy Operators directly. If the Domain Administrators ownership or permissions need to be revoked, the Group Policy Operators group can do this as an additional step as they now have full control of the object.
To work around this issue, the Domain Administrators should grant permissions to the Group Policy Operators directly. If the Domain Administrators ownership or permissions need to be revoked, the Group Policy Operators group can do this as an additional step as they now have full control of the object.
More Information
The stack in Process Monitor will look like this:
9 ntdll.dll ZwOpenFile + 0xa 0x778b01ea C:\Windows\System32\ntdll.dll
10 ntmarta.dll I_MartaFileNtOpenFile + 0x58 0x7fefc9023d8 C:\windows\system32\ntmarta.dll
11 ntmarta.dll MartaFindNextFile + 0x124 0x7fefc903fb7 C:\windows\system32\ntmarta.dll
12 ntmarta.dll MartaFindFirstFile + 0x14d 0x7fefc904036 C:\windows\system32\ntmarta.dll
13 ntmarta.dll MartaUpdateTree + 0x5f 0x7fefc9045f7 C:\windows\system32\ntmarta.dll
14 ntmarta.dll MartaManualPropagation + 0x43f 0x7fefc90442e C:\windows\system32\ntmarta.dll
15 ntmarta.dll AccRewriteSetNamedRights + 0x196 0x7fefc903883 C:\windows\system32\ntmarta.dll
16 advapi32.dll SetNamedSecurityInfoW + 0x84 0x7fefe1a8a23 C:\Windows\System32\advapi32.dll
16 advapi32.dll SetNamedSecurityInfoW + 0x84 0x7fefe1a8a23 C:\Windows\System32\advapi32.dll
17 gpmgmt.dll SetSysvolSecurityFromDSSecurity + 0x230 0x7fef0b45d38 C:\windows\System32\gpmgmt.dll
18 gpmgmt.dll CGPMGPO::SetSecurityDescriptor + 0x3ca 0x7fef0b6915e C:\windows\System32\gpmgmt.dll
19 GPOAdminCustom.dll CGPODelegationSectionBase::WriteSecurityDescriptor + 0x267 0x7fef0dfaee3 C:\windows\System32\GPOAdminCustom.dll
20 dssec.dll CDSSecurityInfo::SetSecurity + 0x57 0x7fef9e43f7f C:\Windows\System32\dssec.dll
9 ntdll.dll ZwOpenFile + 0xa 0x778b01ea C:\Windows\System32\ntdll.dll
10 ntmarta.dll I_MartaFileNtOpenFile + 0x58 0x7fefc9023d8 C:\windows\system32\ntmarta.dll
11 ntmarta.dll MartaFindNextFile + 0x124 0x7fefc903fb7 C:\windows\system32\ntmarta.dll
12 ntmarta.dll MartaFindFirstFile + 0x14d 0x7fefc904036 C:\windows\system32\ntmarta.dll
13 ntmarta.dll MartaUpdateTree + 0x5f 0x7fefc9045f7 C:\windows\system32\ntmarta.dll
14 ntmarta.dll MartaManualPropagation + 0x43f 0x7fefc90442e C:\windows\system32\ntmarta.dll
15 ntmarta.dll AccRewriteSetNamedRights + 0x196 0x7fefc903883 C:\windows\system32\ntmarta.dll
16 advapi32.dll SetNamedSecurityInfoW + 0x84 0x7fefe1a8a23 C:\Windows\System32\advapi32.dll
16 advapi32.dll SetNamedSecurityInfoW + 0x84 0x7fefe1a8a23 C:\Windows\System32\advapi32.dll
17 gpmgmt.dll SetSysvolSecurityFromDSSecurity + 0x230 0x7fef0b45d38 C:\windows\System32\gpmgmt.dll
18 gpmgmt.dll CGPMGPO::SetSecurityDescriptor + 0x3ca 0x7fef0b6915e C:\windows\System32\gpmgmt.dll
19 GPOAdminCustom.dll CGPODelegationSectionBase::WriteSecurityDescriptor + 0x267 0x7fef0dfaee3 C:\windows\System32\GPOAdminCustom.dll
20 dssec.dll CDSSecurityInfo::SetSecurity + 0x57 0x7fef9e43f7f C:\Windows\System32\dssec.dll