Active Directory Teknik

Common mistakes administrators make when applying GPOs

Gästbloggaren Derek Melber, Active Directory MVP, berättar om hur GPO fungerar, vanliga misstag när man sätter upp GPO:er och hur man kan undvika dessa.

How does Group Policy work?

Group Policy is a great mechanism for deploying numerous settings across different Active Directory (AD) objects. But AD can become cluttered over time as more Group Policy Objects (GPOs) become unused and disabled, leading to inefficient GPO processing. In this blog we’ll discuss how Group Policy works, how GPOs can become cluttered, as well as what you can do to easily declutter your GPOs. In this first blog, we’ll start out with the basics of Group Policy application.

The setup 

Imagine that Mr. X is an employee working for ABC Corporation’s California office. Mr. X’s user account can be traced to the LDAP path of OU=UserAccounts, OU=California, DC=abc, DC=com. His computer account can be traced to the LDAP path of OU=ComputerAccounts, OU=California, DC=abc, DC=com. The GPOs that are applied to Mr. X’s user account and computer account are as follows:

User settings GPOs: Local GPO, Default Domain Policy (linked to the domain level), Printer settings policy (linked to the California OU), Network settings policy (linked to the UserAccounts OU)

Computer settings GPOs: Local GPO, Default Domain Policy (linked to the domain level), Printer settings policy (linked to the California OU), Start menu policy (linked to the computer accounts OU)
GPO-setup-how-gpos-process.png
Figure 1: GPO settings user and computer accounts.

How are GPOs processed? 

Let’s now see how GPOs are processed for Mr. X’s user account and computer account. First Mr. X’s workstation communicates with the domain controller through the SYSVOL share available on the domain controller. The GPOs targeting his workstation are then applied.

The domain controller determines the OU and site Mr. X’s workstation belongs to, and delivers the GPOs that are linked to that domain, site, and OU to the workstation. The list of these GPOs are stored, for tracking, in the registry.

The computer settings GPOs are processed in the following order: Local GPO -> Default Domain Policy -> Printer settings policy -> Start menu policy.

Once the workstation has booted and the computer configurations are applied, the workstation is ready for Mr. X to log on. According to Mr. X’s user account location in AD, the domain controller delivers the applicable set of GPOs.

The user settings GPOs are processed in the following order: Local GPO -> Default Domain Policy -> Printer settings policy -> Network settings policy.

How does the client process the GPO settings?

The client machine has client-side extension (CSE) files which process the GPO settings. Each CSE on the client machine opens every GPO and checks whether it has any settings that need to be processed.

Consider two CSEs named abc and xyz (for simplicity). While processing GPOs linked to Mr. X’s accounts, the abc CSE will check if there are any settings it needs to process in both the Computer Configuration and User Configuration settings for all GPOs. Once this is over, the process will be repeated for the next CSE and so on, until the last CSE file, xyz, finishes going through the GPO settings.

Common mistakes when applying GPOs

As a result of administrators not designing Active Directory (AD) well, further poor decisions are made when applying Group Policy Objects (GPOs). What I often see is that administrators will use security filtering for GPOs to target which objects will receive the GPO and the  settings it contains.

A key mistake administrators make when applying GPOs is using the security filtering configuration. Figure 2 illustrates what this setting looks like and where it is located.

gpo-mistakes-part-2-figure-1.png

Figure 2:. Security filtering for GPOs.

Security filtering is per GPO and alters the GPO access control list (ACL). By default, all users and computers in AD have the ability to apply every GPO, so altering this is a major change to the default behavior. Microsoft designed GPOs to apply to all AD users and computers so organizations could design their AD for GPO deployment and ease of troubleshooting. Microsoft chose to provide security filtering for those unique cases where the AD design was not sufficient for applying the settings in a targeted manner to users and computers.

Security filtering is a mistake due to the complexity it adds to not only applying GPOs, but also to troubleshooting them. Therefore, if you find yourself struggling to track down GPO application issues, it might be beneficial to look at how your GPOs are applied and how many security filters you’re using. Stay tuned for Part 3 of my blog series on common GPO mistakes!

Recovery of Active Directory

Although it’s not directly related to the application of Group Policy Objects (GPOs), administrators typically do not back up their GPOs so they can recover in case of a disaster. In fact, Microsoft only provides limited control over GPO backup and recovery, which may explain why admins overlook such required measures.

As a best practice, all administrators should do the following with regard to their GPOs:

  1. Back up all GPOs on a daily basis.
  2. Generate a report on GPOs to view all their settings.
  3. Implement a solution that allows for setting-level GPO recovery.

As an administrator, you can use the Group Policy Management Console (GPMC), the VBScripts that are provided by Microsoft, or even the PowerShell commands that are available to back up your GPOs. All of these solutions will do an excellent job of backing up the GPOs in case you need to restore them. Figure 1 illustrates how you can use the GPMC to back up all of your GPOs.

gpo-common-3-figure-1.png

Figure 3: The GPMC lets admins back up all GPOs.

With regard to generating reports for your GPOs, this is an essential step in case you need to investigate a GPO’s settings. The reason you need a report is that if the GPO setting is changed, there is no other way of knowing what the setting was. Creating a report of each GPO (by clicking “Save Report”), will include the settings, permissions, etc., as seen in Figure 4.

gpo-common-3-figure-2.png

Figure 4: Generating a report of each GPO is essential.

For each GPO, you’ll need to go through the motions of generating a report. It is also a good idea to generate an HTML version, so the GPOs can be posted on a secured site for all admins to view.

(Note: ADAudit Plus and RecoveryManager Plus can track all changes made to GPOs. RecoveryManager Plus can even restore setting-level changes to GPOs.)

The final consideration of being able to restore a GPO setting (without having to restore all settings in the GPO) is one that is rarely evaluated. Microsoft does not provide this level of restoration, even with their Advanced Group Policy Management (AGPM) tool. RecoveryManager Plus not only gives you the power to restore GPOs to any point in time, but the ability to restore just the settings in the GPO that require restoration. Figure 5 illustrates the level of detail that RecoveryManager Plus provides.

gpo-common-3-figure-3.png

Figure 5. Restoring setting-level configurations to a GPO with RecoveryManager Plus.

Be sure you don’t make a huge mistake by failing to back up your GPO environment. Being able to restore GPOs and their settings is key to the stability of your entire AD enterprise.

If you want to test RecoveryManager Plus in your own environment, download it here.

 

On-demad webinar:  Security and compliance in Active Directory 

Derek Melber

Gästbloggare. Derek Melber är Technical Evangelist på ManageEngine. Som en av få Microsoft Active Directory MVP i världen, är han eftertraktad för sin kunskap, insikt och djupgående förståelse för Windows produktutbud och särskilt Active Directory.

derek@zohocorp.com

Prenumerera på bloggen

Håll koll på senaste nytt genom att prenumerera. Vi levererar nyheterna direkt i din inkorg!