Читать книгу Group Policy - Jeremy Moskowitz - Страница 17

Now that you’ve got a grip on honing your view within the GPMC, let’s take it for a quick spin around the block with some examples!

For this series of examples, we’re going after the users who keep fiddling with their display doo-dads in Windows 10.

If you want to see these examples in action using Windows 10, start out on WIN10 by looking at the “Change the visuals and sounds on your computer” page, which is located by right-clicking the Desktop and choosing Personalize. In the left column, you’ll see items including “Change desktop icons” and “Change mouse pointers.” In the bottom section, you’ll see several entries, including Desktop Background, Window Color, Sounds, and Screen Saver, as shown in Figure 1-13.

Figure 1-13: The Windows 10 Personalization page – unconfigured by Group Policy

For our first use of Group Policy, we’re going to produce four “edicts” (for dramatic effect, you should stand on your desk and loudly proclaim these edicts with a thick British accent):

● At the site level, there will be no ability to change screen savers.

● At the domain level, there will be no ability to change Windows’ sounds.

● At the Human Resources Users OU level, there will be no way to change the mouse pointers. And, while we’re at it, let’s bring back the ability to change screen savers!

● At the Human Resources Computers OU, we’ll make it so whenever anyone uses a Human Resources computer, calc.exe automatically launches after login.

Following along with these concrete examples will reinforce the concepts presented earlier. Additionally, they are used throughout the remainder of this chapter and the book.

Understanding GPMC’s Link Warning

As you work through the examples, you’ll do a lot of clicking around. When you click a GPO link the first time, you’ll get this message:

This message is trying to convey an important sentiment – that is, multiple levels in Active Directory may be linked back and use the exact same GPO. The idea is that multiple levels of Active Directory could use the exact same Group Policy Object contained inside the Group Policy Objects container – but just be linked back to it.

What if you modify the policy settings by right-clicking a policy link and choosing Edit from the context menu? All instances in Active Directory that link to that GPO embrace the new settings. If this is a fear, you might want to create another GPO and then link it to the level in Active Directory you want. More properties are affected by this warning, and we’ll explore them in Chapter 4, “Advanced Group Policy Processing.”

If you’ve squelched this message by selecting “Do not show this message again,” you can get it back. In the GPMC in the menus, choose View ⇒ Options and select the General tab, then select “Show confirmation dialog box to distinguish between GPOs and GPO links” and click OK.

More about Linking and the Group Policy Objects Container

The GPMC is a fairly flexible tool. Indeed, it permits the administrator to perform many tasks in different ways. One thing you’ll do quite a lot in your travels with the GPMC is create your own Group Policy Objects. Again, GPOs live in a container within Active Directory and are represented within the Group Policy Objects container (the swimming pool) inside the domain (seen in Figure 1-11, earlier in this chapter). Any levels of Active Directory – site, domain, or OU – simply link back to the GPOs hanging out in the Group Policy Objects container.

To apply Group Policy to a level in Active Directory using the GPMC, you have two options:

● Create the GPOs in the Group Policy Objects container first. Then, while focused at the level you want to command in Active Directory (site, domain, or OU), manually add a link to the GPO that is in the Group Policy Objects container.

● While focused at the level you want to command in Active Directory (domain or OU), create the GPOs in the Group Policy Objects container and automatically create the link. This link is created at the level you’re currently focused at back to the GPO in the Group Policy Objects container.

Which is the correct way to go? Both are perfectly acceptable because both are doing the same thing.

In both cases the GPO itself does not “live” at the level in Active Directory at which you’re focused. Rather, the GPO itself “lives” in the Group Policy Objects container. The link back to the GPO inside the Group Policy Objects container is what makes the relationship between the GPO inside the Group Policy Objects container swimming pool and the level in Active Directory you want to command.

To get the hang of this, let’s work through some examples. First, let’s create our first GPO in the Group Policy Objects folder. Follow these steps:

1. Launch the GPMC. Click Start, and then in the search box, type GPMC.MSC.

2. Traverse down by clicking Group Policy Management ⇒ Forest ⇒ Domains ⇒ Corp.com ⇒ Group Policy Objects.

3. Right-click the Group Policy Objects folder and choose New from the context menu, as shown in Figure 1-14, to open the New GPO dialog box.

4. Let’s name our first edict, er, GPO, something descriptive, such as “Hide Screen Saver Option.”

5. Once the name is entered, you’ll see the new GPO listed in the swimming pool. Right-click the GPO and choose Edit, as shown in Figure 1-15, to open the Group Policy Management Editor.

6. To hide the Screen Saver option, drill down by clicking User Configuration ⇒ Policies ⇒ Administrative Templates ⇒ Control Panel ⇒ Personalization. Double-click the Prevent changing screen saver policy setting to open it. Select the Enabled setting, and click OK.

7. Close the Group Policy Management Editor.

Figure 1-14: You create your first GPO in the Group Policy Objects container by right-clicking and choosing New.

Figure 1-15: You can right-click the GPO in the Group Policy Objects container and choose Edit from the context menu to open the Group Policy Management Editor.

