Related Articles
You should always ask yourself two questions when dealing with Group Policy:
- Where are you (local, site, domain, or organizational unit)?
- What are you (computer or user)?
The LSD OU rule
With these two questions, you will be able to understand how the system applies Group Policy Objects as well as which object you are attempting to add or remove settings to. Additionally, a simple acronym can help anyone understand the layering of GPOs. That acronym is LSD OU! It stands for the following elements:
L = Local
S = Site
D = Domain
OU = Organizational Unit
You can create and apply GPOs to computers and users, but most people think they only apply to domains. This is partially true, but you can configure Group Policies for local machines as well. This means you can apply GPOs in multiple ways, but GPOs will apply to a system or user in a specific order.
This specific order is the same as in the acronym: LSD OU.
LSD OU rule: L (local), S (site), D (domain), OU (organizational unit)
Local Group Policy
On your local system, you can view and edit your Local Group Policy settings by searching your computer. Using the Start Menu, begin typing (searching) for “Edit Group Policy.” You can configure settings for your local system or account, but all subsequent Group Policy layers (site, domain, and OU) that have the same setting configured or enabled can overwrite these settings.
This means you can configure Group Policies locally, but the system can overwrite them when you’ve set Group Policies to trump these settings from site, domain, or OU GPOs applied to your system or user account.
Site-based Group Policy
Now that we understand how Windows applies Local Group Policy settings, we move toward understanding how an organization that has Active Directory (AD) can apply GPOs. At the topmost layer, Group Policy Objects can apply to the “site” level. To understand how a site-based Group Policy could work, we must first generally understand how large organizations might structure their environment.
In Active Directory, we have a topmost layer called an AD forest. An organization can have multiple forests. Within each AD forest, we can have multiple domains.
Multiple AD forests and domains
If your organization has a large environment, the infrastructure design may look like the figure above. Even if you only have one domain in your environment, you can use AD sites, but you will not typically see this. You can understand an AD site as a subnet of your network. We can organize or group machines, systems, users, etc. that reside within a specific subnet. We can then apply a specific GPO to those objects even if those items do not reside in the same domain (or even forest).
Some organizations may use this feature. I have never had to use it personally, but it’s a great way to organize your GPOs across domains and forests, especially for servers that may reside in your datacenter but belong to different groups, sub-organizations, or domains.
When linking GPOs to your sites (groups) and a Local Group Policy exists with the same setting, site-based GPOs will overwrite any Local GPO settings.
Domain-based Group Policy
Domain based Group Policy Objects are far more common in organizations, mostly because setting up a new domain creates a “Default Domain Policy” at the root of that domain. This policy contains a few default settings like a password policy for your users, but most organizations change these. Additionally, some organizations modify this default policy and add their own specifications and settings.
You can definitely add to and edit the Default Domain Policy, but you may be better off just creating a new GPO at the root of your domain. If you decide to modify the existing Default Domain Policy or create a new GPO, please be aware you should apply certain settings to your root domain and not subsequent locations like OUs. It is possible to set these settings in alternate locations, but not recommended. You can only set these settings once per domain, and thus the best practice is to apply these at the root of the domain.
- Account policies
- Password policy
- Enforce password history
- Maximum and minimum password age
- Minimum password length
- Passwords must meet complexity requirements
- Store passwords using reversible encryption for all users in the domain (Noooooooooo!)
- Account lockout policy settings
- Account lockout duration
- Account lockout threshold
- Reset account lockout counter after
- Kerberos policy settings
- Enforce user logon restrictions
- Maximum lifetime for service ticket
- Maximum lifetime for user ticket
- Maximum lifetime for user ticket renewal
- Maximum tolerance for computer clock synchronization
- Network access: Allow anonymous SID/NAME translation
- Network security: Force logoff when logon hours expire
If you have a specific configuration or setting you want to apply to all systems, you should create and link that GPO to the root of your domain. This aids both visually and logically the design and layout of your GPOs. If you still want to apply a GPO to most of your systems or users, you can still create and link that GPO to the root of your domain. However, you will need to filter what the GPO will apply to.
You can filter a GPO several different ways, but the most common methods are using the Security Filtering sections on the GPO’s Scope tab or using WMI Filtering (also located on the Scope tab). By default all GPOs have Authenticated Users set as the filtering scope. (Please note Authenticated Users means both user and computer objects authenticated to the domain.) But if you wish, you can specify both (or either) a Security, Distribution, or individual objects that contain either computers or users, instead of all Authenticated Users.
As I mentioned previously, you can also set a WMI Filter that will automatically filter what objects this GPO will apply to. For example, if I wanted to apply a GPO to all laptop and mobile computers, I could add a WMI filter that would look for the existence of a battery.
WMI filter to apply a GPO only to systems with a battery
Group Policies applied at the domain level will apply to all objects that contain the specific setting you have configured. Applying either a local or site policy that includes an object (user or computer) within our domain will apply those settings first. If we set a domain-wide policy that has any portion of either a local or site GPO, our domain GPO will overwrite either of the previous settings.
In a typical organization, you will always see Account, Account Lockout, and Kerberos Policies at the root of that domain, but some choose to add other policies. For example, one could configure and add settings related to Windows Event Viewer logging across all systems. It is a best practice to create a specific policy for this setting instead of just adding it to the Default Domain Policy (but you can).
Most of your GPOs (configurations) will apply one step lower, at the Organizational Unit level. This allows for more granular control, and visually these OUs typically represent the structure of your organization (e.g. Finance, HR, Marketing, etc.).
Container-based Group Policy
Depending on who has designed or organized your Active Directory OU structure, you will typically have a set of containers or folders similar to the layout of a file system. These folders (OUs) can contain any AD object like Users, Computers, Groups, etc. Even though they contain these objects, all Group Policy Objects contain built-in filtering. When we create a new GPO, we will see there are two main configuration options available (built-in filtering). These are Computer Configuration and User Configuration. We can apply configurations to both Users and Computers within the same GPO, but we can also specify one or the other as well.
User and Computer based Group Policy
For example, let’s imagine we have a simple setup for our domain that contains the following:
Example of Group Policy order in a simple organizational structure
The Default Domain Policy will apply to all OUs and User or Computer objects that reside below where you applied the GPO (basically, in the domain). Again, typically this GPO contains all the Account, Account Lockout, and Kerberos settings for the entire domain and possibly other configurations and settings.
The second layer (Parent OU) has a Group Policy applied to it called Configure Default Logging, which applies to all Computer objects that reside within the Parent OU. This means that the Configure Default Logging policy will apply to any computers within either the Parent OU or Child OU.
The last layer is the Child OU. This OU has another GPO applied to it called Configure Child Default Logging. The Configure Child Default Logging GPO could be the same as the Configure Default Logging GPO. (You shouldn’t do this, but if you have a reason to, you can.) But let’s imagine we have decided to change the Retain application log setting for all computer objects residing under the Child OU. However, we don’t want to apply it to all computer objects within the Parent OU.
This means our Default Domain Policy will apply first to our computer. (Remember, you can specify certain settings only once and thus only apply them once). Next the settings of our Configure Default Logging policy will apply to our computer. Finally, our changes to Configure Default Logging in our Configure Child Default Logging policy will apply last. This will modify any settings that are not “set only once” settings and are within the Configure Default Logging policy.
The order in which these GPOs will apply to our computer objects is as follows:
Default Domain Policy > Configure Default Logging > Configure Child Default Logging
There are a few caveats to this processing though. These are longer topics, which I plan on writing more about soon, but these caveats include both Enforced and Block Inheritance. A GPO applied higher in the hierarchy of your AD (OU) structure has the right to enable a setting on that GPO called Enforced.
Enforced means that if any other OUs have enabled another setting (which I’ll talk about next) called Block Inheritance then that GPO will apply no matter what (even with Block Inheritance enabled). A GPO higher in the domain or OU structure that has Enforced enabled will overwrite any subordinate OUs that have enabled Block Inheritance.
To enable the Enforced setting on your GPO, you can right-click it and select Enforced.
Enforcing a GPO
To add Block Inheritance to an OU, you can select it, right-click it, and select Block Inheritance. Again, if certain settings like Account, Account Lockout, and Kerberos policies already apply, those settings will trump either one of these features since they only can apply once across your domain.
Block inheritance of GPOs to specific OUs to influence GPO order
Group Policy Best Practice
Group Policy design best practices
Group Policy is a series of settings in the Windows registry that control security, auditing and other operational behaviors. For example, Group Policy enables you to prevent users from accessing certain files or settings in the system, run specific scripts when the system starts up or shuts down, or force a particular home page to open for every user in the network. Here are Active Directory Group Policy best practices that will help you to secure your systems and optimize Group Policy performance.
Do not modify the Default Domain Policy and Default Domain Controller Policy
Use the Default Domain Policy for account, account lockout, password and Kerberos policy settings only; put other settings in other GPOs. The Default Domain Policy applies at the domain level so it affects all users and computers in the domain.
Use the Default Domain Controller Policy for the User Rights Assignment Policy and Audit Policy only; put other settings in separate GPOs.
However, even for the policies listed above, it is better to use separate GPOs.
Create a well-designed organizational unit (OU) structure in Active Directory
Having a good OU structure makes it easier to apply and troubleshoot Group Policy. Don’t mix different types of AD objects in the same OUs; instead, separate users and computers into their own OUs and then create sub OUs for each department or business function. Putting users and computers in separate OUs makes it easier to apply computer policies to all computers and user policies to only the users. It is easier to create a GPO and link it in many OUs than to link it to one OU and deal with computers or users that the policy should not affect. However, don’t plan your OU architecture based solely on how you will linking Group Policies to it.
Give GPOs descriptive names
Being able to quickly identify what a GPO does just looking at the name will make Group Policy administration much easier. Giving a GPO a generic name like “pc settings” will confuse sysadmins. For example, you might use the following naming patterns:
- Policies for user accounts: U_<name of the policy>
- Policies for computer accounts: C_<name of the policy>
- Policies for computer and user accounts: CU_<name of the policy>
Here are few examples using those naming rules:
- U_SoftwareRestrictionPolicy
- U_SoftwareInstallation
- C_DesktopSettings
- CU_AuditSettings
Create each GPO according to its purpose rather than where you’re linking it to. For example, if you want to have a GPO that has server hardening settings in it, put only server hardening settings in it and label it as such.
Add comments to your GPOs
In addition to creating good names, you should add comments to each GPO explaining why it was created, its purpose and what settings it contains. This information can be priceless years later.
Do not set GPOs at the domain level
Each Group Policy object that is set at the domain level will be applied to all user and computer objects. This could lead to some settings being applied to objects that you don’t want to. Therefore, the only GPO that should be set at the domain level is the Default Domain Policy. It’s better to apply other policies at a more granular level.
Apply GPOs at the OU root level
Applying GPOs at the OU level will allow sub OUs to inherit these policies; you don’t need to link the policy to each sub OU. If you have users or computers that you don’t want to inherit a setting, then you can put them in their own OU and apply a policy directly to that OU.
Do not use the root Users or Computers folders in Active Directory
Those folders are not OUs so they cannot have GPOs linked to them. The only way to apply policies to those folders is to link them to the domain level, but as stated above, you should avoid doing that. So as soon as a new user or computer object appears in these folders, move it to the appropriate OU immediately.
Don’t disable GPOs
If a GPO is linked to an OU and you don’t want it to be applied, delete the link instead of disabling the GPO. Deleting the link from an OU will not delete the GPO; it just removes the link from the OU and its settings are not applied. Disabling the GPO will stop it from being applied entirely on the domain, which could cause problems because if you use this Group Policy in another OU, it will no longer work there.
Implement change management for Group Policy
Group Policy can get out of control if you let all your administrators make changes as they feel necessary. But tracking changes to Group Policy can be difficult because security logs cannot give you full picture of exact which setting was changed and how.
The most important GPO changes should be discussed with management and fully documented. In addition, you should set up email alerts for changes to critical GPOs because you need to know about these changes ASAP in order to avoid system downtime. You can do this using PowerShell scripts.
Avoid using blocking policy inheritance and policy enforcement
If you have a good OU structure, then you can most likely avoid using blocking policy inheritance and policy enforcement. These settings can make GPO troubleshooting and management more difficult. Blocking policy inheritance and policy enforcement are never necessary if the OU structure is designed properly.
Use small GPOs to simplify administration
Having small GPOs makes troubleshooting, managing, design and implementation easier. Here are some ways to break out GPOs into smaller policies:
- Browser Settings
- Security Settings
- Software Installation Settings
- AppLocker Settings
- Network Settings
- Drive Mappings
However, keep in mind that larger GPOs with more settings will require less processing at log on (since systems have to make fewer requests for GPO information); loading many small GPOs can take more time. However, large GPOs can have GPO setting conflicts that you have to troubleshoot, and you’ll have to pay more attention to GPO inheritance.
Speed GPO processing by disabling unused computer and user configurations
If you have a GPO that has computer settings but no user settings, you should disable the User configuration for that GPO to improve Group Policy processing performance at systems logon. Here are some other factors that can cause slow startup and logon times:
- Login scripts downloading large files
- Startup scripts downloading large files
- Mapping home drives that are far away
- Deploying huge printer drivers over Group Policy preferences
- Overuse of Group Policy filtering by AD group membership
- Using excessive Windows Management Instrumentation (WMI) filters (see the next section for more information)
- User personal folders applied via GPO
Avoid using a lot of WMI filters
WMI contains a huge number of classes with which you can describe almost any user and computer settings. However, using many WMI filters will slow down user logins and lead to a bad user experience. Try to use security filters over WMI, when possible, because they need less resources.
Use loopback processing for specific use cases
Loopback processing limits user settings to the computer that the GPO is applied to. A common use of loopback processing is on terminal servers: Users are logging into a server and you need specific user settings applied when they log into only those servers. You need to create a GPO, enable loopback processing and apply the GPO to the OU that has the servers in it.
Use “gpresult” to troubleshoot GPO issues
The gpresult command displays Group Policy information for a remote user and computer. In addition, it breaks down how long it takes to process the GPO. This command is available only in Windows 10 and Windows Server 2016. The gpresult utility has many settings; you can view them by entering the command “gpresult /?”.
Use Advanced Group Policy Management (AGPM)
AGPM provides GPO editing with versioning and change tracking. It is part of the Microsoft Desktop Optimization Pack (MDOP) for Software Assurance and can be downloaded from https://www.microsoft.com/en-us/download/details.aspx?id=54967.
Back up your Group Policies
Configure daily or weekly backup of policies using Power Shell scripting or a third-party solution so that in case of configuration errors, you can always restore your settings.
GPO settings best practices
Limit access to the Control Panel in Windows
It’s important to limit access to the Control Panel, even if the user is not an administrator on the Windows machine. You can block all access to the Control Panel or allow limited access to specific users using the following policies:
- Hide specified Control Panel items
- Prohibit access to Control Panel and PC settings
- Show only specified Control Panel items
Do not allow removable media drives
Removable media can be dangerous. If someone plugs an infected drive into your system, it unleash malware into the whole network. In an office environment, it’s best to disable removable drives entirely using the “Prevent installation of removable devices” policy. You can also disable DVDs, CDs and even floppy drives if you want, but the primary concern is removable drives.
Disabling automatic driver updates on your system
Driver updates can cause serious problems for Windows users: They can cause Windows errors, performance drop or even the dreaded blue screen of death (BSOD). Regular users can’t switch updates off since it’s an automated feature. Windows Group Policy settings can be changed to disable automatic driver updates, using the “Turn off Windows Update device driver searching” policy. However, you must specify the hardware IDs of the devices you want to stop updates on. You can find this information in Device Manager.
Make sure access to command prompt is restricted
The command prompt is very useful for system administrators, but in the wrong hands, it can turn into a nightmare because gives users the opportunity to run commands that could harm your network. Therefore, it’s best to disable it for regular users. You can do that using the “Prevent access to the command prompt” policy.
Turn off forced restarts on your servers
If your Windows Update is turned on, you probably know that Windows pushes you to reboot the system after updating. But some users don’t turn off their computers when they leave work, so if their desktops are forcibly rebooted by a Windows Update, they can lose their unsaved files. You can use Group Policy settings to permanently disable these forced restarts.
Disable software installations by AppLocker and Software Restriction Policy
There are many ways you can block users from installing new software on their system. Doing this reduces maintenance work and helps avoid the cleanup required when something bad is installed. You can prevent software installation by changing the AppLocker and Software Restriction Group Policy settings and disabling certain extensions (such as “.exe”) from running.
Disable NTLM in your network infrastructure
NTLM is used for computers that are members of a workgroup and local authentication. In an Active Directory environment, Kerberos authentication has to be used instead of NTLM, because it is stronger authentication protocol that uses mutual authentication rather than the NTLM challenge/response method. NTLM has a lot of known vulnerabilities and uses weaker cryptography, so it is very vulnerable to brute-force attacks. You should disable NTLM authentication in your network using Group Policy to allow only Kerberos authentication, but first ensure that both Microsoft and third-party applications in your network do not require NTLM authentication.
