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

Group Policy is a twofold idea. First, without an Active Directory, there’s one and only one Group Policy available.

Officially, this policy directly on the workstation is called a local policy, but it still resides under the umbrella of the concept of Group Policy. Later, once Active Directory is available, the nonlocal (or, as they’re sometimes called, domain-based or Active Directory–based) Group Policy Objects come into play, as you’ll see later. Let’s get started and explore both options.

Then, here’s the weird thing: after I’ve fully described Active Directory’s Group Policy, we’re going to take a second visit back to Local Group Policy. That’s because with Windows Vista and later, there’s a special superpower I want to show you, but I only want to explain it after we’ve explored the first two concepts. So, in summary, here’s the short-term road map:

● Local Group Policy for Windows XP and later

● Active Directory Group Policy for all operating systems

● Multiple Local Group Policy (MLGPO) for Windows Vista and later

Trust me; it’s easier to learn it this way, even though we’re taking two passes at one concept.

While you’re plunking around inside the Group Policy editor (also known as the Group Policy Management Editor, or Group Policy Object Editor), you’ll see lots of policy settings that are geared toward a particular operating system. Some are only for specific operating systems, and others are more general. If you happen to apply a policy setting to a system that isn’t listed, the policy setting is simply ignored. For instance, policy settings described as working “Only for Windows 8” machines will not typically work on Windows XP machines. All policy settings have a “Supported on” field that should be consulted to know which operating systems can embrace which policy setting. Many of them will say something like “At least Windows XP” to let you know they’re valid for, say, XP and on.

Understanding Local Group Policy

Before we officially dive into what is specifically contained inside this magic of Group Policy or how Group Policy is applied when Active Directory is involved, you might be curious to see exactly what your interaction with Local Group Policy might look like.

Local Group Policy is best used when Active Directory isn’t available, say either in a Novell NetWare environment or when you have a gaggle of machines that simply aren’t connected to a domain.

Local Group Policy Editor

The most expeditious way to edit the Local Group Policy on a machine is to click Start ⇒ Run and type in GPEDIT.MSC. This pops up the Local Computer Policy Editor.

You are now exploring the Local Group Policy of this workstation. Local Group Policy is unique to each specific machine. To see how a Local Group Policy applies, drill down through the User Configuration ⇒ Administrative Templates ⇒ System ⇒ Ctrl+Alt+Del options and select Remove Lock Computer, as shown in Figure 1-2. As seen in the figure, the default for all policy settings is Not Configured. To make this policy setting perform its magic, choose the Enabled radio button and click OK.

When you do, within a few seconds you should see that if you press Ctrl+Alt+Del, the Lock Computer option is unavailable.

To revert the change, simply reselect Remove Lock Computer and select Not Configured. This reverts the change.

You can think of Local Group Policy as a way to perform decentralized administration. A bit later, when we explore Group Policy with Active Directory, we’ll saunter into centralized administration.

This Local Group Policy affects everyone who logs onto this machine – including normal users and administrators. Be careful when making settings here; you can temporarily lock yourself out of some useful functions.

If you’re thinking to yourself, “Yep, I’ve done that,” then stay tuned. After the next section is complete, we’ll return to Local Group Policy and discuss the idea of Multiple Local Group Policy Objects, which can help ensure that you escape from this very jam.

Before we leave Local Group Policy (for now), remember something that I stated in the introduction. That is, many of the settings we’ll explore in this book are available to workstations or servers that aren’t joined to an Active Directory domain. Just poke around here in Local Group Policy to get a feel for what you can and cannot do without Active Directory. However, many functions, like Folder Redirection settings (discussed in Chapter 10, “Implementing a Managed Desktop, Part 1: Redirected Folders, Offline Files, and the Synchronization Manager”), the Software Distribution settings (discussed in Chapter 11, “The Managed Desktop, Part 2: Software Deployment via Group Policy”), and others require Active Directory present to embrace these Group Policy directives.

