4 Steps to Managing Local Admin Rights

We’ve always known leaving the local user with admin rights was never a good idea. If your business is still in “break/fix” mode, you may have quite a few users left with admin rights because it’s much easier for you to fix their problems remotely. I completely get that—we’ve all been there. 

But, when the reality of risk around both external and internal attacks sets in, you quickly realize that giving out any kinds of elevated permissions can have dire consequences. All an external attacker needs is local admin rights to establish a foothold in one of your customer’s environments. Same goes for ransomware—give it admin rights and everything from files up to the bios can be affected. While it’s tempting to give out admin rights, you could be asking for trouble.

So, what are some of the ways to manage local admin rights?

First off, the answer is a really big “it depends,” because not every MSP business runs the same.  So, for the purposes of this article, I’m going to start with some simple recommendations and then move towards the more taxing (and expensive) ones. 

Let’s start with taking away admin rights from the user.

Step 1: Implement Least Privilege

The first step is determining what privileges—beyond that of a local admin—do users really need. In nearly every case, none of your users truly needs elevated privileges. So, we begin with ensuring that users have no local admin rights. A simple run of the command net local group administrators, and you’ll have yourself a list of anyone with local rights. The idea behind least privilege is to assign each user as little privilege as possible. So, instead of “reaching high” on this one, “go for low.”

Step 2: Implement User Account Control

If you want to allow users to make certain OS changes, the best way to facilitate this from a security perspective is to separate out a user’s “regular” user account (for use when they are surfing the web, running Office apps, etc.) and give them a separate local admin account for when they need to make changes to the OS. Configure UAC to prompt for credentials when an operation requires elevated privileges—that way, they aren’t using elevated privileges all the time, and they need to authenticate as the admin for changes that could impact the OS to be made.

Step 3: Implement Privilege Management

UAC is only good for OS changes. Should a user require elevated privileges for a specific application, for example, you’ll need to take things a step further and look for a privilege management solution. These solutions define local policies of who and when elevated privileges are to be allowed. For example, say a payroll user uses an application that requires local admin rights. A privilege management solution can be configured to have the application run with elevated privileges while the user remains a regular user.

Step 4: Implement Privileged Account Management (PAM)

One of the problems with Least Privilege and UAC is that when local admin accounts are used (regardless of whether the user logs on with the local admin account, uses UAC, etc.) credential artifacts—such as clear text passwords, password hashes, and Kerberos tickets—all remain in memory. Cyberattackers know these artifacts exist and, should they be able to compromise a single local admin account, the credentials can be gathered and then utilized to access further systems within your network.

This is why you may need to look at a PAM solution. While PAM solutions have many features, I want to focus this blog on just two: a password vault and an ability to rotate passwords automatically. Here’s the idea, a user must authenticate into a PAM solution as themselves. They are then given a local admin account’s credentials from the vault to use to either log on with, or authenticate via UAC, etc. Once the user is done using the admin account, they check it back into the PAM solution, at which time the password is changed and the local admin account is updated.

This puts the attacker at a severe disadvantage: should they be able to access any credential artifacts, none of them are valid any longer (because the passwords have all been changed by the PAM solution upon check-in).

Putting a Lockdown on Local Admin Rights

Regardless of whether you follow all four steps or not, doing something is better than leaving your users with local admin rights. You can offer each step as an additional tier of service, layering on deeper and deeper levels of security. Based on the needs of the customer and the security service offering tier they’ve signed up for, by following one or more of the steps above, you’ll have a much better handle on both who has local admin rights and how they are used.

 

Nick Cavalancia has over 20 years of enterprise IT experience and is an accomplished executive, consultant, trainer, speaker, and columnist. He has authored, co-authored and contributed to over a dozen books on Windows^®, Active Directory^®, Exchange^™ and other Microsoft^® technologies. Nick has also held executive positions at ScriptLogic^®, SpectorSoft^® and Netwrix^® and now focuses on the evangelism of technology solutions.

Follow Nick on Twitter^® at @nickcavalancia

 

Click here to find out how SolarWinds MSP is using Machine Learning to help MSPs protect their customers and also do their jobs more effectively.

 

© 2017 SolarWinds MSP UK Ltd. All rights reserved.