As administrators, we are constantly being told we need to log in using a standard user account unless we are performing an action that cannot be completed without administrator privileges. This best practice does indeed help to protect administrative accounts against misuse and against various potential exploits. However, as every seasoned administrator knows, repeatedly switching back and forth between accounts is a pain.
The good news is that there are ways to perform administrative tasks without logging out of your standard user account. In this article, I will show you a few options for how it's done.
The Case Against Privileged Accounts
Any time that you launch a process in Windows, that process runs under the same security context as your account. This is the very reason why administrators are discouraged from using a privileged account unless a task requires it. For example, if an administrator were to accidentally trigger a ransomware infection, then the ransomware would run under the same security context as the user who triggered it. In other words, if the administrator is logged on as a privileged user, the ransomware would inherit the administrator privileges and wreak havoc with impunity. On the other hand, if the administrator is logged in as a standard user, the ransomware would be constrained by the administrator privileges – or rather, lack thereof.
The same restrictions on privileges that will prevent a malware attack from doing catastrophic damage also makes it so an administrator cannot do their job without a secondary, privileged account. The problem with this is, of course, that it is super-inefficient for an administrator to constantly log out of one account and into another. It can also sometimes be difficult to remember which account you are logged into, which could cause an administrator to perform a non-privileged operation (such as browsing the internet) while logged in with a privileged account.
Reducing the Administrative Burden
There are a few things that admins can do to make their lives easier without sacrificing security in the process.
Privilege access 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 Administration. The basic idea is that privileges are stripped from an administrative account to make that account functionally similar to a standard user account. When an admin needs to perform a privileged operation, they can acquire the required privileges for just long enough to complete the operation.
Separate workstations
Another common strategy for limiting permissions is to use two separate computers (or a physical device and two virtual machines). The idea here is that one device will be used for non-privileged operations while the other is used only for privileged operations. The advantage to this approach is that performing privileged operations from a dedicated management workstation and using a dedicated account greatly reduces the chances of the account becoming compromised. After all, the administrator will never be using the privileged account to sign into a standard workstation.
RunAs tool
An approach that is less commonly discussed is to use the RunAs tool. The RunAs tool, which has been a part of Windows since Windows 2000, lets a standard user use a privileged account to launch a specific process. This technique is not without risk because it does require an administrator to enter privileged credentials while signed in as a regular user. Even so, it can keep an administrator from having to log out each time they need to perform a privileged operation.
How To Use the RunAs Tool
So, let’s look at how an administrator might use the RunAs tool to perform a privileged operation. For the purposes of this article, I am going to assume that the privileged operation is being performed at the command line in PowerShell, but this technique can easily be adapted to other situations.
The administrator begins by logging in as a standard user and then opening a PowerShell session. Because the administrator is working from a standard user account, they currently lack the permissions to perform privileged operations within PowerShell.
Now suppose that the administrator needs to perform a privileged operation. To do so, they would type:
RunAs /User:PowerShell
The RunAs account tells Windows that the person who is logged in wants to run a process as a different user. The /User switch is used to specify the name of the user account that is to be used. Finally, RunAs needs to know what type of process to launch. In this case, I specified PowerShell as the process, but this could 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 figure below.
I have used the RunAs command to open a PowerShell window as another user.
