Local Group Policies are one of the more underutilized features for keeping Windows 10 machines secure. Local Group Policies are very similar to the Group Policy settings that are a part of the Active Directory. Unlike Active Directory-based Group Policy objects, however, local Windows Group Policies apply only to a computer’s local operating system, and they are not designed to be centrally managed.
To see how local Windows Group Policies can help to improve an organization’s security, it is necessary to understand a bit about how Active Directory Group Policies work.
The Windows Group Policy objects that exist within the Active Directory are hierarchical in nature. Policy settings can be applied either to the computer or to the user (or a combination of the two), and policy settings can be applied at various levels of the Active Directory: local, site, domain and OU.
The first thing that must be understood is that even if an organization has Windows Group Policy objects at all four levels, there is no guarantee that all four of these Group Policy objects are going to apply to a given user. For that to happen, the user account and/or computer account would have to reside in a domain, site and OU for which a group policy object has been defined. For this particular example, let’s assume that all four Group Policy objects apply to a particular user.
When the user logs in, the local Group Policy will be immediately applied. Next, the site level policy will be applied. The site level policy does not necessarily negate the local policy. If the site level policy contains settings that did not exist within the local policy, then those settings will be added to the settings that were already applied by the local policy. Conversely, if the local policy contains settings that are not defined within the site level policy, then those settings will remain in effect because the site level policy did nothing to remove them.
So, what happens if a particular setting is defined in both the site-level policy and the local policy, but the two policies are contradictory with regard to that setting? When this happens, Windows uses a “most recent change wins” model. What this means is that if two policies contain contradictory settings, then the higher-level policy (the one that is applied last) takes precedence for that particular setting. Because the site policy exists at a higher level than the local policy (and is applied after the local policy), it will override a setting within the local policy in the event that the two policies are contradictory for that particular setting.
This precedence model works in the exact same way for domain and OU level policies. The local Group Policy is considered to be the lowest-level policy object, with the site policy object being just above it, the domain policy object existing above the site policy object, and the OU level residing at the top of the hierarchy. When a user logs on, all of the applicable Group Policy objects combine with one another according to this model to form the resultant policy. The “resultant policy” is essentially just Microsoft-speak for the policy settings that ultimately apply to the user and to their computer.
So, if the local Group Policy is at the bottom of the hierarchy, why should an organization bother to use it? There are actually a couple of reasons. For one thing, the local Group Policy can provide protection in the event that a user logs in using a local account rather than a domain account. In such a situation, none of the Active Directory policies would apply, but the local Group Policy object would still be in effect. This is an especially important consideration because so many users are working remotely rather than logging directly into a Windows domain.
Another reason why organizations should use the local Group Policy is because it provides a degree of protection against Active Directory tampering. Imagine that an administrator within your company accidentally deleted a couple of settings within the Default Domain Policy. If those settings had also been defined at the local Group Policy level, they would remain in effect for domain-joined devices.
One of the main reasons why many organizations shy away from using local Group Policies is that they are not designed to be centrally managed. While this can be a challenge, local Group Policy settings can be integrated into automated Windows deployments, making it much easier to put those policy settings into place on Windows devices.