Note that in earlier iterations of the GPMC, this setting was named differently and placed in another node. It used to be called Hide Screen Saver Tab and was located in the Display node within Control Panel. As you can see, as the operating system evolves, so do the names of the policy settings, Group Policy Preference items (described in Chapter 5), and the capabilities within the GPMC itself. This is why it’s pretty important to always use the “latest, greatest” GPMC, as we are doing in this book.

Understanding Our Actions

Now that we have this “Hide Screen Saver Option” edict, er, GPO floating around in the Group Policy Objects container – in the representation of the swimming pool of the domain – what have we done? Not a whole lot, actually, other than create some bits inside Active Directory and on the Domain Controllers. By creating new GPOs in the Group Policy Objects folder, we haven’t inherently forced our desires on any level in Active Directory – site, domain, or OU.

To make a level in Active Directory accept our will, we need to link this new Group Policy Object to an existing level. Only then will our will be accepted and embraced. Let’s do that now.

Applying a Group Policy Object to the Site Level

The least-often-used level of Group Policy application is at the site. This is because it’s got the broadest stroke but the bluntest application. And more and more organizations use high-speed links everywhere, so it’s not easy to separate computers into individual sites because (in some organizations) Active Directory is set up to see the network as just one big site!

Additionally, since Active Directory states that only members of Enterprise Administrators (EAs) can modify sites and site links, it’s equally true that only EAs (by default) can add and manipulate GPOs at the site level.

When a tree or a forest contains more than one domain, only the EAs and the Domain Administrators (DAs) of the root domain can create and modify sites and site links. When multiple domains exist, DAs in domains other than the root domain cannot create sites or site links (or site-level GPOs).

However, site GPOs might come in handy on occasion. For instance, you might want to set up site-level GPO definitions for network-specific settings, such as Internet Explorer proxy settings or an IP security policy for sensitive locations. Setting up site-based settings is useful if you have one building (set up explicitly as an Active Directory site) that has a particular or unique network configuration. You might choose to modify the Internet Explorer proxy settings if this building has a unique proxy server. Or, in the case of IP security, perhaps this facility has particularly sensitive information, such as confidential records or payroll information.

Therefore, if you’re not an EA (or a DA of the root domain), it’s likely you’ll never get to practice this exercise outside the test lab. In upcoming chapters I’ll show you how to delegate these rights to other administrators, like OU administrators.

For now, we’ll work with a basic example to get the feel of the Group Policy Management Editor.

We already stood on our desks and loudly declared that there will be no Screen Saver options at our one default site. The good news is that we’ve already done two-thirds of what we need to do to make that site accept our will: we exposed the sites we want to manage, and we created the “Hide Screen Saver Option” GPO in the Group Policy Objects container.

Implementing GPOs linked to sites can have a substantial impact on your logon times and WAN (wide area network) traffic if not performed correctly. For more information, see Chapter 7 in the section “Group Policy Objects from a Site Perspective.”

Now all we need do is to tether the GPO we created to the site with a GPO link.

To remove the Screen Saver option using the Group Policy Management Editor at the site level, follow these steps:

1. Inside the GPMC snap-in, drill down by clicking the Group Policy Management folder, the Forest folder, and the Sites folder.

2. Find the site to which you want to deliver the policy. If you have only one site, it is likely called Default-First-Site-Name.

3. Right-click the site and choose “Link an Existing GPO,” as shown in Figure 1-16.

4. Now you can select the “Hide Screen Saver Option” GPO from the list of GPOs in the Group Policy Objects container within the domain.

Once you have chosen the GPO, it will be linked to the site.

Did you notice that there was no “Are You Sure You Really Want To Do This?” warning or anything similar? The GPMC trusts that you set up the GPO correctly. If you create GPOs with incorrect settings and/or link them to the wrong level in Active Directory, you can make boo-boos on a grand scale. Again, this is why you want to try any setting you want to deploy in a test lab environment first.

Again, there is a good reason GPOs for sites must be pre-created. Since Sites does not belong to a specific domain but rather the forest, you cannot assume which “domain swimming pool” a particular GPO should be added to. By creating them this way, you know which domain you created them in first and then to what site you want them linked.

Figure 1-16: Once you have your first GPO designed, you can link it to your site.

Verifying Your Changes at the Site Level

Now, log onto any workstation or server that falls within the boundaries of the site to which you applied the sitewide GPO. If you didn’t change any of the defaults, you should be able to log onto any computer in the domain (say, WIN10) as any user you have defined – even the administrator of the domain.

Right-click the Desktop and select Personalize. Then click Lock Screen on the left, and try the Screen Saver option toward the bottom of the page. When you try it, you’ll see what happens, which you can also see in Figure 1-17.

Don’t panic if you do not see the changes reflected the first time you log on. See Chapter 3, “Group Policy Processing Behavior Essentials,” in the section “Background Refresh Policy Processing” to find out how to encourage changes to appear. To see the Screen Saver tab disappear right now, log off and log back on. The policy should take effect.

Figure 1-17: In Windows 10 the Screen Saver entry on the Personalization page is disabled.

This demonstration should prove how powerful Group Policy is, not only because everyone at the site is affected, but more specifically because administrators are not immune to Group Policy effects. Administrators are not immune because they are automatically members of the Authenticated Users security group. (You can modify this behavior with the techniques explored in Chapter 3.)

