Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Vista

Group Policy Object Overview (part 2) - Applying GPOs to a Computer and User in an AD Environment

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
3/14/2011 10:05:02 PM

Applying GPOs to a Computer and User in an AD Environment

GPOs are applied to a computer and user in an AD environment as follows.

The computer is turned on. All the Local settings are read from the files on the local hard drive that make up the Registry and the Local Computer Policy (LCP) and are placed in RAM. Again, think of this RAM copy of the Registry as the live, awake brain for this session on the computer. This is the “L” part of the computer boot-up process.

Because the computer is a member of Active Directory, it contacts a domain controller for its domain and authenticates its computer account with AD. It then compares its IP address to IP subnets configured in AD sites to identify which site the computer is currently in. The computer then downloads and reads all GPOs for the site that it is currently in and applies only the computer half of those GPOs to the RAM copy of the Registry on the computer. (At this point in the bootup process, it cannot apply the user portion because there is no way to know what user will eventually be logging on.) If any Site level settings conflict with any Local settings, the Site level settings override the Local settings. This is the “S” part of the computer bootup process.

The computer then downloads and reads all GPOs for the domain that it is a member of and applies only the computer half of those GPOs to the RAM copy of the Registry on the computer. By default, if any Domain level settings conflict with any Local or Site level settings, the Domain level settings override the Local and Site level settings. This is the “D” part of the computer bootup process.

The computer then downloads and reads all GPOs for the top-level OU that its computer object resides in and applies only the computer half of those GPOs to the RAM copy of the Registry on the computer. By default, if any OU level settings conflict with any Local, Site, or Domain level settings, the OU level settings override the Local, Site, and Domain level settings. This is the “OU” part of the computer bootup process.

The computer repeats this process for each level OU that it may reside within. If the computer object for the computer resides in the top-level OU, these are the only OU GPOs to be processed. If the computer object for the computer resides in the third-level OU, the top-level OU GPOs are processed, then the second-level OU GPOs are processed, and finally the third-level OU GPOs are processed. By default, the last GPO that gets applied overrides all conflicts with previously applied GPOs.

Again, these GPO policies get applied to the computer over the top of the Local Computer Policy settings to provide enterprise (AD) administrative dominance over the local configuration settings.

When all appropriate OU GPOs are processed, the Windows GINA dialog box is presented, and finally you are allowed to attempt to log on.

You are prompted to press and hold the Ctrl+Alt keys and then press the Del key to initialize the logon process, as shown in Figure 3. You then provide your identity information, your username and password, and click Enter.

Figure 3. You provide your identity information, your username and password, and then click Enter.


When your identity information is accepted as valid by a domain controller, you are authenticated, and the L-S-D-OU-OU process begins all over again. Only this time it uses your user profile (L) and the user half of the S, D, and OU GPOs, as follows.

The user profile settings are read from the files on the local hard drive and are placed in RAM. This is the “L” part of the user logon process.

The computer again compares its IP address to IP subnets configured in AD sites to identify which site the computer is currently in. The computer then downloads and reads all GPOs for the site that it is currently in and applies only the user half of those GPOs to the RAM copy of the Registry on the computer. If any Site level settings conflict with any Local settings, the Site level settings override the Local settings. This is the “S” part of the user logon process.

The user object can be located in a different OU and even a different domain than the computer object, but because you are logging on to the computer, you must be in the same physical location as the computer and are subject to the computer’s Site level GPOs.

The computer then contacts a domain controller for the domain that you are a member of and downloads and reads all GPOs for your domain. The computer applies only the user half of those GPOs to the RAM copy of the Registry on the computer. By default, if any Domain level settings conflict with any Local or Site level settings, the Domain level settings override the Local and Site level settings. This is the “D” part of the user logon process.

The computer then downloads and reads all GPOs for the top-level OU that the user account object resides in and applies only the user half of those GPOs to the RAM copy of the Registry on the computer. By default, if any OU level settings conflict with any Local, Site, or Domain level settings, the OU level settings override the Local, Site, and Domain level settings. This is the “OU” part of the user logon process.

The computer repeats this process for each level OU that the user account object may reside within. If the user account object resides in the top-level OU, these are the only OU GPOs to be processed. If the user account object for the computer resides in the third-level OU, then the top-level OU GPOs are processed, followed by the second-level OU GPOs, and finally the third-level OU GPOs are processed. By default, the last GPO that gets applied overrides all conflicts with previously applied GPOs.

Once again, these policies get applied to the RAM copy of the Registry on the computer over the top of the User Profile settings to provide enterprise (AD) administrative dominance over the local configuration settings.

