Forcing Domain Admins to use AGPM (but not really)

Hi folks, Sean Wright here for my final post. So, you have AGPM installed, but your Domain Admins continue using GPMC to create, delete, and modify Group Policy. You’ve asked nicely, but that hasn’t had much effect. Now you want to make your point, and prevent your Domain Admins from managing Group Policy the wrong way. You decide to deny Domain Administrators the rights to modify Group Policy Objects (GPOs) through any means save the AGPM console. It may seem like a good idea, but let me explain how your time is better spent elsewhere.

First, let’s cover the concept of a domain administrator. The domain admin is the most trusted and unrestricted user account in the domain. The domain admin can do anything in the domain and can give themselves permissions that make anything possible. The domain admin is the "Domain Overlord" if you will. Go ahead, laugh maniacally now, I’ll wait.

The very notion that you want to deny something to a Domain Admin is a foreign concept. You don’t deny them anything. They deny rights to others. Windows and Active Directory are built upon this fundamental concept, which brings us to our next section.

Why you’re wasting your time:

Active Directory is tailored to Domain Admins being all-powerful. No matter what you do to restrict their rights, they can simply change it back at will. You can make it difficult, which might discourage them… but a determined admin can undo anything you change.

You now have a new admin on the team, and during his troubleshooting “Random Group Policy Problem #5”, they receive an access denied error when managing policy through GPMC. They should be using AGPM, and the fact that they are unaware of this is a whole other issue. Most admins take access denied errors as a bad thing-- after all, they are an admin; so, they may start fixing the environment by changing permissions.

If you contact Microsoft Support for a Group Policy related issue, we will likely return the permissions to defaults before proceeding with troubleshooting. We do not recommend this scenario, because you can't prevent a domain administrator from being an domain administrator, and your efforts can be so easily undone.

If you modify permissions on policy folders within SYSVOL, you’re going to trigger replication for every file and folder that is changed. In large environments with many policies, that can be a significant network traffic surge.

Most importantly, Microsoft has not tested this scenario, so you may introduce unforeseen problems to your environment by attempting it.

What you should do instead:

The advice I give to every customer who force domain admins into AGPM is Education. You can’t prevent a domain admin from doing something if they are determined. If you can’t trust your domain admins to do the right thing, and do it the right way, then they should not be a domain admins. That said, I suggest educating administrators by teaching them about AGPM and its benefits. Explain why they should only use AGPM manage policy, and you will likely see them consciously decide to go the extra mile to do things the correct way.

Recently, I had a customer insist AGPM was incomplete, because it did not have this restrictive functionality built-in. The developers did not intend for AGPM to restrict admins. It was designed to provide benefits that make troubleshooting and administration of policy more manageable.

If you’re still reading, and are determined to try this in spite of my recommendations against it:

Editing existing Group Policy object

During installation, in an effort to make things easier, some customers simply add the AGPM service account to the Domain Administrators group. Since we’re about to prevent domain admins from accessing production GPOs, you’ll want to read over the AGPM Least Privilege scenario and make sure you have successfully implemented this before you proceed.

1. We’ll need to remove any Administrative users or groups from the “Group Policy Creator Owners” group. You can do this through Active Directory Users and Computers.

2. If it’s not already there, make sure you add the AGPM service account to ”Group Policy Creator Owners”

3. Open the Group Policy Management Console (GPMC.msc) and find the Group Policy Objects container. The Delegation tab shows a list of users/groups that have the ability to create new GPOs in the domain. You can try to remove Domain Admins from this location, but alas, it won’t let you.

Note: This is a safety feature, designed to prevent you from accidentally removing all rights to create GPOs.

What you can do, is prevent your domain admins from editing the existing GPOs.

4. Within GPMC, expand the Group Policy Objects container and find the Default Domain Controllers Policy.

5. Select the Default Domain Controllers GPO and go to the Delegation tab.

6. Remove the Domain Administrators and Enterprise Administrators groups from the delegation list.

7. Make sure the list contains SYSTEM with full control, and ENTERPRISE DOMAIN CONTROLLERS and the Authenticated Users entries with Read permissions (at least).

8. Repeat steps 5 through 7 for every GPO currently in your environment.

This makes your existing GPOs resistant (but not immune) to your administrator’s editorial charms.

9. Next, open GPMC with your AGPM Administrator account and go to the AGPM console.