Applying Group Policy Objects to the Domain Level

At the domain level, we want to deliver an edict that says that the Sounds option in the Windows Personalization page should be removed.

Active Directory domains allow only members of the Domain Administrators group the ability to create and link Group Policy directly on the domain level. Therefore, if you’re not a DA (or a member of the EA group), or you don’t get delegated the right, it’s likely that you’ll never get to practice this exercise outside the test lab. (A bit later we’ll talk more about how to give others besides Domain Admins rights to create and link GPOs.)

To apply the edict, follow these steps:

1. In the GPMC, drill down by clicking Group Policy Management ⇒ Forest ⇒ Corp.com.

2. Right-click the domain name to see the available options, as shown in Figure 1-18.

Figure 1-18: At the domain level, you can create the GPO in the Group Policy Objects container and then immediately link to the GPO from here.

“Create a GPO in this domain, and Link it here” vs. “Link an Existing GPO”

In the previous example, we forced the site level to embrace our “Hide Screen Saver Option” edict. First, we created the GPO in the Group Policy Objects folder, and then in another step we linked the GPO to the site level. However, at the domain level (and, as you’re about to see, the OU level), we can take care of both steps at once via the “Create a GPO in this domain, and Link it here” command. (Note, in previous versions of the GPMC, this was confusingly called “Create And Link A GPO Here.” Being a grammar snob, this was a personal wish of mine to have clarified, and I’m happy to see Microsoft agreed and corrected it.)

This command tells the GPMC to create a new GPO in the Group Policy Objects folder and then automatically link the new GPO back to this focused level of Active Directory. This is a time-saving step so we don’t have to dive down into the Group Policy Objects folder first and then create the link back to the Active Directory level.

So why is the “Create a GPO in this domain, and Link it here” option possible only at the domain and OU level and not the site level? Because Group Policy Objects linked to sites can often cause excessive bandwidth troubles when the old-school way of doing things is used. With that in mind, the GPMC interface makes sure that when you work with GPOs that affect sites, you’re consciously choosing from which domain the GPO is being linked.

Don’t panic when you see all the possible options. We’ll hit them all in due time; right now we’re interested in the first two: “Create a GPO in this domain, and Link it here” and “Link an Existing GPO.”

Since you’re focused at the domain level, you are prompted for the name of a new Group Policy Object when you right-click and choose “Create a GPO in this domain, and Link it here.” For this one, type a descriptive name, such as “Prohibit Changing Sounds.” Your new “Prohibit Changing Sounds” GPO is created in the Group Policy Objects container and, automatically, a link is created at the domain level from the GPO to the domain.

Take a moment to look in the Group Policy “swimming pool” for your new GPO. Simply drill down through Group Policy Management ⇒ Forest ⇒ Domains ⇒ Corp.com and locate the Group Policy Objects node. Look for the new “Prohibit Changing Sounds” GPO.

Right-click the link “Prohibit Changing Sounds” (or the GPO itself) and choose Edit to open the Group Policy Management Editor. To make your wish come true and affect the sounds applet Windows 10 Personalization page, drill down through User Configuration ⇒ Policies ⇒ Administrative Templates ⇒ Control Panel ⇒ Personalization, and double-click Prevent changing sounds. Change the setting from Not Configured to Enabled, and click OK. Close the Group Policy Management Editor to return to the GPMC.

Note that the policy setting will only affect Windows 7 and later, so any Windows XP machines (if you have any) will ignore the policy setting.

Verifying Your Changes at the Domain Level

Now, log on as any user in the domain. You can log onto any computer in the domain (say, WIN10) as any user you have defined – even the administrator of the domain.

On WIN10, right-click the Desktop and click Personalize ⇒ Themes ⇒ Go to Advanced sound settings.

You’ll see in Figure 1-19 the before and after. On the left, you’ll see that before the policy applies, there are four tabs in the Sound applet. After the policy applies, there are three tabs in the Sounds applet.

The actual policy name was called Prevent changing sounds. Note that it didn’t prevent access to the Sounds applet, but instead removed the most critical tab, the Sounds tab, in the Sound applet.

Once again, administrators are not immune to Group Policy effects. You can change this behavior, as you’ll see in Chapter 2.

Figure 1-19: The Sounds applet goes from four tabs to three tabs because the user is affected by the domain-level policy

Applying Group Policy Objects to the OU Level

OUs are wonderful tools for delegating away unpleasant administrative duties, such as password resets or modifying group memberships. But that’s only half their purpose. The other half is to be able to apply Group Policy.

You’ll likely find yourself making most Group Policy additions and changes at the OU level, because that’s where you have the most flexibility and the OU is the most refined instrument to affect users. Once OU administrators become comfortable in their surroundings, they want to harness the power of Group Policy.

Preparing to Delegate Control

To create a GPO at the OU level, you must first create the OU and a plan to delegate. For the examples in this book, we’ll create three OUs that look like this:

● Human Resources

● Human Resources Users

● Human Resources Computers

Having separate OUs for your users and computers is a good idea – for both delegation of rights and GPO design. Microsoft considers this a best practice. In the Human Resources Users OU in our Corp.com domain, we’ll create and leverage an Active Directory security group to do our dirty work. We’ll name this group HR-OU-Admins and put our first users inside the HR-OU-Admins security group. We’ll then delegate the appropriate rights necessary for them to use the power of GPOs.

