Now that we are all digging out from MS16-072, and the reality that it likely won’t be “fixed” anytime soon, I think it’s worthwhile to drop a quick blog post about how you can ensure that all GPOs that get created going forward in your environment, get the proper read permissions on them. A long time ago, I blogged about how you could add additional groups to the default GPO ACL by modifying the defaultSecurityDescriptor attribute on the group-policy-container AD schema class. This method is well documented by Microsoft and indeed will allow you to add Default Computers with read access to every new GPO that gets created to address future problems with MS16-072. The process is relatively simple (or as simple as a schema change in AD can be).
The first step, is that you obviously need permissions to make such a change. This means that you need to be a member of the Schema Admins group in AD. Here are the next steps. I probably don’t need to say this but MODIFYING THE SCHEMA SHOULD NOT BE TAKEN LIGHTLY!!!! SO BE CAREFUL.
1.If you have the AD tools installed on your server or workstation, fire up ADSIEdit.msc and, from the Action, Connect To menu, connect to the schema instance of your domain:
3. Double-click the group-policy-container class to bring up it’s attributes and navigate down to the defaultSecurityDescriptor attribute. Double-click that attribute and you will see a dialog with a long list of Security Descriptor Definition Language (SDDL) strings. Each group of SDDL strings in parentheses represent a default permission on the GPO.
4. The first thing I would do is select the whole SDDL string on the attribute and copy/paste it into Notepad so you have a backup of the pristine value in case something goes wrong. Next, put your cursor at the very end of that long string, after the last closing parentheses and paste the following SDDL string into the attribute value:
(A;CI;LCRPLORC;;;DC)
so it looks like the following (a good explanation of SDDL strings is here: https://jorgequestforknowledge.wordpress.com/2008/03/26/parsing-sddl-strings/):
5. Press OK to commit the change. The last thing you need to do, for this to take effect, is to reload the schema.
6. Load the AD Schema MMC snap-in (if you don’t see the snap-in appear in the MMC list, open an elevated command prompt and type regsvr32 schmmgmt.dll then restart MMC and it should appear), right-click the top level “Active Directory Schema” node and select “Reload the Schema” as shown here:
7. Once completed, when you create a new GPO, you will see, under the delegation tab, the new Domain Computers group with Read permissions, as shown here:
All future GPOs should now function properly in the brave new MS16-072 world!
Darren
operation failed. error code 0x202b. a referral was returned from the server.
Were you connected to the Schema Operations Master when you tried the edit? I had the same error first time, but then made sure I was connected to the SOM and all was OK.
Having said that, I agree with your later post suggesting just to use the Active Directory Schema snap-in to do the actual edit too. Certainly easier/safer via a GUI than messing with SDDL.
can we just grant “domain computers” read rights to the group-policy-container object using the AD Schema GUI, as outlined here: https://technet.microsoft.com/en-us/library/dd252852.aspx
Sorry for the delay, but yes, that approach *should* work the same. One difference I noticed as I started to walk through it, is that permissions added via SDDL show as “Special” in the UI but if I try to add a new entry via the Schema snap-in, It simply shows “read” permissions. So I’m not sure what the difference is there, and don’t have time to dig into it now, but it does show up differently.
How would you add “Authenticated Users” as opposed to Domain Computers if you wanted to go that route? Essentially what is the “Authenticated Users” version of “(A;CI;LCRPLORC;;;DC)”?
Thanks for the information; great article.
you should be able to replace the “DC” at the end of the SDDL, with “AU”. However, note that by default, GPOs already grant Authenticated Users with Read and Apply Group Policy, so unless you plan on removing that, adding an SDDL string for Authenticated Users, Read permission is redundant.