You can point to other computers’ local policies by using the syntax gpedit.msc /gpcomputer:"targetmachine" or gpedit.msc /gpcomputer:"targetmachine.domain.com"; the machine name must be in quotes.

Figure 1-2: You can edit the Local Group Policy using the Local Group Policy Editor (GPEDIT.MSC).

Active Directory–Based Group Policy

To use Group Policy in the most meaningful way, you’ll need an Active Directory environment. An Active Directory environment needn’t be anything particularly fancy; indeed, it could consist of a single Domain Controller and perhaps just one Windows 10 workstation joined to the domain.

But Active Directory can also grow extensively from that original solitary server. You can think of an Active Directory network as having four constituent and distinct levels that relate to Group Policy:

● The local computer

● The site

● The domain

● The organizational unit (OU)

The rules of Active Directory state the following:

● Every server and workstation must be a member of one (and only one) domain and be located in one (and only one) site.

● Every user must be a member of one (and only one) domain and may also be located within one OU (and only one OU).

One of the most baffling questions people have when they start to dig into Group Policy is, “If a user can only be a member of one OU, how do I apply multiple Group Policy Object directives to one user?” I know it seems almost impossible based on the constraints listed, but I promise I’ll explain exactly how to do that in Chapter 2 in the section “Filtering the Scope of Group Policy Objects with Security.”

Full Windows vs. Windows RT and What It Means for Group Policy

Windows has two big flavors: full Windows and Windows RT.

Windows RT is the tablet edition that runs on ARM-based devices. Microsoft is not permitting Windows RT machines to join Active Directory. Therefore, there is no way to get Active Directory–based Group Policy on Windows RT. However, Windows RT will support Local Group Policy.

In this book we’re not going to be spending much time on Windows RT, because most of what we’ll do, we’ll do within the domain – and Windows RT machines are left out of the fun.

Windows RT has some non–Group Policy management capability so that administrators can control basic security settings. For more information about this feature, visit

http://tinyurl.com/6ufn565

Sadly, Windows RT has been out a few years (with the birth of Windows 8) and there still isn’t any way to manage these devices using Group Policy. If there ever comes a time that Windows RT machines can join the domain and get Active Directory Group Policy, I’ll write about it at www.GPanswers.com. But don’t hold your breath, as all indications suggest Windows RT will likely be depreciated and Microsoft will only be updating Windows RT to keep the lights on.

Group Policy and Active Directory

As you saw, when Group Policy is created at the local level, everyone who uses that machine is affected by those wishes. But once you step up and use Active Directory, you can have nearly limitless Group Policy Objects (GPOs) – with the ability to selectively decide which users and which computers will get which wishes (try saying that five times quickly). The GPO is the vessel that stores these wishes for delivery.

Actually, you can have only 999 GPOs applied and affecting a user or a computer before the system “gives up” and won’t apply any more.

You’ll create GPOs using the Group Policy Management Console, or GPMC for short. The GPMC can be added to a Windows Server 2016 computer or Domain Controller (see the section “Using a Windows Server 2016 Machine as Your Management Station”). The GPMC can also be added to a Windows 7, Windows 8, Windows 8.1, or Windows 10 machine via an extra download and install called RSAT. RSAT stands for Remote Server Administration Tools, and after installing it, you’ll find tools like Active Directory Users and Computers as well as the GPMC, which we’ll use right around the bend.

When we create a GPO that can be used in Active Directory, two things happen: we create some brand-new entries within Active Directory, and we automatically create some brand-new files within our Domain Controllers. Collectively, these items make one GPO.

You can think of Active Directory as having three major levels:

● Site

● Domain

● OU

Additionally, since OUs can be nested within each other, Active Directory has a nearly limitless capacity for where we can tuck stuff away.

In fact, it’s best to think of this design as a three-tier hierarchy: site, domain, and each nested OU. When wishes, er, policy settings, are set at a higher level in Active Directory, they automatically flow down throughout the remaining levels.

So, to be precise:

● If a GPO is set at the site level, the policy settings contained within affect those accounts within the geography of the site. Sure, their user account could be in one domain and their computer account could be in another domain. And of course, it’s likely that those accounts are in an OU. But the account is affected only by the policy settings here because the account is in a specific site. And logically, when a computer starts up in a new site, the User object will also get its site-based Group Policy from the same place. This is based on the IP subnet the user is a part of and is configured using Active Directory Sites and Services.

● If a GPO is set at the domain level, it affects those users and computers within the domain and all OUs and all other OUs beneath it.

● If a GPO is set at the OU level, it affects those users or computers within the OU and all other OUs beneath it (usually just called child or sub-OUs).

By default, when a policy is set at one level, the levels below inherit the settings from the levels above it. You can have “cumulative” wishes that keep piling on.

You might wonder what happens if two policy settings conflict. Perhaps one policy is set at the domain level and another policy is set at the OU level, which reverses the edict in the domain. The result is simple: policy settings further down the food chain take precedence. For instance, if a policy setting conflicts at the domain and OU levels, the OU level “wins.” Likewise, domain-level settings override any policy settings that conflict with previously set site-specific policy settings. This might seem counterintuitive at first, so bear with me for a minute.

Take a look at the following illustration to get a view of the order of precedence.

The golden rule with Group Policy is truly, “Last writer wins.” Another way to say it is, “If any GPOs conflict, the settings contained in the last-written GPO win.”

However, don’t forget about any Local Group Policy that might have been set on a specific workstation. Regardless, once that local policy is determined, only then do policy settings within Active Directory (the site, domain, and OU) apply. So, sometimes people refer to the four levels of Group Policy: local workstation, site, domain, and OU. Nonetheless, GPOs set within Active Directory always trump the Local Group Policy should there be any conflict.

If this behavior is undesirable for lower Active Directory levels, all the settings from higher Active Directory levels can be blocked with the “Block Inheritance” attribute on a given OU. Additionally, if a higher-level administrator wants to guarantee that a setting is inherited down the food chain, they can apply the “Enforced” attribute via the GPMC interface. (Panic not! Chapter 2 explores both “Block Inheritance” and “Enforced” attributes in detail.)

Note that you cannot “Block Inheritance” between Local GPOs and Active Directory GPOs. But it is true that anything you set within Active Directory to inverse a Local GPO setting is always honored. Said another way, Active Directory edicts trump local edicts. You can, however, literally “turn off” Local Group Policy Objects from processing. In Windows Vista and later, there is a policy setting found in Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Group Policy entitled Turn off Local Group Policy Object processing, which, when set to Enabled, will prevent Local Group Policy Objects from affecting the machine.

Don’t sweat it if your head is spinning a little now from the Group Policy application theory. I’ll go through specific hands-on examples to illustrate each of these behaviors so that you understand exactly how this works.

Linking Group Policy Objects

Another technical concept that needs a bit of description here is the “linking” of GPOs. When a GPO “appears” to be “created” at the site, domain, or OU level via the GUI (which we’ll do in a moment), what’s really happening is quite different. It’s created in one set “place,” then merely “linked” there. (Yes, I know there are a lot of “quotes” in the last sentence, but sometimes that’s how I “write.”)

Anyway, when you tell the system, “I want to affect an OU with this new GPO,” the system automatically creates the GPO in the fixed location and then associates that GPO with the level at which you want to affect. That association is called linking.

Linking is an important concept for several reasons. First, it’s generally a good idea to understand what’s going on under the hood. However, more practically, the Group Policy Management Console (GPMC), as we’ll explore in just a bit, displays GPOs from their linked perspective.

Let’s extend the metaphor a little more.

You can think of all the GPOs you create in Active Directory as children in a big swimming pool. Each child has a tether attached around their waist, and an adult guardian is holding the other end of the rope. Indeed, there could be multiple tethers around a child’s waist, with multiple adults tethered to one child. A sad state indeed would be a child who has no tether but is just swimming around in the pool unsecured. The swimming pool in this analogy is a specific Active Directory container named Policies (which we’ll examine closely in Chapter 7, “Troubleshooting Group Policy”). All GPOs are born and “live” in that specific domain. Indeed, they’re replicated to all Domain Controllers. The adult guardian in this analogy represents a level in Active Directory – any site, domain, or OU.