To create the Human Resources Users OU using your WIN10MANAGEMENT machine, follow these steps:

1. Earlier, you created a “unified console” where you housed both Active Directory Users and Computer and the GPMC. Simply use Active Directory Users and Computers, right-click the domain name, and choose New ⇒ Organizational Unit, which will allow you to enter a new OU name. Enter Human Resources as the name. (Note that newer versions of Active Directory Users and Computers will ask you if you want to “Protect container from accidental deletion.” It’s your choice. I typically deselect the check box.)

2. Inside the Human Resources OU, create two more OUs —Human Resources Computers and Human Resources Users, as shown in Figure 1-20.

Figure 1-20: When you complete all these steps, your Human Resources OU should have a Human Resources Users OU and Human Resources Computers OU. In the users’ side, put Frank Rizzo and the HR-OU-Admins.

Alternatively, you can create the OU in the GPMC. Just right-click the domain and choose New Organizational Unit from the context menu.

To create the HR-OU-Admins group, follow these steps:

1. In Active Directory Users and Computers, right-click the new Human Resources Users OU and choose New ⇒ Group.

2. Create the new group HR-OU-Admins as a new global security group.

To create the first user to go inside HR-OU-Admins, follow these steps:

1. In Active Directory Users and Computers, right-click the Human Resources Users OU and choose New ⇒ User.

2. Name the user Frank Rizzo, with an account name of frizzo, and click Next.

3. Modern domains require a complex password for a user. Again, my suggested password is p@ssw0rd. That’s a lowercase p, the at sign, an s, an s, a w, a zero, then r, and d.

4. Finish and close the wizard.

If you’re following along, Frank Rizzo’s login will be frizzo@corp.com.

Easily Manage New Users and Computers

The Computers folder and Users folder in Active Directory Users and Computers are not OUs. They are generic containers. You’ll notice that they are not present when you’re using the GPMC to view Active Directory. Because they are generic containers (and not OUs), you cannot link Group Policy Objects to them. Of course, these objects will receive GPOs if linked to the domain, because the containers are still in the domain. They just aren’t OUs in the domain.

These folders have two purposes:

● If you ever did an upgrade from NT 4 domains to Active Directory, these User and Computer accounts would wind up in these folders. (Administrators are then supposed to move the accounts into OUs.)

● The two folders are the default location where older tools drop new accounts when creating new users and computers. Additionally, command-line tools, such as net user and net group, will add accounts to these two folders. Similarly, the Computers folder is the default location for any new client workstation or server that joins the domain. The same goes when you create computer accounts using the net computer command.

So, these seem like decent “holding pens” for these kinds of objects. But ultimately, you don’t want your users or computers to reside in these folders for very long – you want them to end up in OUs. That’s where the action is because you can apply Group Policy to OUs, not to these folders! Yeah, sure, these users and computers are affected by site- and domain-level GPOs. But the action is at the OU level, and you want your computer and user objects to be placed in OUs as fast as possible – not sitting around in these generic Computers and Users folders.

To that end, domains that are at least at the “Windows 2003 functional level” have two tools to redirect the default location of new users and computers to the OUs of your choice. For example, suppose you want all new computers to go to a NewComputers OU and all new users to go to a NewUsers OU. And you want to link several GPOs to the NewUsers and NewComputers OUs to ensure that new accounts immediately have some baseline level of security, restriction, or protection. Without a little magic, new user accounts created using older tools won’t automatically be placed there.

Starting with Windows 2003 Active Directory, Microsoft provided REDIRUSR and REDIRCMP commands that take a distinguished name, like this:

Now if you link GPOs to these OUs, your new accounts will get the Group Policy Objects dictating settings to them at an OU level. This will come in handy when users and computers aren’t specifically created in their final destination OUs.

To learn more about these tools, see the Microsoft Knowledge Base article 324949 at http://support.microsoft.com/kb/324949.

To add Frank Rizzo to the HR-OU-Admins group, follow these steps:

1. Double-click the HR-OU-Admins group.

2. Click the Members tab.

3. Add Frank Rizzo.

When it’s all complete, your OU structure with your first user and group should look like Figure 1-20, shown previously.

Delegating Control for Group Policy Management

You’ve created the Human Resources OU, which contains the Human Resources Users OU and the Human Resources Computers OU and the HR-OU-Admins security group. Now, put Frank inside the HR-OU-Admins group, and you’re ready to delegate control.

Performing Your First Delegation

You can delegate control to use Group Policy in two ways: using Active Directory Users and Computers and using the GPMC.

For this first example, we’ll kick it old school and do it the Active Directory Users and Computers way. Then, in Chapter 2, I’ll demonstrate how to delegate control using the GPMC.

To delegate control for Group Policy management, follow these steps:

1. In Active Directory Users and Computers, right-click the top-level Human Resources OU you created and choose Delegate Control from the context menu to start the “Delegation of Control Wizard.”

2. Click Next to get past the wizard introduction screen.

