Group Policy Best Practices

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. You can take a look at how you can track changes to Group Policy in the Group Policy Auditing Quick Reference Guide.

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 or, more conveniently, with IT auditing software like Netwrix Auditor for Active Directory.

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.