Now you (finally) get your desktop and can begin working.

And If That Isn’t Enough: Enforced, Block Inheritance, and Slow Link Detection

With all the different GPOs that can be applied to a computer and user, some settings in the different GPOs are bound to conflict. Suppose at the site level, a GPO sets the desktop wallpaper for all computers in the site to the company logo wallpaper. And then some domain administrator sets a GPO at the domain level so that the desktop wallpaper for all domain computers is a picture of the domain’s softball team. By default, if any settings in the numerous GPOs conflict, the last GPO that gets applied wins the conflict.

This sounds like the lowliest administrator in charge of two or three computers and a few users in an OU can overrule the highest level enterprise administrator in charge of hundreds or thousands of computers and users. If left to the defaults, this is true. However, there is a setting called Enforced on each GPO. If this setting is enabled (it is not enabled by default), it locks every setting that is configured in the GPO, and no GPO that follows can override these locked settings. So with the Enforced setting enabled on GPOs, the first Enforced GPO that gets applied wins all conflicts. This is a top-down mechanism.

Another configurable setting regarding GPO processing is a bottom-up mechanism. If an administrator at a domain or some OU level does not want any previously applied, non-Enforced GPOs to affect his computers and users, he can enable a setting called Block Inheritance on the domain or the OU. This setting turns off processing of all GPOs from higher-level containers that are not Enforced. Remember, though, that a GPO with the Enforced setting enabled blows right past the Block Inheritance setting and is still processed by all computers and users in all child containers, even if the Block Inheritance setting is enabled.

One more parameter that changes the way GPOs are processed has to do with the bandwidth connecting the client computer to the domain controllers. Because some GPOs trigger a large amount of network traffic—a software deployment and folder redirection GPOs, for example—an evaluation of the bandwidth of the link to AD is performed before processing any GPOs. This is referred to as Slow Link Detection. If the link speed is below 500Kbps, the default data rate for a slow link, software GPOs do not deploy software, and folder redirection GPOs do not relocate folders. If a computer cannot identify the bandwidth of the link to AD, it assumes that it is using a slow link and may not process all appropriate GPOs, like the software deployment GPOs.

Alert

In earlier versions of Windows, like Windows XP, the client computer utilized the Internet Control Message Protocol (ICMP) Echo Request, the same function used in the PING application, to perform the slow link detection process. This became problematic when we all began blocking ICMP Echo Requests on our firewalls, due to the numerous Denial of Service attacks that used it. Client computers began to fail to identify slow links, and therefore they would fail to process all appropriate GPOs because the firewalls on the domain controllers blocked their slow link detection mechanism, the ICMP Echo Request packets.

Windows Vista has solved this problem by using a different service to identify slow links. Windows Vista uses a service called Network Location Awareness, instead of ICMP, to perform Slow Link Detection so that all appropriate GPOs are processed by Windows Vista computers.

To ensure Windows XP computers process all appropriate GPOs, you might need to allow ICMP Echo Request packets through your firewalls.


GPO Refresh, Loopback GPO Processing, and Turning Off the “L”

A few settings within the GPO also can affect the way this GPO processing happens. The first one is called the GPO Refresh. GPOs are applied to the computer during its bootup and then to the user during logon. They also get reapplied on a regular interval to ensure that new GPOs take effect quickly.

By default, GPOs refresh on member servers, member client computers, and domain users every 90 minutes, plus a random offset of 0 to 30 minutes (90 to 120 minutes). GPOs refresh on domain controllers every 5 minutes and have no random offset. These default refresh intervals can be adjusted within the GPO to affect all future refresh intervals. You can make this adjustment under User Configuration > Administrative Templates > System > Group Policy for the user refresh, and under Computer Configuration > Administrative Templates > System > Group Policy for domain member servers, domain member client computers, and domain controllers, as shown in Figure 4.

Figure 4. Determining the Group Policy refresh interval settings.

Alert

Remember that you can manually refresh GPOs by running the gpupdate.exe /force command on the target computer. The /force switch reapplies all applicable GPO settings.


Another tool within a GPO that affects the way GPOs get processed is called Loopback, and it has two modes: Merge and Replace.

 Alert

You typically use Loopback when the computer is located in a public area, and you want to minimize or eliminate any User GPO settings that might be applied to the computer session.


