As administrators, we are constantly being told to log in with a standard user account unless we are performing an action that cannot be completed without administrator privileges. In fact, this best practice helps protect administrative accounts from misuse and various potential vulnerabilities. However, as every experienced administrator knows, repeatedly switching from one account to another is a hassle.
The good news is that there are ways to perform administrative tasks without logging out of your standard user account. In this article, I’ll show you a few options on how it’s done.
The case against privileged accounts
Every time you start a process in Windows, that process runs under the same security context as your account. This is why administrators are discouraged from using a privileged account unless a task requires it. For example, if an administrator accidentally triggered a ransomware infection, the ransomware would run in the same security context as the user who activated it. In other words, if the admin logs in as a privileged user, the ransomware would inherit admin privileges and wreak havoc with impunity. On the other hand, if the administrator logs in as a standard user, the ransomware would be limited by administrator privileges, or rather, the lack of them.
The same privilege restrictions that will prevent a malware attack from causing catastrophic damage also make it impossible for an administrator to do their job without a secondary privileged account. The problem with this is, of course, that it’s super inefficient for an administrator to constantly log out of one account and another. It can also sometimes be difficult to remember which account you’re logged in to, which could cause an administrator to perform a non-privileged operation (such as browsing the Internet) while you’re logged in with a privileged account.
Reduced administrative burden
There are a few things administrators can do to make their lives easier without sacrificing security in the process.
Access privilege management
If you are working in a Windows environment, one option is to use Microsoft Privileged Access Management (PAM). PAM is sometimes called just-in-time management. The basic idea is that the privileges of an administrative account are removed to make that account functionally similar to a standard user account. When an administrator needs to perform a privileged operation, they can acquire the necessary privileges long enough to complete the operation.
separate work stations
Another common strategy to limit permissions is to use two separate computers (or one physical device and two virtual machines). The idea here is that one device will be used for non-privileged operations while the other will be used for privileged operations only. The advantage of this approach is that performing privileged operations from a dedicated administration workstation and using a dedicated account greatly reduces the chances of the account being compromised. After all, the administrator will never use the privileged account to log in to a standard workstation.
run as tool
A less frequently discussed approach is to use the RunAs tool. The RunAs tool, which has been a part of Windows since Windows 2000, allows a standard user to use a privileged account to start a specific process. This technique is not without risk because it requires an administrator to enter privileged credentials while logged in as a normal user. Still, it can prevent an administrator from having to log off every time they need to perform a privileged operation.
How to use the RunAs tool
So let’s see how an administrator could use the RunAs tool to perform a privileged operation. For the purposes of this article, I will assume that the privileged operation is performed on the PowerShell command line, but this technique can be easily adapted to other situations.
The administrator starts by logging in as a standard user and then opens a PowerShell session. Because the administrator works from a standard user account, they currently lack the permissions to perform privileged operations within PowerShell.
Now suppose the administrator needs to perform a privileged operation. To do so, they would write:
The RunAs account tells Windows that the logged in person wants to run a process as a different user. The /User switch is used to specify the name of the user account to use. Finally, RunAs needs to know what kind of process to launch. In this case, I specified PowerShell as the process, but it could just as easily have been CMD (for a Windows Command Prompt window) or any other executable.
You can see an example of how this works in the following figure.
I have used the RunAs command to open a PowerShell window as another user.