3. You’ll be asked to select users and/or groups. Click Add, add the HR-OU-Admins group, and click Next to open the “Tasks to Delegate” screen, shown in Figure 1-21.

Figure 1-21: Select the “Manage Group Policy links” task.

4. Click “Manage Group Policy links,” and then click Next.

5. At the wizard review screen, click Finish.

You might want to click some or all the other check boxes as well, but for this example, only “Manage Group Policy links” is required. Avoid selecting “Generate Resultant Set of Policy (Planning)” and “Generate Resultant Set of Policy (Logging)” at this time. You’ll see where these options come into play in Chapter 2.

The “Manage Group Policy links” delegation assigns the user or group Read and Write access over the gPLink and gPOptions properties for that level. To see or modify these permissions by hand, open Active Directory Users and Computers and choose View ⇒ Advanced Features. If later you want to remove a delegated permission, it’s a little challenging. To locate the permission that you set, right-click the delegated object (such as OU), click the Properties tab, click the Security tab, choose Advanced, and dig around until you come across the permission you want to remove. Finally, delete the corresponding access control entry (ACE).

Adding a User to the Server Operators Group (Just for This Book)

Under normal conditions, nobody but Domain Administrators, Enterprise Administrators, or Server Operators can walk up to Domain Controllers and log on. For testing purposes only, though, we’re going to add our user, Frank, to the Server Operators group so he can easily work on our DC01 Domain Controller when we want him to.

To add a user to the Server Operators group, follow these steps:

1. In Active Directory Users and Computers, double-click Frank Rizzo’s account under the Human Resources Users OU.

2. Click the Member Of tab and click Add.

3. Select the Server Operators group and click OK.

4. Click OK to close the Properties dialog box for Frank Rizzo.

Normally, you wouldn’t give your delegated OU administrators Server Operators access. You’re doing it solely for the sake of this example to allow Frank to log on locally to your Domain Controllers.

Testing Your Delegation of Group Policy Management

At this point, on your WIN10MANAGEMENT machine, log off as Administrator and log in as Frank Rizzo (frizzo@corp.com).

Now follow these steps to test your delegation:

1. Choose Start and type GPMC.MSC at the Start Search prompt to open the GPMC.

2. Drill down through Group Policy Management, Domains, Corp.com, and Group Policy Objects. If you right-click Group Policy Objects in an attempt to create a new GPO, you’ll see the context menu shown in Figure 1-22.

As you can see, Frank is unable to create new GPOs in the swimming pool of the domain. Since Frank has been delegated some control over the Human Resources OU (which also contains the other OUs), let’s see what he can do. If you right-click the Human Resources OU in the GPMC, you’ll see the context menu shown in Figure 1-23.

Figure 1-22: Frank cannot create new GPOs in the Group Policy Objects container.

Figure 1-23: Frank’s delegated rights allow him to link to existing GPOs but not to create new GPOs.

Because Frank is unable to create GPOs in the swimming pool of the domain (the Group Policy Objects container), he is also unable by definition to “Create a GPO in this domain, and Link it here.” Although Frank (and more specifically, the HR-OU-Admins) has been delegated the ability to “Manage Group Policy links,” he cannot create new GPOs. Frank (and the other potential HR-OU-Admins) has only the ability to link an existing GPO.

Understanding Group Policy Object Linking Delegation

When we were logged on as the Domain Administrator, we could create GPOs in the Group Policy Objects container, and we could “Create a GPO in this domain, and Link it here” at the domain or OU levels. But Frank cannot.

Here’s the idea about delegating the ability to link to GPOs: someone with a lot of brains in the organization does all the work in creating a well-thought-out and well-tested GPO. Maybe this GPO distributes software, maybe it sets up a secure workstation policy, or perhaps it runs a startup script. You get the idea.

Then, others in the organization, like Frank, are delegated just the ability to link to that GPO and use it at their level. This solves the problem of delegating perhaps too much control. Certainly some administrators are ready to create their own users and groups, but other administrators may not be quite ready to jump into the cold waters of Group Policy Object creation. Thus, you can design the GPOs for other administrators; they can just link to the ones you (or others) create.

When “Link an Existing GPO” is selected (as seen in Figure 1-23), any GPO which lives in the Group Policy Objects “swimming pool” can be selected.

In this example, the HR-OU-Admins members, such as Frank, can leverage any currently created GPO to affect the users and computers in their OU – even if they didn’t create it themselves. In this example, Frank has linked to an existing GPO called “Word 2003 Settings.” Turns out that some other administrator in the domain created this GPO, but Frank wants to use it. So, because Frank has “Manage Group Policy links” rights on the Human Resources OU (and OUs underneath it), he is allowed to link to it.

But, as you can see in Figure 1-24, he cannot edit the GPOs. Under the hood, Active Directory doesn’t permit Frank to edit GPOs he didn’t create (and therefore doesn’t own).

In Chapter 2, I’ll show you how to grant specific rights to allow more than just the original creator (and now owner) of the object to edit specific GPOs.

Giving the ability to just link to existing GPOs is a good idea in theory, but often OU administrators are simply given full authority to create their own GPOs (as you’ll see later). For this example, don’t worry about linking to any GPOs. Simply cancel out of the Select GPO screen, close the GPMC, and log off from the server as Frank Rizzo.

