Securing windows 10 with local group policy
When it comes to quickly making wide-ranging modifications to Windows systems, Group Policy is usually at the top of the list for ease-of use and raw power. The problem is that most people think of Group Policy as this all-encompassing voodoo that is only for large organizations and massive domains.
To be fair, those are great examples of groups that depend on Group Policy, since it is extremely difficult to properly manage that many workstations individually without help. What many don’t realize, however, is that Group Policy still is available at a local individual workstation level. You don’t necessarily need to have a Domain Controller and complex GPOs to help secure workstations: Local Group Policy can still help in situations where you can’t or won’t be able to deploy from a central source.
We’re going to be going over some of the basics of Local Group Policy, as well as what it can and cannot do.
PLEASE BE AWARE: Local Group Policy (like standard Group Policy) is not present or supported by Microsoft on Windows 10 Home. There are ways to get around this, but they are very hit-or-miss and are actively discouraged by Microsoft. Please keep this in mind if you are attempting to do this on a Windows 10 Home system.
Group policy hierarchy
To start with, Local Group Policy is at the beginning of a very long chain of Inheritance. When a computer is booting up or a user is logging on, Group Policies begin to be applied. Local Group Policies are applied first before all others, but while this would make you think that they take precedence, they actually have the least impact of all forms of Group Policy.
Local Group Policies run first, followed by Site-Level Policies, Domain-Level Policies and Organizational Unit (OU) Policies. Unless otherwise specified, the OU-level policies have the last word when it comes to settings — they have the ability to override anything that comes before them.
This doesn’t mean, however, that using functions at the local level has no meaning. It is still possible to make powerful changes that affect only a single system at a time and use the tools that Group Policy provides.
Viewing and applying Local Group Policies
We’ll start by accessing the Local Group Policy Editor. To do this, click on Start and type gpedit.msc. You may or may not have this available to you, depending on your local permissions.
This brings up the basic format that all Group Policy Objects (GPO) conform to and can be divided into two key areas: settings that apply to the local computer and settings that apply to local users. Computer-based policies usually run at boot time and can modify applications, security options and core Windows functionality. User-based policies will tweak permissions that users have and deploy objects to users automatically, based on memberships and other filters.
Let’s say, for example, that because this workstation is in a bit of a general access area, we wanted to not only disable the built-in local administrator account, but we also wanted to rename it to make things just that bit more difficult for someone trying to break in. We can do this by going to Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options. Once we are there, the two particular settings that we are looking for are Accounts: Administrator Account Status and Accounts: Rename administrator account.
If we open up “administrator account status,” this will allow us to quickly disable the local admin account.
Likewise once we open up “Rename admin account,” this allows us access to change the username used to login with the local admin account.
Bear in mind that if you are currently logged in with this account, you’re going to want to log out and log back in before making any other changes. This is because you are left in a sort of limbo state where very strange things can happen if there isn’t a clean session active.
But why are we bothering with locking down the local admin account anyway? What difference does it make?
The problem with local admins
Local admins have total control of the workstation. This means that if we make changes at the Local Group Policy level, they can just log back in and change them back if they choose. This is why if at all possible, users need to run with “Least Permissions” — or the minimum required permissions to do their tasks. This isn’t because of animosity or fear towards the users, but because some very bad things can happen if their credentials get into the wrong hands.
Windows being Windows, however, we’ve had decades where standard practice was to give users local admin rights simply because the programs they were running demanded it. While this has changed drastically over the years, there may be significant push-back from users when it comes to this sort of thing.
Local Group Policies have the potential to fix situations on workstations extremely quickly and with little hassle. Realistically, the only true difference between Local Group Policies and traditional ones is that of scale: if you spend time working with Local Group Policies, you will be significantly more comfortable when you start working with larger scale ones.
The last point we need to make on this is that Group Policy is not some strange set of rules that only work in this one key space via this interface. Everything that Group Policy does is via the registry, albeit in a much more refined and easier-to-handle package.
If you do find yourself on a Windows 10 Home machine and need to make changes similar to those that can be done via Local Group Policy, you certainly can attempt to do so. It just may take significantly longer and require quite a bit of research. Making changes directly in the registry can lead to significant problems, so please be sure to back up your registry before making any changes.
- Windows 10 Local Security Policy Editor, Business News Daily
- Top 10 Most Important Group Policy Settings for Preventing Security Breaches, Lepide
- Configure security policy settings, Microsoft
- Windows security baselines, Microsoft
- 6 Group Policy Settings You Need to Get Right, blog.netwrix.com
- Bypassing Active Directory Group Policy, blog.cdemi.io