Advanced Security and Delegation with the GPMC | Group Policy, Profiles, and IntelliMirror for Windows2003, WindowsXP, and Windows 2000 (Mark Minasi Windows Administrator Library)

Mere mortals ' access to Group Policy can be and, indeed, should be controlled. Users' access to all things Group Policy related is judged in many forms. However, the first question you'll want to answer and understand well is basic: To whom should Group Policy be applied, and to whom should it not be applied?

Once we can answer that, we can move on to some more advanced topics:

What kind of access can I grant to mere mortals to manipulate the GPO itself? That is, can a user read or modify the GPO's settings or security?
How can I grant a mere mortal access to create GPOs in the domain?
Can a user perform special Group Policy-related stuff, such as the creation and management of WMI filters or access to RSoP tools?

You can answer all these questions by determining what security is placed on Active Directory and specific GPOs. Let's tackle these questions one at a time to locate all the places users' access touches our Group Policy infrastructure and where that access can be managed.

Filtering the Scope of Group Policy Objects

The normal day-to-day Human Resources workers inside the Human Resources OU structure are fine with the facts of life:

The Enterprise Administrator says that no one at the site will have the Screen Saver tab.
The Domain Administrator says that no one will have the Desktop tab. He is forcing this edict with the "Enforced" option.
Frank Rizzo, the Human Resources OU Manager, says that for the Human Resources Users OU he will remove the Settings tab, but restore the Screen Saver tab. For the Human Resources Computers OU, he'll be removing the Scheduled Tasks icon. Additionally, at the top-level Human Resources OU, he will enable the "Block Inheritance" setting to give back the Screen Saver tab removed by the Enterprise Administrator at the site level. But Frank is forced to live with the fact that he won't be able to return to his people the Desktop tab that the Domain Administrator has taken away.

But Frank and other members of the HR-OU-Admins Security group are getting frustrated that they cannot access the Settings tab. And they're also getting frustrated that they can't schedule tasks on the machines they use every day. Sure, it was Frank's own idea to make these two policy settingsone that affects the users he's in charge of, and one that affects the computers he's in charge of. The problem is, however, it also affects Frank (and the other members of the HR-OU-Admins team) when they're working, and you can see where that can be annoying.

Frank needs a way to "filter" the "Scope of Management" ( SOM ) of the "Hide Settings Tab/Restore Screen Saver Tab" as well as the "Prohibit new Tasks in Task Scheduler" GPOs. By scope or SOM, I mean "how far and wide" the GPOs we set up will be embraced.

Note

Occasionally you will see references to SOM in your travels with Group Policy. An SOM is simply a quick-and-dirty way to express where and when a GPO might apply. An SOM can be nearly any combination of things: linking a GPO to the domain, linking a GPO to an OU, and linking a GPO to a site. However, if you start to filter GPOs within the domain, that's also an SOM. In essence, an SOM indicates when and where a GPO applies to a level in Active Directory.

In our case, the idea is twofold:

Frank and his team are excluded from the "Hide Settings Tab/Restore Screen Saver Tab" GPO edict.
The specific computers that Frank and his team use are excluded from the "Prohibit new Tasks in Task Scheduler" GPO edict.

Recall from Chapter 1 that, despite the wording of the term Group Policy , Group Policy does not directly affect Security groups. You cannot just wrap up a bunch of similar users or computers in a Security group and thrust a GPO upon them. There's nowhere to "link" to. You need to round up the individual user or computer accounts into an OU first and then link the desired GPO on that OU.

Here's the truly strange part: even though you can't round up users in Security groups and apply GPOs to them, it's the Security group that we'll leverage (in most cases) in order to enable us to filter Group Policy application!

In order for users to get GPOs to apply to them, they need two under-the-hood access rights to the GPO itself:

Read
Apply Group Policy

These permissions must be set on the GPO in question. By default, all Authenticated Users are granted the "Read" and "Apply Group Policy" rights to all new GPOs. Therefore, anyone who has a GPO geared for them will process it.

How Is a Computer an Authenticated User?