Figure 1-24: The GPMC will not allow you to edit an existing GPO if you do not own it (or do not have explicit permission to edit it).

Granting OU Admins Access to Create New Group Policy Objects

By using the “Delegation of Control Wizard” to delegate the “Manage Group Policy links” attribute, you performed half of what is needed to grant the appropriate authority to Frank (and any additional future HR-OU-Admins) to create GPOs in the Group Policy Objects container and link them to the Human Resources OU, the Human Resources Users OU, or the Human Resources Computers OU (though we really don’t want to link many GPOs directly to the Human Resources OU).

You can grant the HR-OU-Admins the ability to create GPOs in the Group Policy Objects container in two ways. For now, I’ll show you the old-school way; in Chapter 2, I’ll show you the GPMC way.

One of Active Directory’s built-in security groups, Group Policy Creator Owners, holds the key to the other half of our puzzle. You’ll need to add those users or groups that you want to have the ability to create GPOs to a built-in group, cleverly named Group Policy Creator Owners. To do so, follow these steps:

1. Log off and log back on as Domain Administrator.

2. Fire up Active Directory Users and Computers.

3. By default, the Group Policy Creator Owners group is located in the Users folder in the domain. Double-click the Group Policy Creator Owners group and add the HR-OU-Admins group and/or Frank Rizzo.

In Chapter 2, you’ll see an alternate way to allow users to create GPOs.

Creating and Linking Group Policy Objects at the OU Level

At the site level, we hid the Screen Saver option. At the domain level, we chose to get rid of the Sounds option in the Windows 10 Personalization page.

At the OU level, we have two jobs to do:

● Prevent users from changing the mouse pointers (a Windows 7 and later policy setting)

● Restore the Screen Saver option that was taken away at the site level

To create a GPO at the OU level, follow these steps:

1. Since you’re on WIN10MANAGEMENT, log off as Administrator and log back on as Frank Rizzo (frizzo@corp.com).

2. Choose Start and type GPMC.MSC in the Start Search prompt.

3. Drill down until you reach the Human Resources Users OU, right-click it, and choose “Create a GPO in this domain, and Link it here” from the context menu to open the New GPO dialog box.

4. In the New GPO dialog box, type the name of your new GPO, say “Hide Mouse Pointers Option / Restore Screen Saver Option.” This will create a GPO in the Group Policy Objects container and link it to the Human Resources Users OU.

5. Right-click the Group Policy link and choose Edit from the context menu to open the Group Policy Management Editor.

6. To hide the mouse pointers option in the Group Policy editor, drill down through User Configuration ⇒ Policies ⇒ Administrative Templates ⇒ Control Panel ⇒ Personalization and double-click the Prevent changing mouse pointers policy setting. Change the setting from Not Configured to Enabled, and click OK.

7. To restore the Screen Saver setting for Windows 10, double-click the Prevent Changing Screen Saver policy setting. Change the setting from Not Configured to Disabled, and click OK.

8. Close the Group Policy Management Editor to return to the GPMC.

By disabling the Hide Screen Saver Tab policy setting, you’re reversing the Enable setting set at a higher level. See the sidebar “The Three Possible Settings: Not Configured, Enabled, and Disabled” later in this chapter.

Verifying Your Changes at the OU Level

On your test WIN10 machine, log back on as Frank. Because Frank’s account is in the OU, Frank is destined to get the site, domain, and now the new OU GPOs with the policy settings.

On WIN10, right-click the Desktop and choose Personalize from the context menu to open the Display Properties dialog box.

You can now (as Frank) click Themes, and when you then try to click on “Go to mouse pointer settings” you will see what’s in Figure 1-25.

You should also now (as Frank) be able to click within Personalization upon the Lock Screen menu, and when you try to click on “Screen saver settings” you will be able to open it.

In Figure 1-25, you can see the before (left) and after (right) when the policy is applied. Look closely, and note that the “Pointers” option in the Mouse Properties applet is removed and that the Screen Saver option is no longer grayed out and is now available.

Figure 1-25: On the top, we have Frank’s Personalization page where Frank can now get to his Screen Saver settings. On the bottom (left) you can see Frank’s Mouse Properties before the policy applies. On the bottom (right) you can see Frank’s Mouse Properties after the policy applies (and note the missing “Pointers” tabs).

This test proves, once again, that even OU administrators are not automatically immune from policy settings. Chapter 2 explains how to change this behavior.

Group Policy Strategy: Should I Create More or Fewer GPOs?

At times, you’ll want to lock down additional functions for a collection of users or computers. For example, you might want to specify that no users in the Human Resources Users OU can use the Control Panel.

At the Human Resources Users OU level, you’ve already set up a GPO that contained a policy setting to hide the mouse pointers option in the Windows 10 Personalization page. You can create a new GPO that affects the Human Resources Users OU, give it a descriptive name – say, No One Can Use Control Panel– and then drill down through User Configuration⇒ Policies ⇒ Administrative Templates ⇒ Control Panel and enable the policy setting Prohibit Access to Control Panel.

Or you could simply modify your existing GPO, named Hide Mouse Pointers Option/Restore Screen Saver Option, so that it contains additional policy settings. You can then rename your GPO to something that makes sense and encompasses the qualities of all the policy changes – say “Our Human Resources Users’ Desktop Settings.”