In our swimming pool example, multiple adults can be tethered to a specific child. With Active Directory, multiple levels can be linked to a specific GPO. Thus, any level in Active Directory can leverage multiple GPOs, which are standing by in the domain ready to be used.

Remember, though, unless a GPO is specifically linked to a site, a domain, or an OU, it does not take effect. It’s just floating around in the swimming pool of the domain waiting for someone to make use of it.

I’ll keep reiterating and refining the concept of linking throughout the first four chapters. And, as necessary, I’ll discuss why you might want to “unlink” a policy.

This concept of linking to GPOs created in Active Directory can be a bit confusing. It will become clearer later as we explore the processes of creating new GPOs and linking to existing ones. Stay tuned. That discussion is right around the corner.

Multiple Local GPOs (Vista and Later)

Okay, as promised, we need to take a second swipe at Local GPOs.

Starting with Vista and continuing on through Windows 10, there’s a secret superpower that takes Local Group Policy to the next level.

The last time I discussed Local GPOs, I stated this:

This Local Group Policy affects everyone who logs onto this machine – including normal users and administrators. Be careful when making settings here; you can temporarily lock yourself out of some useful functions.

True – for pre-Vista machines, like Windows XP. On Vista and later, however, the superpower feature is that you can decide who gets which settings at a local level. This feature is called Multiple Local GPOs (MLGPOs).

MLGPOs are most often handy when you want your users to get one gaggle of settings (that is, desktop restrictions) but you want to ensure that your access is unfettered for day-to-day administration.

Now, in these examples we’re going to use Windows 10, but this same feature is available on Vista and later (including Windows Server 2008 and later). It’s just not all that likely you’ll end up using it on a Windows Server.

Understanding Multiple Local GPOs

The best way to understand MLGPOs is by thinking of the end product. That is, when we’re done, we want our users to embrace some settings, and we (administrators) want to potentially embrace some settings or avoid some settings. We can even get granular and dictate specific settings to just one user.

By typing GPEDIT.MSC at a command prompt, you’re running the utility to affect all users – mere mortals and administrators.

But with Vista and later, there are actually three “layers” that can be leveraged to ensure that some settings affect regular users and other settings affect you (the administrator).

Let’s be sure to understand all three layers before we get too gung ho and try it out. When MLGPOs are processed, Windows Vista and later checks to see if the layer is being used and if that layer is supposed to apply to that user:

Layer 1 (Lowest Priority) The Local Computer Policy. You create this by running GPEDIT.MSC.

● The settings you make on the Computer Configuration side are guaranteed to affect all users on this computer (including administrators).

● The settings you make on the User Configuration side may be trumped by Layer 2 or Layer 3.

Layer 2 (Next Highest Priority) Is the user a mere mortal or a local administrator? (One account cannot be both.) This layer cannot contain Computer Configuration settings.

Layer 3 (Most Specific) Is this a specific user who is being dictated a specific policy? This layer cannot contain Computer Configuration settings.

You can see this graphically laid out in Figure 1-3.

If no conflicts exist among the levels, the effect is additive. For instance, let’s imagine the following:

● Layer 1 (Everyone): The wish is to restrict “Lock this PC” from the Ctrl+Alt+Del area in Windows 10. We’ll use the Remove Lock Computer policy setting that we already saw in Figure 1-2.

● Then, at Layer 2 (Users, but not Administrators): We say “All local users” will have Task Manager gone from the Ctl+Alt+Del screen in Windows 10.

● Then, at Layer 3 (a specific user): We say Fred, a local user, will be denied access to the Control Panel.

The result for Fred will be the sum total of all edicts at all layers.

