LITMIR.BIZ

Скачать книгу

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.

Скачать книгу