Here’s the quandary: the former method (one policy setting per GPO) is certainly more descriptive and definitely easier to debug should things go awry. If you have only one policy set inside the GPO, you have a better handle on what each one is affecting. If something goes wrong, you can dive right into the GPO, track down the policy setting, and make the necessary changes, or you can disable the ornery GPO (as discussed in Chapter 2 in the section “Stopping Group Policy Objects from Applying”).

The second method (multiple policy settings per GPO) is a teeny-weeny bit faster for your computers and users at boot or logon time because each additional GPO takes some miniscule fraction of additional processing time. But if you stuff too many settings in an individual GPO, the time to debug should things go wrong goes up exponentially. Group Policy has so many nooks and crannies that it can be difficult to debug.

So, in a nutshell, if you have multiple GPOs at a particular level, you can do the following:

● Name each of them more descriptively.

● Debug them easily if things go wrong.

● Disable individually misbehaving GPOs.

● Associate a specific GPO more easily to a WMI filter (explored in Chapter 6).

● More easily delegate permissions to any specific GPO (explored in Chapter 2).

If you have fewer GPOs at a particular level, the following is the case:

● Logging on is slightly faster for the user (but only slightly).

● Debugging is somewhat more difficult if things go wrong.

● You can disable individually misbehaving GPOs or links to misbehaving GPOs. (But if they contain many settings, you might be disabling more than you desire.)

So, how do you form a GPO strategy? There is no right or wrong answer; you need to decide what’s best for you. Several options, however, can help you decide.

One middle-of-the-road strategy is to start with multiple GPOs and one lone policy setting in each. Once you are comfortable that they are individually working as expected, you can create another new GPO that contains the sum of the settings from, in this example, Prevent Changing Mouse Pointers and Prohibit Access to Control Panel, and then delete (or disable) the old individual GPO.

Another middle-of-the-road strategy is to have a single GPO that contains only the policy settings required to perform a complete “wish.” This way, if the wish goes sour, you can easily address it or disable it (or whack it) as needed.

Here’s yet another strategy. Some Microsoft documentation recommends that you create GPOs so that they affect only the User half or the Computer half. You can then disable the unused portion of the GPO (either the Computer half or the User half). This allows you to group together policy settings affecting one node for ease of naming and debugging and allows for flexible troubleshooting. However, be careful here because after you disable half the GPO, there’s no iconic notification (though there is a column labeled GPO Status that does show this). Troubleshooting can become harder if not performed perfectly and consistently. In all, I’m not a huge fan of disabling half the GPO.

Creating a New Group Policy Object Affecting Computers in an OU

For the sake of learning and working through the rest of the examples in this section, you’ll create another GPO and link it to the Human Resources Computers OU. This GPO will autolaunch a very important application for anyone who uses these machines: calc.exe.

The setting we’re about to play with also exists under the User node, but we’ll experiment with the Computer node policy.

First, you’ll need to create the new GPO and modify the settings. You’ll then need to move some client machines into the Human Resources Computers OU in order to see your changes take effect.

To autolaunch calc.exe for anyone logging into a computer in the Human Resources Computers OU, follow these steps:

1. If you’re not already logged in as Frank Rizzo, the Human Resources OU administrator, do so now on WIN10MANAGEMENT.

2. Choose Start and type GPMC.MSC in the Start Search prompt.

3. Drill down until you reach the Human Resources Computers OU, right-click it, and choose “Create a GPO in this domain, and Link it here” from the context menu.

4. Name the GPO something descriptive, such as “Auto-Launch calc.exe.”

5. Right-click the GPO, and choose Edit to open the Group Policy Management Editor.

6. We want to affect our client computers (not users), so we need to use the Computers node. To autolaunch calc.exe, drill down through Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Logon, and double-click Run these programs at user logon. Change the setting from Not Configured to Enabled.

7. Click the Show button, and the Show Contents dialog box appears. You’ll see that this policy setting has a little “table editor” associated with it. In the first “row,” simply enter the full path to calc.exe as c: \windows\system32\calc.exe and click OK, as shown in Figure 1-26. Click OK to close the Show Contents dialog box, and click OK again to close the Run these programs at user logon policy setting.

Figure 1-26: When this policy setting is enabled and calc.exe is specified, all computers in this OU will launch calc.exe when a user logs in.

8. Close the Group Policy Management Editor to return the GPMC.

Be aware of occasional strange Microsoft verbiage when you need to enable a policy to disable a setting. Since Windows 2003, most policy settings have been renamed to “Prohibit <whatever>” to reflect the change from confusion to clarity.

Moving Computers into the Human Resources Computers OU

Since you just created a policy that will affect computers, you’ll need to place a workstation or two inside the Human Resources Computers OU to see the results of your labor. You’ll need to be logged on as Administrator on DC01 or WIN10MANAGEMENT to do this.

Quite often computers and users are relegated to separate OUs. That way, certain GPOs can be applied to certain computers but not others. For instance, isolating laptops, desktops, and servers is a common practice.

In this example, we’re going to use the Find command in Active Directory Users and Computers to find your workstation named WIN10 and move it into the Human Resources Computers OU.