10. Click on the Production Delegation tab and remove Domain Administrators and Enterprise Administrators from this location. This tab within the AGPM console determines the permissions AGPM assigns to controlled GPOs when they are deployed to production using AGPM. Making this change prevents all of the hard work you just did in the section above from going to waste.

Don’t worry that the list isn’t complete. We need to add Authenticated Users and the AGPM service account to production GPOs.

Control Group Policy object links

So far, we’ve removed the domain admin’s ability to edit existing GPOs, but they can still create new GPOs and link new and existing GPOs to OUs. In order to prevent these actions, we need to explicitly deny specific rights related to Group Policy.

1. Open GPMC and click on the domain node that contains the name of your domain.

2. Click Delegation and click Advanced.

3. On the domain’s security dialog box, click Advanced to open the Advanced Security Settings dialog.

4. Click Add button to add a new entry.

5. Type Domain Admins and then click Check Names. Click OK to show the Permission Entry dialog.

6. Click Properties.

7. Select the Deny check box next to the permissions Write gPLink and Write gPOptions.

8. Click OK on all dialogs until you return to GPMC.

9. Check the permissions by right-clicking the node with the name of the domain. Notice the menu items Create a GPO in this domain, and Link it here… ; Link an Existing GPO… ; and Block Inheritance are unavailable. Additionally, the menu items Enforced and Link Enabled are unavailable on existing GPO links.

10. You will need to repeat steps 1-9 for every OU in your domain. This change is also needed for any newly created OUs. It might seem easier to set these deny permissions at the domain level and let inheritance propagate the settings down to existing and new OUs, it doesn’t work. When an OU is created in Active Directory, permissions are explicitly defined at the OU level. When you set an explicit deny permission at the domain level, inheritance applies an implicit deny at the OU level. An explicit deny wins over an explicit allow; however, an explicit allow wins over an implicit deny.

Note: There is also an option to change the default permissions applied to new OUs as they are created. This option modifies the schema, so use caution when modifying any value in the schema. The defaultSecurityDescriptor attribute is in SDDL format, so I recommend you configure one OU with the correct security settings and copy the value. This prevents having to manually set the permissions as new OUs are created in the future.

No new GPOs for You

So far, we removed the domain admin’s right to edit existing GPOs, and their rights to link new GPOs to existing OUs in the domain. Also, we removed their right to edit the GPOptions such as link and enforced states. The last step is to prevent a domain admin from creating new GPOs in the domain’s Group Policy Objects container.

1. Open ADSIEdit.msc. Right-click the ADSI Edit node in the navigation pane and then click Connect to…

2. Configure the Connections Settings dialog similar to the following image. Click OK.

3. In the navigation pane, expand the Default naming context until you find the following container: CN=Policies,CN=System,DC=domain,DC=com.

4. Right-click CN=Policies and then click Properties.Click the Security tab.

5. Click Advanced to open the Advanced Security Settings dialog. Add an entry for Domain Admins,and deny the permission to create or delete groupPolicyContainer objects.

This last step makes Create menu item unavailable within GPMC when creating a new Group Policy Objects. The Delete menu item remains available for GPOs; however, attempting a delete results with an access denied error.

An Imperfect Solution:

Many aspects of this scenario require periodic administrative attention that certainly increases management costs.. In addition, domain admins can undo this partially or in total. This can increases the difficultly that comes with troubleshooting.

Group Policy was designed to be managed by domain administrators. Attempting to hack a solution can cause its fair share of administrative burden (even when it’s working correctly). Why? Because any domain admin can undo the solution with relative ease, making it a monumental waste of time and provides a false sense of security. Since Microsoft does not recommend this scenario, we advise everyone to use AGPM as a beneficial tool and educate your staff. When they are familiar with it, and have it as readily available as GPMC, they will be more likely to do the right thing by using the AGPM to manage GPOs.

And the real solution? Have some consequences when admins choose not to use AGPM. That will straighten people out in a hurry. If your domain admin can't follow simples rules, like use AGPM, the imagine what other dangers lurk behind your back.

Sean "Don't Taz Me Bro" Wright

[Editor’s note: this was Sean’s last post – he left us for greener pastures last week. Good luck man, I hope you can get a chuckle out of your new colleagues with your famous photoshopping – Ned]

Comments

• Anonymous
  June 21, 2011
  Hmmm... I have an ideal solution ;) Just tell them the truth: every time when someone deploys settings from AGPM, the settings which were done directly will be just overwritten ;) Works like charm =) Audit helps too, I guess...