With Loopback Merge mode enabled, after the GPO processing described earlier (L-S-D-OU-OU-OU for the computer and then L-S-D-OU-OU-OU again for the user) completes, Loopback Merge mode kicks in and reapplies the computer settings, just in case any user settings conflict with any computer settings. Remember, the last GPO that applies wins conflicts, by default. User GPOs apply after computer GPOs by default. Loopback reapplies the computer settings to win any conflicts with user settings.

With Loopback Replace mode enabled, after the GPO processing described earlier completes, Loopback Replace mode kicks in and reapplies the computer settings, just in case any user settings conflict with any computer settings. Then Loopback Replace mode throws away every user GPO setting that has been applied, and it processes the user half of all GPOs (S-D-OU-OU-OU) that apply to the computer’s position in AD, not the user’s position in AD. The Loopback processing GPO is shown in Figure 5.

Figure 5. Using Loopback Merge mode or Loopback Replace mode to minimize or eliminate user GPO settings.


Another GPO setting that affects GPO processing is used to turn off Local Group Policy objects processing. You can access this setting under Computer Configuration\Administrative Templates\System\Group Policy in the Group Policy Management Console running on a Windows Vista computer, as shown in Figure 6.

Figure 6. Disabling the processing of the Local Computer Policy.


Alert

Enabling the Turn Off Local Group Policy Objects Processing GPO setting disables policy processing for the L part of L-S-D-OU and processes only S-D-OU.


Note

New GPOs There are approximately 800 new GPO settings exclusively for Windows Vista. You can access these new settings only by running GPMC and the Group Policy Object Editor (GPOE) on a Windows Vista computer. You cannot access these new Vista GPO settings from GPOE running on a Windows Server 2003 computer.

To be able to use and save the GPMC MMC on a Windows Vista computer, you must use a computer that is a member of an AD domain, and you must be logged in with a domain user account with sufficient privilege to create and edit GPOs.


You can access the Group Policy Management Console (GPMC), as shown in Figure 7, on a Windows Vista computer by building a new MMC.

Figure 7. Accessing the Group Policy Management Console.

Building the Group Policy Management Console (GPMC) MMC

To build the Group Policy Management Console (GPMC) MMC, follow these steps:

1.
Click Start > Run, type MMC, and click OK. (You can use Start > Start Search > MMC > and click Enter.)

2.
From the menu, select File > Add / Remove Snap-in.

3.
Select Group Policy Management snap-in and click Add.

4.
Click OK.

5.
From the menu, select File > Save As.

6.
Type the name GPMC.msc and save the MMC either on the desktop or in Administrative Tools.

To create a new GPO in the GPMC tool, follow these steps:

1.
Expand Forest, Domains, and your domain name.

2.
Right-click the folder Group Policy Objects and select New.

3.
Give your new GPO a descriptive name so that you know what is configured in the GPO.

To edit the new GPO, right-click the new GPO in the Group Policy Objects folder and select Edit. This opens the GPO in the Group Policy Object Editor (GPOE).

To link a GPO to a site, domain, or OU in the GPMC tool, follow these steps:

1.
Expand the appropriate folder to be able to view the target container.

2.
Click the desired GPO and drag it to the target container and release. This creates a link between the GPO and the container.

 Alert

The exam focuses on processing order, blocking inheritance (enforced), delegation, loopback processing modes, and so on.


Caution

Use Care When Dealing with GPOs Two GPOs are provided by default in every new domain. They are the Default Domain Policy and the Default Domain Controllers Policy. These policies are generally LEFT ALONE, with no new settings added. These policies have many carefully conceived, preconfigured settings to control and secure your domain and domain controllers (DCs).

You might make an occasional adjustment to a preconfigured setting or two inside these policies, but these changes should be carefully considered, planned, formally approved by senior IT administration, and carefully implemented. If you want to add GPO settings to the domain or to the DCs, create new GPOs with your desired settings and link them in the proper locations.

Other -----------------
- Group Policy Object Overview (part 1) - Building a Local Computer Policy & The Domain Member Computer
- User Account Control (UAC)
- Troubleshoot Authentication Issues - SmartCards
- Configure and Troubleshoot Access to Resources (part 4) - Securing Network Traffic for Remote Desktop Protocol (RDP) Access
- Configure and Troubleshoot Access to Resources (part 3) - IPSec for Securing Network Traffic on the Local LAN
- Configure and Troubleshoot Access to Resources (part 2) - Printer Sharing
- Configure and Troubleshoot Access to Resources (part 1) - Permissions
- Windows Update (part 4) - Troubleshooting Updates
- Windows Update (part 3) - Windows Server Update Services Server (WSUS)
- Windows Update (part 2) - Automatic Updates
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server