I was shocked to learn that a computer falls under the category of an Authenticated User. It's true: the computer account has the Authenticated User's SID in its access token. I was skeptical, but fiber-Guru Bill Boswell (and author of Chapter 7) proved it to me. And you can prove it to yourself by following these steps:

Use the at command and specify a time at least one minute ahead of the current time to open a system-level console:
```
 at <one minute in the future> /interactive cmd 
```
Use WHOAMI to verify that the cmd has run as System. Now use WHOAMI /ALL to verify that you have the Authenticated Users group in the access token.

Note that the System does not have domain credentials. When it touches another machine, it uses the Kerberos ticket issued to the local computer. You can take advantage of this for this experiment.

Set the NTFS permissions on a folder in a shared volume on another machine to deny access to Authenticated Users but allow access by Everyone.
Map a drive from the system console to the share point and try to access the contents of the protected folder. You'll be denied access.

Because Deny for Authenticated Users comes before Allow for Everyone, you've proved that the computer account has the Authenticated Users group in its access token.

The following two things might not be immediately obvious:

Administrators are not magically exempt from embracing Group Policy; they, too, are members of "Authenticated Users." You can change this behavior with the techniques described in the very next section.
Computers need love too. And for computers to apply their side of the GPO, they need the same rights: "Read" and "Apply Group Policy." Since computers are technically Authenticated Users, the computer has all it needs to process GPOs meant for it.

With this fundamental concept in mind, let's look at several ways to filter who gets specific GPOs.

If you want to filter GPOs for either specific users or specific computers, you have three distinct approaches. For our three examples (which will all do the exact same thing), we want the "Hide Settings Tab/Restore Screen Saver Tab" GPO to "pass over" our heroes in the HR-OU-Admins security group, but apply to everyone else who should get them. We also want the "Prohibit new Tasks in Task Scheduler" GPO to pass over the specific computers our heroes use at their desks.

Group Policy Object Filtering Approach #1: Leverage the "Security Filtering" Section of the Scope Tab in GPMC

In the first approach, you'll round up only the users, computers, or Security groups who should get the GPO applied to them. To make things easier, let's first create two Active Directory Security groupsone for our users who will get the GPO, and one for computers who will get the GPO. Good names might be People Who Get Hide Settings Tab-Restore Screen Saver Tab GPO and Computers That Get The Prohibit New Tasks In Task Scheduler GPO. Go ahead and do this in Active Directory Users And Computers as seen in Figure 2.11.

Figure 2.11: Create anew Active Directory Security group for whom you want the GPO to apply.

Next, add all user accounts you want to embrace the GPO into the first Security group.

You would then add all computer accounts you want to get the GPO into the security group named Computers That Get The Prohibit New Tasks In Task Scheduler GPO.

Because we don't want these GPO to apply to Frank or Frank's computer (XPPRO1), don't add Frank to the first group (which contains users) and don't add XPPRO1 to the second group (which contains computers).

Next, click the link to the "Hide Settings Tab / Restore Screen Saver Tab" GPO found in Group Policy Management ˜ Forest ˜ Domains ˜ Corp.com ˜ Human Resources OU ˜ Human Resources Users OU. In the Security Filtering section, you can see that Authenticated Users is listed. This means that any users inside the Human Resources Users OU will certainly get this GPO applied.

However, now we're about to turn the tables. We're going to click the "Remove" button to remove the Authenticated Users in the Security Filtering section; then we're going to add the People Who Get Hide Settings Tab-Restore Screen Saver Tab GPO Security group, as shown in Figure 2.12.

Figure 2.12: When you remove "Authenticated Users," no one will get the effects of the GPO. Add only the users or groups you want the GPO to affect.

Next, click the "Prohibit new Tasks in Task Scheduler" GPO link (which is under the Human Resources Computers OU). In the Security Filtering section of the Scope tab, you'll remove Authenticated Users and add the Computers That Get The Prohibit New Tasks In Task Scheduler GPO Security group.

