How Endpoint Privilege Management Helps System Administrators

System Administrators routinely need access to network/remote resources to manage, troubleshoot, or stand up networks, as well as maintaining a stable internet connection. They are also responsible for monitoring data to proactively detect anomalies or other issues. As a company, you want your System Administrators to have the ability to run or install diagnostic applications and troubleshoot network-related issues on employees’ systems. These activities can be performed either at the console level or remotely. In many companies, the terms System and Network Administrators are used interchangeably. System Administrators are often granted administrator rights or have the credentials for a secondary account with them (e.g. adm%username%, admHelpDesk1). This practice makes your organization susceptible to security threats. If a malicious user/attacker retrieves these credentials, your organization’s networks, infrastructure, and data would all be compromised. Given the breadth of the System Admins’ responsibilities, there isn’t one list of network admin tools that satisfy all. Some admins may prefer to use Wireshark, while others get what they need from WinPCap. I’ve known admins who love CLI/PowerShell and some who just feel more comfortable using a GUI. At the end of the day, they all have similar goals and your company’s security policy shouldn’t be the reason they can’t achieve them. Let’s take a look at a few examples and what that looks like from a least privilege perspective.

Configuring a Network

Network Configuration is among the most common tasks in an admin’s life. Whether they need to make a simple settings change or diagnose a network outage, these operations require the process, at least in part, to be run as an administrative user.

Using PowerBroker for Windows’ Logging capabilities, we can see the process, ‘Netshell.dll' prompted for administrative credentials, which, in the least privilege model a user would not have the authority to move past.

Allowing approved users to run this application is easy — all that’s needed is to create a rule that targets netshell.dll for these users.

And now when they attempt to view or change network configuration settings, they can. This operation doesn’t require having access to secondary admin or additional service accounts on the system.

Installing Network Software

Often a Sys Admin needs additional software to assist in troubleshooting issues on user machines or servers. Most of these installs require administrative rights to run properly. When we run an install that requires admin rights while logged in as a standard user, we see a similar result as with Network Configuration.

Even though this is an installer, whereas running Network Config was an application, the process is the same to allow users to run it. We see in the logging where UAC prompted and can easily create a rule to allow this.

With the rule in place, WinPCap installs the same as if the user had administrative rights, but everything is still run in the logged-on user’s context.

With the rule in place, WinPCap installs the same as if the user had administrative rights, but everything is still run in the logged-on user’s context.

Running PowerShell Scripts Running PowerShell scripts to diagnose issues can be different than running other applications or installers. With other diagnostic applications, they are focused on the local machine. With PowerShell, this is not always the case. Sometimes, information from a remote machine needs to be gathered, or changes must be made. In these cases, a standard rule may not be enough. The script needs to be launched as a user with the appropriate permissions on the remote host. Let’s look at a simple example. I just want to list all services from a remote host that are stopped. When I launch this as a user with limited rights on the remote computer it fails.

Because the elevated rights are required on the remote machine, I can’t use a default rule action in PowerBroker for Windows. Instead, in combination with PowerBroker Password Safe, I will ask for the script to be launched with alternate credentials. Please note, the user will not need to know what these credentials are, nor will they be exposed during this process.

And the result is a successful launch of the script:

These are a few examples of how PowerBroker for Windows can help protect privileged access to common System Admin activities. To learn more about PowerBroker for Windows can help eliminate the need for administrative access, even for the most complex of use cases, download our latest white paper, “The CISO’s Guide to Managing Risk for Privileged Access & Credentials in Windows Environments”. Additionally, you can watch our recent webinar on best practices for managing windows privileged accounts via on-demand.