Group Policy. Jeremy Moskowitz
Чтение книги онлайн.
Читать онлайн книгу Group Policy - Jeremy Moskowitz страница 9
Название: Group Policy
Автор: Jeremy Moskowitz
Издательство: John Wiley & Sons Limited
Жанр: Зарубежная образовательная литература
isbn: 9781119035688
isbn:
● 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 СКАЧАТЬ