Group Policy. Jeremy Moskowitz

Чтение книги онлайн.

      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.

      An Example of Group Policy Application

      At this point, it’s best not to jump directly into adding, deleting, or modifying our own GPOs. Right now, it’s better to understand how Group Policy works “on paper.” This is especially true if you’re new to the concept of Group Policy, but perhaps also if Group Policy has been deployed by other administrators in your Active Directory.

      By walking through a fictitious organization that has deployed GPOs at multiple levels, you’ll be able to better understand how and why policy settings are applied by the deployment of GPOs.

Let’s start by taking a look at Figure 1-6, the organization for our fictitious example company, Example.com.

      This picture could easily tell a thousand words. For the sake of brevity, I’ve kept it down to around 200. There are two domains: Example.com and Widgets.example.com. Let’s talk about Example.com:

      Using Active Directory Sites and Services, you can put in place a schedule to regulate communication between EXAMPLEDC1 located in California and EXAMPLEDC2 located in Phoenix. That way, the administrator controls the chatter between the two Example.com Domain Controllers, and it is not at the whim of the operating system.

Figure 1-6: This fictitious Example.com is relatively simple. Your environment may be more complex.

      Another domain, called Widgets.example.com, has an implicit transitive two-way trust to Example.com. There is only one Domain Controller in the Widgets.example.com domain, named WIDDC1, and it physically resides at the Phoenix site. Last, there is MarksPC, a member of the Widgets.example.com domain, and it physically resides in the New York site and isn’t in any OU.

      Understanding where your users and machines are is half the battle. The other half is understanding which policy settings are expected to appear when they start logging onto Active Directory.

      Examining the Resultant Set of Policy

      As stated earlier, the effect of Group Policy is cumulative as GPOs are successively applied – starting at the local computer, then the site, the domain, and each nested OU. The end result of what affects a specific user or computer – after all Group Policy at all levels has been applied – is called the Resultant Set of Policy (RSoP). This is sometimes referred to as the RSoP calculation.

      Throughout your lifetime working with Group Policy, you will be asked to troubleshoot the RSoP of client machines.

      Many of our dealings with Group Policy will consist of trying to understand and troubleshoot the RSoP of a particular configuration. Getting a good, early understanding of how to perform manual RSoP calculations on paper is important because it’s a useful troubleshooting skill. In Chapters 3 and 7, we’ll also explore additional RSoP skills – with tools and additional manual troubleshooting.

      Before we jump in to try to discover what the RSoP might be for any specific machine, it’s often helpful to break out each of the strata – local computer, site, domain, and OU – and examine, at each level, what happens to the entities contained in them. I’ll then bring it all together to see how a specific computer or user reacts to the accumulation of GPOs. For these examples, assume that no local policy is set on any of the computers; the goal is to get a better feeling of how Group Policy flows, not necessarily what the specific end state will be.

      At the Site Level

      Based on what we know from Figure 1-6, the GPOs in effect at the site level are shown here:

      If we look at the graphic again, it looks like Dave, for instance, resides in California and Jane, for instance, resides in Delaware. But I don’t like to think about it like that. I prefer to say that their accounts reside in OUs.

      But users are affected by site GPOs only when they log onto computers that are at a specific site.

      In Figure 1-6, we have Dave’s and Jane’s accounts in the Human Resources OU. And that’s great. But they’re only affected by California site-level GPOs if they travel to California. It doesn’t matter where they usually reside; again, they’re only affected by the site-level GPOs when they’re physically present in that site. So if they travel to California, they will get the GPOs related to California first; then other GPOs (described later) will apply.

      So, don’t think that user accounts reside at the site level. Rather, they reside in the OU level but are using computers in the site and, hence, get the properties assigned to all users at that site.

      Sites are defined using the Active Directory Sites and Services tool. IP subnets that constitute a site are assigned using this tool. That way, if a new computer turns on in Delaware, Active Directory knows what site СКАЧАТЬ