Tip	In both cases, what we're really doing under the hood is giving these new Security groups the ability to "Read" and "Apply Group Policy." You'll see this under-the-hood stuff in a minute.

Testing Your First Filters

To see if this is working, log on to your Windows XP machine as Frank (Frizzo). Even though the GPO applies to the Human Resources Users OU, the GPO will pass over him and anyone else not explicitly put into that Security group since Frank is not a member of the People Who Get Hide Settings Tab-Restore Screen Saver Tab GPO Security group.

For another test, add a new user account or two to the Human Resources Users OU (via Active Directory Users And Computers.) Then, log on as one of these new users (in the OU) and verify that they, indeed, do not get the GPO. This is because the GPO is only set to apply to members of the security group. Then, add the user to the Security group, and log on again. The GPO will then apply to your test users (inside the Security group) as well. In fact, you can add users to the Security group by simply clicking the Properties button in the Security Filtering section. Doing so opens the Security Group Membership dialog in which you can add or delete users or computers.

Repeat your tests by adding XPPRO1 into the Security group named Computers That Get The Prohibit New Tasks In Task Scheduler GPO. When the computer is in the group, it will apply the GPO. Now, try removing XPPRO1 and see what happens. When the computer is out of the group, the GPO will pass over the computer.

Note	You might have to reboot the machine or run GPUPDATE /FORCE to immediately see computer-side results.

What's Going on Under the Hood for Filtering

As I implied , when you add Security groups to get the GPOs in the "Security Filtering" section, you're really doing a bit of magic under the hood. Again, that magic is simply granting two security permissions: "Read" and "Apply Group Policy" to the users or Security groups that you want to apply the GPOs in the OU.

To see which security permissions are really set under the hood for a particular GPO (or GPO link, because it's the same information), click the Delegation tab and select the Advanced button as shown in Figure 2.13.

Figure 2.13: Selecting "Advanced" in the Delegation tab for the GPO (or GPO link) shows the under-the-hood security settings for the GPO.

When you do, you can see the actual permission on the GPO itself. You can easily locate the Security group named People Who Get Hide Settings Tab-Restore Screen Saver Tab GPO and see that they have both the "Read" and "Apply Group Policy" access rights set to "Allow." This is why they will process this GPO.

Filtering Approach #2: Identify Who You do Not Want to Get the Policy

The other approach, typically used in environments that do not use the GPMC, is to leave the default definition in for the GPO such that the "Authenticated Users" group is granted the "Read" and "Apply Group Policy." Then, figure out who you do not want to get the policy applied to them, and use the "Deny" attribute over the "Apply Group Policy" right.

When Windows security is evaluated, the designated users or computers will not be able to process the GPO due to the "Deny" attribute; hence, the GPO passes over them.

Note	See the "Positive or Negative" sidebar later in this chapter before doing this in your real environment.

For our examples, we want the "Hide Settings Tab/Restore Screen Saver Tab" GPO to pass over our heroes in the HR-OU-Admins Security group, but apply to everyone else by default. We also want the "Prohibit new Tasks in Task Scheduler" GPO to pass over the specific computers our heroes use at their desks.

To use this second technique, we'll use the "Deny" permission to ensure that the HR-OU-Admins Security group cannot apply (and hence process) the "Hide Settings Tab/Restore Screen Saver Tab" GPO. We'll also additionally prevent Frank's computer, XPPro1, from processing the "Prohibit new Tasks in Task Scheduler" GPO.

Again, you'll do this on the GPO (or the GPO link, because it's the same information), click the Delegation tab, and then click the Advanced button. Follow these steps:

Locate the "People who get Hide Settings Tab-Restore Screen Saver Tab GPO" Security group and remove it.
Locate the "Authenticated Users" group, select the "Read" permission, select Allow, select "Apply Group Policy" permission, and select Allow.
If you used Frank's account to originally create this GPO, he is specifically listed in the security list. You want to remove Frank and add the HR-OU-Admins group. Click Frank, and then click Remove. Click Add, and add the HR-OU-Admins group.

