- Use Azure Bastion as a jump host for RDP and SSH - Tue, Apr 18 2023
- Azure Virtual Desktop: Getting started - Fri, Apr 14 2023
- Understanding Azure service accounts - Fri, Mar 31 2023
In general, do you operate your Windows client computers by using a standard user account or an administrative account? Least-privilege security states that you should operate your computers using a standard user account. Remember that if malware compromises your system, the rogue process can hijack the currently logged-on user's credential and privilege context. Not cool.
Therefore, the goal is to run as a standard user habitually and elevate your credential only for processes that require such elevation.
Today we will review some of the options available in Windows for applying least-privilege security during our daily computer operations. Information security is, above all, a balancing act between security assurance on one side and user convenience on the other.
Run as
Microsoft gave us User Account Control (UAC) in Windows Vista. The idea is you operate the computer using a standard user context (typically with a user account that's a member of the system's local Users group) and elevate to administrative privilege only when necessary.
From the Windows GUI, we access Run as by right-clicking an application or script icon (or shortcut) and selecting Run as administrator. As you can see in the following screenshot, File Explorer displays a UAC shield to denote any action that requires administrative elevation, while Start menu icons do not.
Note: Programmers can insert a flag in their source code to require administrative elevation for their process to execute. The process icon should then display in File Explorer with the UAC shield.
Accessing Run as from the Windows desktop
In any event, if you've logged onto the computer as a standard user, you'll need to provide another administrative credential to complete this action, as shown in the next screenshot:
Providing administrative credentials via UAC
Note: Shift + right-clicking a program shortcut from File Explorer gives you the Run as different user option, which is handy in certain circumstances.
As you probably know, we can access Run as and User Account Control from the command line as well. For instance, the following statement starts Visual Studio Code (VSCode) under another credential:
runas /user:zo "C:\Program Files\Microsoft VS Code\Code.exe"
Notes:
- /user: This can be a local or domain administrative user account
- /savecred: This optional parameter caches the credential so subsequent runs of the process will not require you to type the password again
- path: Instead of typing fully qualified paths to executables, Microsoft Management Consoles (MMCs), scripts, etc., I suggest you create shortcuts for the programs you want to launch under administrative privilege
The good news is that Run as works. The bad news is that whenever you start a process with Run as, you start that process under a totally different credential. This can have more ramifications than you think.
Take a look at the next screenshot. I am logged into my Windows 10 workstation with my standard Tim user account. Next, I started VSCode by using Run as administrator and authenticating as a local administrator named Zo.
Sadly, any user-specific references (such as the $profile automatic variable) will reference Zo and not Tim.
Context switching with User Account Control
Let's take a look at the best free solution I could find to provide administrative elevation without the annoying account context switching.
Sudo for Windows
Sudo (pronounced sue-doo or SUH-doo) is an old Unix/Linux tool that enforces least-privilege code execution in an elegant way. Andrew Kutz developed Sudo for Windows as a way to give administrators sudo capability from the Windows desktop and command line.
Sudo for Windows is free, open-source software. Mr. Kutz hasn't updated the software for quite a few years, but it works well so far on my Windows 10 workstations. If I were a developer, here is what I would do (maybe you can do this if you're so inclined?):
- Fork the project from SourceForge to GitHub
- Digitally sign the executable
- Ensure compatibility with both Active Directory domain and local user accounts
Here is how Sudo for Windows works: The software creates a service named Sudowin that operates with Local System privilege. It also creates a local group called Sudoers. Populate the Sudoers local group with user accounts that should be able to access Sudo for Windows. I show you a "mash-up" of these steps in the next screenshot.
Configuring Sudo for Windows
To use Sudo for Windows graphically, right-click the process or script icon and select Sudo... from the shortcut menu. You then supply your own user account password, as shown in the next screen shot.
Using Sudo from the Windows desktop
As a test, I started three instances of Notepad:
- One instance using my Tim standard user credential
- One instance using Sudo for Windows and the Tim account password
- One instance using Run as administrator and authenticating as Zo
I used Process Explorer to view metadata. First, look at the next screenshot and observe what's going on:
Comparing process identity in Process Explorer
- Process ID (PID) 6920: Notepad running under my Tim standard account with medium (non-elevated) process integrity
- PID 7484: Notepad running as Zo with high (elevated) integrity
- PID 824: Notepad running elevated with my Tim account
Process Explorer gives you additional details when you right-click the process, select Properties, and navigate to the Security tab.
Standard user at left and Sudo elevated user at right
Sadly, I have found Sudo for Windows to be a bit inconsistent when launched from the command line. For instance, typing sudo code from the Run box asked for my current user password, but it never launched VSCode.
On the other hand, from a non-elevated PowerShell console, typing sudo control opened the Control Panel under elevated context on my system.
Open Control Panel with Sudo from the command line
Wrap-up
For me, it was the uptick in ransomware attacks that finally convinced me to run as a standard user instead of as an administrator on all my client workstations. Here's what I suggest you do on your administrative workstations:
Subscribe to 4sysops newsletter!
- Rename the built-in Administrator and Guest accounts, give them strong passwords, and then disable them
- Create a separate local administrator account and give it a strong password for Run as elevation
- Convert your current user account to a standard user and ensure that user ID is a member of the Sudoers group
