Group Policy Management and Troubleshooting Best Practices

Cybersecurity has defined the tech space over the past decade, and we don’t anticipate that changing any time soon. It’s likely cybersecurity threats will only get more advanced in 2020 as the digital landscape continues to evolve, and customers will become even more concerned about the security of their devices. Managed services providers (MSPs) will need to make sure their cybersecurity threat and data breach protocols are up to the challenge.

Luckily, we’ve seen a lot of MSPs take big steps in the right direction. Two-factor authentication (2FA), for example, is a great way for MSPs to encourage their customers to add an additional layer of security to their personal devices. What else can you do to improve operational security for your customers? Regulating user permissions with Microsoft’s Group Policy is a great place to start.

What is Group Policy?

Microsoft Group Policy is a network security tool that allows system administrators to implement certain security configurations across all users and all computers within a network. The security policies, configurations, and settings that Group Policy deploys are called Group Policy Objects (GPOs), which can be managed from a specific Group Policy Management Console or command-line interface tool. Even though GPOs can be applied directly from a Windows computer, it’s much more common to do so using Active Directory because you can centrally manage Active Directory-based GPOs as opposed to using a domain controller. Make sure you familiarize yourself with Active Directory before diving into Group Policy—you might find it easier to work with in the long run.

There are three different kinds of GPOs—local Group Policy Objects, non-local Group Policy Objects, and starter Group Policy Objects. You can combine all three of these varieties to create a security policy that fits your customers’ needs, so don’t feel pressured to commit to one type.

Local Group Policy Objects are policy objects that can only be applied to local computers and the users who log in to that computer, and they come preinstalled with Windows computers. Non-local Group Policy Objects, on the other hand, are GPOs that are applied to more than one computer or user, but only if they are linked to Active Directory. Starter Group Policy objects are templates for Group Policy that allow MSPs and sysadmins to build their own preconfigured settings that can be used as the building blocks for policies they want to make in the future.

What can you do with Group Policy?

Group Policy can be applied to a variety of different use cases, from implementing a company desktop wallpaper on all computers to making sure that only certain users have access to certain servers. This tool is especially useful for customers with a lot of workstations to maintain or with many employees spread out across the globe. With just a few keystrokes from one centralized location, MSPs can regulate user permissions and make sure everyone has access to what they need—and nothing they don’t.

From a nonsecurity standpoint, you could also:

• Assign network printers to certain users so they are prioritized amongst the list of available printers upon login
• Set all computer displays to turn off after a certain time of day in order to conserve energy
• Specify what home pages pop up when users open their internet browser

Aside from enabling quick and easy deployments across hundreds or even thousands of workstations within your domain, how does Group Policy actually work?

Group Policy applies Group Policy Objects to the organizational units (OUs) you have already designated for your system using Active Directory. A standard OU contains domain administrators, domain users, and servers. The GPO settings will apply to everything within the OU, but it is also possible to apply a GPO to only one or two objects within the OU by changing the security filters. It’s important to know that GPOs are applied recursively, meaning that any changes or settings applied to a parent OU will also be applied to sub-OUs and other objects within the domain.

The benefits of Group Policy include, but certainly are not limited to, efficient and centralized management, easy administration, and better password management and enforcement. You need to set, maintain, and enforce strict password management policies in order to keep your customers’ networks safe—but that can be hard to do across a lot of users and computers without the right tools. With Group Policy, you can predetermine password length and other requirements so you never have to worry about whether or not all the users within the domain are employing password management best practices.

However, Group Policy Objects do come with some technical limitations. These limitations shouldn’t be deal breakers for MSPs, but they are still worth taking into account. GPOs have to process actions in sequential order—local, site, domain, then organizational unit. Thus, configuring multiple GPOs can cause a bottleneck, which can negatively impact end-user experience. GPOs cannot react to sudden changes in the domain environment like network outages because they are programmed to only make changes upon startup, login, or at set intervals. You also can’t search for specific settings within a GPO, which can make GPO troubleshooting difficult. Despite these limitations, Group Policy still brings tremendous security benefits and can help ensure MSPs are helping their customers to the best of their ability.

Group Policy best practices

Group Policy troubleshooting becomes trickier if you have multiple GPOs spread out across an entire environment. When your customers’ confidential information and overall data breach preparedness are at stake, you must make sure that you’re doing everything you can to get the most out of Group Policy.

To help MSPs, we’ve compiled a list of the top seven Group Policy best practices for 2020. Keep in mind that every Group Policy configuration and Active Directory environment is different, so as you become more comfortable with the technology you’ll be able to determine exactly what works best for you and your customers. Our most tried-and-true Group Policy best practices provide a strong starting point for you to supplement with your own findings.

 

• GPO Best Practice #1: Don’t set GPOs at the domain levelRemember that GPO settings will populate to anything and everything within the domain. If you configure GPOs at the domain level, you might end up applying settings to objects you didn’t intend to. It’s safer to apply your settings at a more granular level and make changes as you go along, rather than applying them across the board and retroactively trying to fix your work when problems arise. The only GPO setting that should be applied at the domain level is the Default Domain Policy.
• GPO Best Practice #2: Apply GPOs to OUs at the root levelA GPO’s recursive structure works in your favor when it comes to working with OUs. In this scenario, you want sub-OUs to inherit the policies from the parent OU, and you don’t want to link each policy to an OU individually. Feel free to apply GPOs in broad strokes here. If you have computers or users you don’t want to inherit a setting, you can isolate them in their own OU and apply a specific policy directly to it.
• GPO Best Practice #3: Make sure you’re using a solid OU structureGroup Policy management and troubleshooting gets complicated when your OUs aren’t ordered in a logical manner in Active Directory. How exactly you go about this is up to you, but never mix different types of AD objects within the same OU. Instead, try to break out computers and users into their own OUs and then make sub-OUs for different uses and departments.
• GPO Best Practice #4: Integrate change management with Group PolicyIt’s extremely important to find a way to keep track of the changes made with Group Policy. Ensuring that only certain people have system administrator access to make changes to GPOs can help reduce confusion, but it can still be hard to keep track of changes because standard logging won’t tell you which settings have been changed and how. It’s not feasible to set off an entire change management chain reaction for each change, but MSPs should at least set up email alerts for critical GPOs.
• GPO Best Practice #5: Break down GPOs into smaller chunksAn argument can be made for using one large GPO in your domain, but that approach often does more harm than good. Although loading many small GPOs takes a little more time to load, that’s a small price to pay for easier troubleshooting, implementation, and design. Try breaking down GPOs into Security Settings, Network Settings, and Browser settings to start.
• GPO Best Practice #6: Don’t disable GPOsPermanently disabling a GPO will remove the setting from your entire environment, which could be a problem if that particular GPO is doing just fine in another OU. Instead, delete the particular troublesome GPO link from the OU instead of disabling the GPO altogether.
• GPO Best Practice #7: Use descriptive or creative GPO namesDon’t underestimate the power of having easily identifiable GPO names. Avoid generic GPO names like “pc settings” and opt for more descriptive names that reference what the GPO is being used for—not what the GPO is being linked to. Need a suggestion? Use the “U_” prefix in the GPO name for policies that will be applied to user accounts, “C_” for computer accounts, and “CU_” for both.

 

For more information on Group Policy and Active Directory read through our related blog articles.