Contents:
In this article, you’ll find what group policy objects are, how many types exist out there, the benefits and limitations of group policy objects, examples of GPOs, how you can create a new group policy object, and how our solution can help you with this.
To understand what a group policy object is, we must first clarify what a group policy means.
What Is a Group Policy?
Group Policy is related to Windows, it is basically a Windows feature that contains a number of complex settings in the Windows registry. These can be helpful for network admins to gain control over the users’ and computers’ working environment in the Active Directory.
What does this have to do with group policy objects?
What Are Group Policy Objects?
Group Policy Objects, also known as GPOs, are basically a collection of rules, a virtual policy settings compilation. Group policy objects form a collection of policy settings: computer-related policies and user-related policies that have the role of defining the behavior of computers or users in an Active Directory environment. Basically, through a GPO you establish a set of settings in order to configure your clients and servers and draw user-designed rules in your company. Each Group Policy Object will have an exclusive name.
Group Policy Objects Types
Group Policy Objects can be divided into 3 types:
Local Group Policy Objects
These indicate the number of group policy settings that will only be valid for the local computer and to all the users who will be going to log on to the local PC, so that will be locally enforced on the Windows client. Therefore, they are a set of key/value pairs that implement a general-purpose configuration store for an individual computer.
If policy settings need to be implemented only for one Windows computer or just for one user, this is when this type of GPOs is of use. It’s also worth mentioning that they will be found by default present on all Windows computers.
Non-local Group Policy Objects
The second type of GPOs refers to, as the name itself says, the opposite of the first one mentioned above. Now, the GPOs will be applied not just to one Windows computer or user, but the policy settings will be implemented to multiple computers or users. And these policy settings will be enforced only when linked with Active Directory containers that can be sites, domains, or OUs (organizational units).
Starter Group Policy Objects
We’ve come to the third type in this section. This last type of GPOs, basically nonlocal GPOs, are templates particularly useful when creating in the Active Directory a new GPO. To put it simply, these help admins build a group of settings that are pre-configured. For instance, the Starter GPO will pre-populate the mandatory settings from the previous one when a new GPO is created.
Group Policy Objects Levels
Group policy objects are a way to configure and enforce computer and user settings on a domain. We can speak of a GPO as divided into 2 parts: the computer configuration level and the user configuration level. These could also be called nodes.
Computer Configuration Group Policy Objects: they set computer configuration policies such as folder redirection, disk quotas, process handling, event logs size, or network settings.
Here you can find policy settings that apply only to, guess what, computers, like, for instance: scripts on startup or shutdown actions or local firewall configuration control settings. This particular node is relevant only for computers, so if a set of rules apply to that computer, no matter what user is logged on, those policy settings will be enforced.
User Configuration Group Policy Objects: they set the user configuration policies, so settings associated with the user accounts such as folder redirection, drive letter mappings, printers, scripts startup programs, desktop layout, start menu, and many more.
If we talked before about computer policy settings, here we have only users policy settings, therefore settings that will be valid only for users like, for instance: scripts related to log on and log off actions or some that define the Control Panel’s access. So, unlike the above node, when no matter the user, the computer configuration will be enabled whatsoever, here is the opposite: the user configuration will be enforced on a user-based level, no matter what machine a user logs on to.
Here it’s interesting to mention what’s the core difference between computer configuration group policy objects and user configuration group policy objects. And the difference lies in the time of the appliance. The first ones apply when the system is booted, the latter when users log on to the domain.
GPOs Processing Order
It’s interesting to also mention here what order takes each GPO because yes, they do run by rules and this has the LSDOU acronym associated: first comes the local computer policy, closely followed by active directory policies which are those related to sites and domains and last the ones associated with organizational units. And if you might wonder what happens if there are any conflicts in the running process whatsoever, be aware that the last enabled policy will always take precedence over the previous.
The order of appliance of a GPO to a certain domain can be managed if you change the order of the links: as in the order above, the lowest link takes precedence, you can block the inheritance, as the child OUs will always inherit the parent GPOs, you can set a GPO link to Enforced to prevent the overwriting of child OUs over parents OUs, and of course, a GPO can be prevented to be applied for a certain container if the link to that container will be disabled.
However, you must keep in mind that every non-local GPO takes effect only when linked to an Active Directory container. In this sense, linking a GPO to various AD containers is possible.
Group Policy Objects Examples
Let’s take some GPOs examples to better understand how these work.
Example 1
Let’s say a user opens Internet Explorer. GPOs can make that the first displayed page to be the same home page for all users that log on to that network.
Example 2
Let’s say there is a specific Active Directory OU that contains only certain users. Through Group Policy, all those users from that OU will have a default network printer preinstalled.
Simply put, this means that the first network printer available a user that logs on into Windows will see will be the one predefined through the settings of that specific Group Policy.
Why Do You Need Group Policy Objects?
You might wonder why a company needs group policy objects. The primary goal of an organization is its cybersecurity. Because, if systems and users are protected and well managed, the business will be up and running, as simple as that.
Group Policy Objects (GPO) are a helpful way to ensure consistency across computers in your organization. They let you configure settings for the computer, such as the background wallpaper, screen saver, and desktop icons.
They also provide a way to enforce restrictions on users and groups in your organization so they don’t have to remember multiple passwords and account names. You can use them to require strong passwords or keep accounts from having full access rights on the computer.
Here are the benefits and limitations of group policy objects you should be aware of.
Benefits of Group Policy Objects
Group Policy Objects are important for an enterprise, because, with their help, this can secure its IT core infrastructure and take care of its management by:
- blocking software deployment: let’s say a user wants to install certain software on their computer. Maybe they do not have bad intentions, however, they wouldn’t know if that’s malware inside that program or not. Preventing software installation would only not let malware propagation happen.
- preventing users’ access to specific resources for better security. Here we can mention the principle of least privilege: give the users the access they need to perform a certain task and nothing beyond. For example, you can disable the local admin rights and give admin privileges on a role basis level.
- restricting the Control Panel’s access: we all know that a computer can be managed through the control panel, so this is the most exposed to threats, keeping data safe here being not only a matter of restrictions but also a necessity for continuous security preservation.
- command prompt disablement: through command prompts users in a company could be granted a superior access level, so there’s always the risk of system security measures bypassing.
- being relatively easy to understand the objects you are applying. This means that it is easier to audit what was applied at any given time, which can be advantageous for companies with strict compliance requirements.
In a nutshell, the benefits of group policy objects are: better security, better management over users’ rights and their passwords, and over-computer behavior as a standardized environment will prevent wasting time with setups and let your sysadmins deploy patches or make any updates they want via GPOs.
Limitations of Group Policy Objects
- laborious maintenance: since there are no filters or certain options to search through GPOs, it’s hard to find a certain setting that has issues in order to fix it.
- the successive order: GPOs are not multitasking, so they run one after the other, not at the same time. This means that a log-on can take forever if many GPOs are put in place.
- No setting changes tracing: if somebody makes changes to a GPO, this will not be registered. So, there’s no tracking possible: like to know who made a change and when a change was made. And this is particularly dangerous as can lead to security breaches. For example, a threat actor could alter a GPO for brute force attack purposes, perform data theft if the option use removable media drives is enabled, propagate malware, make the websites listed in the browser of the user be replaced with malicious ones or at computer startup or shutdown a malicious script could be run. It’s easy for them to do this, as all it takes is access to a privileged account.
- the GPO editor is not such a user-friendly console.
- local GPOs are prone to lateral movement cyberattacks: local GPOs can be altered by a hacker who intends to laterally move onto the network (a solution that monitors and audits the Group Policy can help with this).
GPOs Best Practices
Here are some best practices you need to follow when creating and managing Group Policy Objects:
1. A simple Active Directory OU structure
The purpose of an organizational unit (OU) structure is twofold: first, it simplifies your AD environment for administration work; second, it can limit what administrators can do in certain areas of your AD forest. So having a simple OU structure will let you avoid mixing AD objects. Users and computers should be treated as two separate categories, as each category should have its own OUs. This will simplify your GPO management.
Original names that indicate what’s inside a GPO and comments on creation reason and settings types are also helpful for an organized setup. For instance, computer policies could go by the rule: C_<name of the policy> and user configuration can follow the naming rule of U_<name of the policy>.
2. GPOs should not be set at a domain level
Beware of domain-level GPOs: it’s better to skip setting up GPOs at the domain level. Why? Because if you do so they will have effects on all users and machines in that domain and this can lead to unnecessary policies being applied where it’s no need for.
3. GPOs should not be disabled
Avoid GPO disablement: you know that a GPO in order to have an effect, has to be linked with an OU, and group policies can be linked to more AD OUs. So, logically, if you disable the entire GPO, this will have effects at the domain level. You can just delete that specific OU link.
How to Create a Group Policy Object
To create Group Policies you need to use the Group Policy Management Console (GPMC). This is basically a free group policy editor provided by Microsft that will let you manage your GPOs.
There are two default GPOs whenever an AD is created: the Default Domain Policy and the Default Domain Controllers Policy. The first sets up rules for computers and users focusing on policies like account lockout, Kerberos, and password policies. The latter is related to the domain controllers from a domain as it draws baseline settings for these.
Here is how you can create a group policy object and keep in mind that you have to log in with a user account that allows you to create this:
You should go to Start –> then choose Administrative Tools –> then choose Group Policy Management.
In the dropdown find the Group Policy Objects node linked to your domain. For this, you should expand your Active Directory forest to Domains.
You should right-click on Group Policy Objects, select New, choose a name and then press Ok.
In the left pan, you must expand the container of Group Policy Objects, right-click on the GPO you created, and then select Edit in order to open the Group Policy Management Editor window and set up whatever settings you need.
To link a GPO with a setting you’ve configured, you should go to the organization unit named Domain Controllers, right-click on it, then Domains, then the option: Link a GPO.
How Can Heimdal™ Help You?
Speaking of a centralized environment on a user and computer basis level, Heimdal™ has two solutions (among others) that help you better deal with rights management and application control. These are Privileged Access Management and Application Control.
With Privileged Access Management, you can grant users several permissions. This also immediately deescalates rights whenever a suspicious activity is detected. With PAM you can build a flow of approvals and denials, define individual permissions per Active Directory group or in association with the escalation periods, you can also delete local elevated rights, basically a set of steps that will create a better vulnerability mitigation surroundings as the most system flaws flood through high-privileged accounts.
On the other hand, Application Control allows you to make your denial or approval flows even more efficient and faster by setting default rules, and it works both in active and passive mode.
Now, how do these solutions help with GPOs? If you like them, you get the solutions and then deploy the Heimdal Agent through a GPO from Active Directory. You follow the above steps and create a new GPO with the name Heimdal. Make sure you have previously installed the Heimdal MSI Installer in a shared folder. Then you open the Group Policy Editor on the created GPO and just select the Heimdal MSI Installer in the Computer Configuration section and then the same MSI in the User Configuration section. This way, the Heimdal Agent can be deployed and installed through the created GPO in your IT environment. For more information on this topic, you can also visit our Support Page.
If you enjoyed this article, because we know that you surely did, don’t forget to follow us on Linkedin, Twitter, Youtube, or Instagram to never miss a thing we post.
Heimdal® Privileged Access Management
- Automate the elevation of admin rights on request;
- Approve or reject escalations with one click;
- Provide a full audit trail into user behavior;
- Automatically de-escalate on infection;
Hi! My name is Andra and I am a passionate writer interested in a variety of topics. I am curious about the cybersecurity world and what I want to achieve through what I write is to keep you curious too!