To find and move computers into a specific OU, follow these steps:

1. In Active Directory Users and Computers, right-click the domain, and choose Find from the context menu to open the “Find Users, Contacts, and Groups” dialog box.

2. From the Find drop-down menu, select Computers. In the Name field, type WIN10 to find the computer account of the same name. Once you’ve found it, right-click the account and choose Move from the context menu, as shown in Figure 1-27. Move the account to the Human Resources Computers OU.

3. Now that you’ve moved WIN10 (or other example machines) into the new OU, be sure to reboot those client computers.

After you move the computer accounts into the Human Resources Computers OU, it’s very important to reboot your client machines. As you’ll see in Chapter 3, the computer does not recognize the change right away when computer accounts are moved between OUs.

As you can see in this example (and in the real world), a best practice is to separate users and computers into their own OUs and then link GPOs to those OUs. Indeed, underneath a parent OU structure, such as the Human Resources OU, you might have more OUs (that is, Human Resources Laptops OU, Human Resources Servers OU, and so on). This will give you the most flexibility in design between delegating control where it’s needed and the balance of GPO design within OUs. Just remember that for GPOs to affect either a user or computer, that user or computer must be within the scope of the GPO – site, domain, or OU.

Figure 1-27: Use the Find command to find computers in the domain, then right-click the entry and select Move to move them.

Verifying Your Cumulative Changes

At this point, you’ve set up three levels of Group Policy that accomplish multiple actions:

● At the site level, the “Hide Screen Saver Option” GPO is in force for users.

● At the domain level, the “Prohibit Changing Sounds” GPO is in force for users.

● In the Human Resources Users OU, the “Hide Mouse Pointers Option/Restore Screen Saver Option” GPO is in force for users.

● In the Human Resources Computers OU, the “Auto-Launch calc.exe” GPO is in force for computers.

At this point, take a minute to flip back to Figure 1-11 (the swimming pool illustration) to see where we’re going here. To see the accumulation of your policy settings inside your GPOs, you’ll need to log on as a user who is affected by the Human Resources Users OU and at a computer that is affected by the Human Resources Computers OU. Therefore, log on as Frank Rizzo at WIN10.

If you’re using Windows 10, right-click the Desktop and choose Personalize. Note that the removal of “Change mouse pointers” is still in force (and the Screen Saver entry is restored). And, when you logged in as Frank Rizzo, did the computer GPO autolaunch Windows Calculator?

These tests prove that even OU administrators are not automatically immune from GPOs and the policy settings within. Under the hood, they are in the Authenticated Users security group. See Chapter 2 for information on how to modify this behavior.

The Three Possible Settings: Not Configured, Enabled, and Disabled

As you saw in Figure 1-2 earlier in this chapter, nearly all administrative template policy settings can be set as Not Configured, Enabled, or Disabled. These three settings have very different consequences, so it’s important to understand how each works.

Not Configured The best way to think about Not Configured is to imagine that it really says, “Don’t do anything” or even “Pass through.” Why is this? Because if a policy setting is set to Not Configured, then it honors any previously set setting (or the operating system default).

Enabled When a specific policy setting is enabled, the policy will take effect. In the case of the Prohibit Changing Sounds policy setting, the effect is obvious. However, lots of policy settings, once enabled, have myriad possibilities inside the specific policy setting! (For a gander at one such policy setting, use the Group Policy Management Editor and drill down to User Configuration Policies Administrative Templates Windows Components Internet Explorer Toolbars and select the policy setting named Configure Toolbar Buttons.) So, as you can see, Enabled really means “Turn this policy setting on.” Either it will then do what it says or there will be more options inside the policy setting that can be configured.

Disabled This setting leads a dual life:

● Disabled usually means that if the same policy setting is enabled at a higher level, reverse its operation. For example, we chose to enable the Prevent Changing Screen Saver policy setting at the site level. If at a lower level (say, the domain or OU level), we chose to disable this policy setting, the Screen Saver option will pop back at the level at which we disabled this policy. You can think of Disabled (usually) as “reverse a policy setting coming from a higher level.”

● Disabled sometimes has a special and, typically, rare use. That is, something might already be hard-coded into the Registry to be “turned on” or work one way, and the only way to turn it off is to select Disabled. One such policy setting is the Shutdown Event Tracker. You disable the policy setting, which turns it off, because in servers, it’s already hard-coded on. In workstations, it’s already hard-coded off. Likewise, if you want to kill the firewall for Windows XP (and later), you need to set Windows Firewall: Protect All Network Connections to Disabled. (You can find that policy setting at Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ Network ⇒ Network Connections ⇒ Windows Firewall ⇒ Domain Profile (and also Standard Profile). Again, you set it to Disabled because the firewall’s defaults are hard-coded to on, and by disabling the policy setting, you’re “reverting” the behavior back.

So, think of Not Configured as having neither Allow nor Deny set. Enabled will turn it on, and it will possibly have more functions. Disabled has multiple uses, and be sure to first read the help text for each policy setting. Most times it’s simply directly spelled out what Enabled and Disabled does for that particular setting. Last, test, test, test to make sure that once you’ve manipulated a policy setting, it’s doing precisely what you had in mind.