But what if there’s a conflict between the levels? In that case, the layer that’s “closest to the user” wins (also known as “Last writer wins”). So, if at the Local Computer Policy the wish is to Remove Lock Computer from the Ctrl+Alt+Del area but that area is expressly granted to Sally, a local user on that machine, Sally will still be able to use the Lock command. That’s because we’re saying that she is expressly granted the right at Layer 3, which “wins” over Layers 1 and 2.

Figure 1-3: A block diagram of how MLGPOs are applied to a system

Trying Out Multiple Local GPOs on Windows 10

Just typing GPEDIT.MSC at the Start screen doesn’t give you the magical “layering” superpower. Indeed, just typing GPEDIT.MSC performs the exact same function as it did in Windows XP. That is, every edit you make while you run the Local Computer Policy affects all users logged onto the machine.

To tell Vista and later you want to edit one of the layers (as just described), you need to load the Group Policy Object Editor by hand. We’ll do this on WIN10.

On WIN10, to load the Group Policy Object Editor by hand, follow these steps:

1. From the Start screen, start typing MMC (which will bring up the Search box). A “naked” MMC appears. Note that you may have to approve a User Access Control (UAC) dialog message (UAC is discussed in detail in Chapter 8, “Implementing Security with Group Policy”).

2. From the File menu, choose Add/Remove Snap-in to open the Add/Remove Snap-in dialog box.

3. Locate and select the Group Policy Object Editor Snap-in and click Add (don’t choose the Group Policy Management Snap-in, if present – that’s the GPMC that we’ll use a bit later).

4. At the Select Group Policy Object screen, note that the default Local Computer Policy is selected. Click Browse.

5. The “Browse for a Group Policy Object” dialog box appears. Select the Users tab and select the layer you want. That is, you can pick Non-Administrators or Administrators, or click a specific user, or choose the Administrator account, as seen in Figure 1-4.

Figure 1-4: Edit specific layers of Windows MLGPOs by first adding the Group Policy Object Editor into a “naked” MMC. Then browse for the Windows Local Group Policy by firing up GPEDIT.MSC.

In the Group Policy Object Exists column in the Users tab, you can also tell whether or not a local GPO layer is being used.

6. At the “Select Group Policy Object” dialog box, click Finish.

7. At the “Add or Remove Snap-ins” dialog box, click OK.

You should now be able to edit that layer of the local GPO. For instance, Figure 1-5 shows that I’ve chosen to edit the Non-Administrators portion of the GPO (which is on level 2).

Figure 1-5: Below the words Console Root, you can see which layer of the local GPO you’re specifically editing.

To edit additional or other layers of the local GPO, repeat the previous steps.

Here’s an important point that bears repeating: Layers 2 and 3 of the MLGPO cannot contain overriding computer settings from Layer 1. That’s why in Figure 1-5 you simply don’t see them – they’re not there. If you want to introduce a Computer-side setting that affects everyone on the machine, just fire up GPEDIT.MSC and you’ll be off and running. That’s Layer 1, and it affects everyone.

Final Thoughts on Local GPOs

You can think of Local Group Policy as a way to perform desktop management in a decentralized way. That is, you’re still running around, more or less, from machine to machine where you want to set the Local Group Policy.

The other strategy is a centralized approach. Centralized Group Policy administration works only in conjunction with Active Directory and is the main focus of this book.

For more information, check out the article “Step-by-Step Guide to Managing Multiple Local Group Policy” from Microsoft. At last check, the URL was http://tinyurl.com/oqgl8at. The steps should work for all versions of Windows starting with Vista.

In case you’re curious, Local Group Policy is stored in the %windir%\system32\grouppolicy directory (usually C:\windows\system32\grouppolicy). The structure found here mirrors what you’ll see later in Chapter 7 when we inspect the ins and outs of how Group Policy applies from Active Directory. Windows Vista and later store Level 2 (Admin/Non-Admin Local Policies) and specific Local User Policies (Level 3) inside %windir%\system32\grouppolicyusers.

You will notice one folder per user policy you have created, each named with the Security ID (SID) of the relevant user object.