Make sure the "Apply Group Policy" check box is set to "Deny" for the HR-OU-Admins group, as shown in Figure 2.14.

Warning

Do not set the Deny check box for the "Read" or "Write" attributes from the HR-OU-Admins (the group you're currently a member of when logged in as Frank). If you do, you'll essentially lock yourself out, and you'll have to ask the Domain Administrator to grant you access again.

Click OK to close the Group Policy Settings dialog box. In the warning box that tells you to be careful about Deny permissions, click Yes.
Click OK to close the OU Properties dialog box.

Figure 2.14: Use the "Deny" bit to prevent Group Policy from applying.

To test your first filter again, log on to XPPro1 as Frank Rizzo. Note that the Settings tab has returned to him because he is part of the HR-OU-Admins group. The "Hide Settings Tab/Restore Screen Saver Tab" GPO has passed over him because he is unable to process the GPO.

To bypass "Prohibit new Tasks in Task Scheduler" GPO on XPProl, you'll perform a similar function. That is, you'll modify the security on the GPO to pass over the computers our heroes use by denying those specific computer accounts the ability to "Apply Group Policy." You can then test your second filter by logging on as anyone to XPPro1. You should be able to create new tasks in the Task Scheduler.

Tip	If you want to filter many machines, you can just as easily create a Security group for the computers and deny the "Apply Group Policy" right to the entire group. It's just like you did for the HR-OU-Admins group, but, instead, think of putting computers in their own Security group.

Turns out, however, there's a major problem by using the aforementioned method. That is, if you performed the previous exercise and used the "Deny" attribute to pass over the HR-OU-Admins group using the Security on the GPO, you've got a small problem. Sure, it worked! That's the good news. The bad news is that GPMC isn't smart enough to interpret quite what you did back on the "Scope Tab" in the "Security Filtering" section as shown in Figure 2.15.

Figure 2.15: The Security Filtering section on the Scope tab will not show you any use of "Deny" bits under the hood.

Yes, it's technically true what the Security Filtering section says: Authenticated Users will apply this GPO. However, it doesn't tell us the other important fact: that the HR-OU-Admins group will not process this GPO, because they were denied the ability to "Apply Group Policy."

The only way to get the full, true story of who will actually get the GPO applied to them is to look back within the GPO (or GPO link, because it's the same information), select the Delegation tab, and click the Advanced button to see who has "Read" and "Apply" Group Policy; then also see who is denied access to process the GPO via the "Deny" attributes.

Positive or Negative?

Now that you can see the two ways to filter users from processing GPOs, which should you use? Approach 1 (adding only those you want to get the GPO) or Approach 2 (denying only those you don't want to get the GPO)? The data reflected within the GPMC's Scope tab clearly wants you to take the first approach. However, many Active Directory implementations I know take the second approach (and, in fact, it was my advice to do so in the first edition of this book.)

Now, you and your team need to make a choice for your approach. As you saw, when you create new GPOs, you can choose to filter via the Scope tab or the Advanced Delegation. So which do you choose? If you're going to be religious about using the first approach, you can then be reasonably confident that only the users, groups, and computers listed in the Security Filtering section of the Scope tab will, in fact, be the only users, groups, and computers who will get the GPO. You can then reduce your need to dive into the Security Editor as seen in Figures 2.13 and 2.14, earlier in this chapter.

However, if you (or other administrators) occasionally choose to use the "Deny" attribute upon users, computers, and groups from getting the GPO, you'll need to additionally inspect the Advanced Security Editor dialog in the Delegation tab as in Figures 2.13 and 2.14 earlier in this chapter.

The GPMC clearly encourages you to use Approach #1 for filtering. If you have older GPOs in your Active Directory that already use Approach #2 for filtering, consider changing it so that GPMC's Scope tab will actually reflect who will get the GPO.

The moral of the story? Always consult the Advanced tab to get the "whole truth" as to the security on the GPO.

Granting User Permissions Upon an Existing Group Policy Object

You already know the three criteria for someone to be able to edit or modify an existing GPO:

They are a member of the Domain Admins group.
They are a member of the Enterprise Admins group.
They created the GPO themselves and hence are the owner. (We saw this in Figure 1.22 in Chapter 1 when Frank couldn't edit the GPOs he didn't create.)

But sometimes, you also want to add rights to a user upon a GPO so that they can modify it. As we foreshadowed, the Delegation tab for a GPO (or GPO link, which reflects the same information) has a second purpose: to help you grant permissions to groups or users over the security properties of that GPO. If you click Add on the Delegation tab, you can grant any mere mortal user or group (even in other domains) the ability to manipulate this GPO, as seen in Figure 2.16.

Figure 2.16: The Delegation tab helps you set permissions on a GPO.

Once the permissions settings have been applied, the user has that level of rights over the GPO, as seen in Table 2.1.

Table 2.1: GPMC vs. Genuine Active Directory permissions
Permissions Option	Actual Under-the-Hood Permissions
"Read"	Sets the Allow permission for "Read" on the GPO.
"Edit settings"	Sets the Allow permission for "Read," "Write," "Create Child Objects," and "Delete Child Objects." See note at the end of this table.
"Edit settings, delete, modify security"	Sets the Allow permission for "Read," "Write," "Create Child Objects," "Delete Child Objects," "Delete," "Modify Permissions," and "Modify Owner." This is near-equivalent to full control on the GPO, but note that "Apply Group Policy" access permission is not set. (This can be useful to set for administrators so they can manipulate the GPO but not have it apply to themselves.)
"Read (from Security Filtering)"	This isn't a permission located in the ACL Editor (see Fig 2.14); rather this is only visible if the user has "Read" and "Apply Group Policy" permissions on the GPO. This is a reflection of what is on the Scope tab.
Custom	Any other combinations of rights, including the use of the Deny permission. Custom rights are only added via the ACL editor but can be removed here. They can be removed using the Remove button as in the Delegation tab.

Note

If you look really, really closely at the "Under the hood" attributes specifically granted to the user when he is given "Edit settings" or "Edit setting, delete, modify security" rights, you'll notethat "Write" isn'texpressly listed. However, the ability to perform writes is granted because other sub-attributes which do permit writing are granted on the entry. To see those attributes for yourself, click the Advanced button while looking at the properties of the security on a GPO (like what we see in Figure 2.14.)

Granting Group Policy Object Creation Rights in the Domain

As you learned in Chapter 1, a user cannot create new GPOs unless that user is a member of the Group Policy Creator Owners group. Dropping a user into this group is one of two ways you can grant this right.

However, the GPMC introduces another way to grant users the ability to have Group Policy Creator Owner-style access. Traverse to the Group Policy Objects container as seen in Figure 2.17, and click the Delegation tab. You can now click Add and select any user, including any user in your domain, say a user named Joe User, or users across forests, such as Sol Rosenberg, who is in a domain called bigu.edu. As you can see in Figure 2.17, both users have been added.

Figure 2.17: You can choose to delegate to users in your domain, in other domains, or in domains in other forests.

This can be handy if you have trusted administrators in other domains that you want to have create GPOs in your domain. You might want to round them up into a group (instead of just listing them individually as Sol is listed here), but that's your option.

Special Group Policy Operation Delegations

You can delegate three special permissions at the domain and OU levels, and you can set one of those three special permissions at the site level. Clicking the level, such as an OU, and then clicking the Delegation tab for that level shows the available permissions as seen in Figure 2.18.

Figure 2.18: These operations are equivalent to the Active Directory Users And Computers "Delegation Wizard."

The interface is a bit confusing here. Specifically, you must first select the permission from the drop-down box. This lists the current users who can have permissions to use the right. You can then click the "Add," "Remove," or "Advanced" button to make your changes.

There are three Permissions that may be selected from the dropdown box, as seen in Figure 2.18. They are:

Linking GPOs Of the three permissions here, this is the only permission that can be configured at all levels: site, domain, and OU. Recall in Chapter 1 that you ran the Active Directory Users And Computers "Delegation of Control Wizard" (see Figure 1.19). Instead of using Active Directory Users And Computers to perform that task, the GPMC can do the same jobright here.
Perform Group Policy Modeling Analyses This right performs the same function as if we had used the Active Directory Users And Computers "Delegation of Control Wizard" to grant the "Generate Resultant Set of Policy (Planning)" permissions, as seen previously in Figure 1.19. The next section describes how to get more data about what's happening at the client. You'll see how to use this power in the "What-If Calculations with Group Policy Modeling" section later in this chapter. Group Policy Modeling lets you simulate what-if scenarios regarding users and computers.

By default, only Domain Admins have the right to perform this task. Domain Admins can grant other users or groups the ability to perform this function, such as the Help Desk, HR-OU-Admins, or your own desktop-administrator teams . You can choose to grant people the ability to perform Group Policy Modeling analyses on this specific container or this specific container and child containers. When you assign this right, the user performing the Group Policy Modeling analysis must have the delegated right upon the container containing the what-if user and also the container containing the what-if computer. If you don't grant rights in both containers, only half the analysis is displayed.

Tip	This right is available only if the domain schema has been updated for Windows 2003. Additionally, Group Policy Modeling analyses function only when at least one Windows 2003 Domain Controller is available in the domain.

Read Group Policy Results Data This right performs the same function as if we used the Active Directory Users And Computers "Delegation of Control Wizard" to grant the "Generate Resultant Set of Policy (Logging)" permission, as seen previously in Figure 1.19. You'll see how to use this power in the "What's-Going-On Calculations with Group Policy Results" section later in this chapter. However, if you want to grant this power to others, you can. Again, a typical use is to grant this right to the Help Desk or other administrative authority.
When you assign this right, the user performing the Group Policy Results analysis must have the delegated right upon the container containing the target computer. Or this right can be applied at a parent container, and the rights will flow down via inheritance. The user must also have this right delegated upon any container containing any users who have logged on to the machine you want to analyze. If you don't grant rights in both containers, no analysis is displayed.

Tip
This right is available only if the domain schema has been updated for Windows 2003.

Who Can Create and Use WMI Filters?

Okay, okay, okay. I know the subject of WMI filters has come up before about 3000 times already, and every time I refer you, the poor reader, to Chapter 10. Once you've read what they are and how to create them in Chapter 10, please come back here and read how to manage them.

Two types of people are involved in the management of WMI filters:

Those who can create them
Those who can use them

Delegating Who Can Create WMI Filters

By default, only the Domain Administrator can create WMI filters. However, you might have some WMI whiz-kid in your company (and it's a good chance this isn't the same person as the Domain Administrator.) With that in mind, the Domain Administrator can grant that special someone the ability to create WMI filters. To do this, drill down to the domain ˜ WMI Filters node, and then select Delegation in the pane on the right. You can now grant one of two rights, as shown in Figure 2.19.

Figure 2.19: These are controls over the creation of WMI filters.

In Figure 2.19, we can see the two rights that appear in the drop-down box:

Once a user has "Creator Owner" rights here, they can create and modify their own WMI filters, but they cannot modify others' WMI filters.
A user with "Full Control" rights here can create and modify their own WMI filters or anyone else's.

Tip	These rights are available only if the domain schema has been updated for Windows 2003.

Delegating Who Can Use WMI Filters

Once WMI filters are created (again, see Chapter 10), you'll likely want to assign who can apply them to specific GPOs. To do this, drill down to the specific WMI filter, as shown in Figure 2.20. Then click Add, and you'll see that two rights are available for the user you want.

Figure 2.20: These are controls over the WMI filters themselves.

In Figure 2.20, we can see the two rights that appear in the drop-down box:

Once a user has "Edit" rights here, they can edit and tailor the filter, as we do in Chapter 10.
A user with "Full Control" rights here can edit the filter as well as delete it and modify the security (that is, specify who else can get "Edit" or "Full Control" rights here).

Tip	These rights are available only if the domain schema has been updated for Windows 2003.