Many companies follow the Microsoft best practice of “Least User Privilege”.  The idea is to provide a user or service the least amount of security privileges required to accomplish its task.  One of the most common tactics is using a seperate account for administrative tasks like application access or domain administration.  Using this tactic means that Domain Administrators do not logon to their workstations with their Domain Administrator credentials, where a piece of malware on that machine would inherit those all powerful permissions.  Instead they logon using a non-priviledged account.  So how do they perform administrative tasks without logging off and back on?  The answer is “Run As”, which utilizes the “Secondary Logon” service to run an application under alternate credentials.  However, you might be wondering if “Run As” works as advertised by mitigating this risk factor.  I will address that concern in this three part series, but the answer changes depending on whether you run it from the GUI or CLI and also what operating system you are using.  In this first part of the series let’s go look at how it works in Windows XP.

Windows XP

In Windows XP, if you want to run an application under alternate credentials you usually have to hold down the shift key while you right click on the application launcher.  Some application launchers do not require holding down the shift key for the “Run As” option to appear in the context menu.  Why some require it and some do not is still a mystery.  What we are trying to discover here is whether this option works as advertised from a security stand point.  Note: Make sure you do not have any MMC consoles open to avoid confusion when testing the below scenarios.

GUI

Test Scenario 1.  Go to Start→Programs→Administrative Tools and click Active Directory Users and Computers (hereafter referred to as ADUC).  Now right click the taskbar and open Task Manager. Click the processes tab and make sure to put a check mark in show processes from all users.  Scroll through the list and look for the “MMC” process.  You should see that it is running under the account you are logged in with.  This exercise verifies that ADUC is running under the credentials of the locally logged in user account as expected.  Let’s see what happens when we run it as an alternate user.

Test Scenario 2.  Close the ADUC MMC console.  Now let’s open it again, but this time hold down the shift key, right click ADUC, and select “Run As” from the context menu.  An authentication window will open, so enter an alternate user name and password.  Once ADUC opens, switch back to your Task Manager window or open a new one if you already closed it.  Look for the “MMC” process and you should see that it is running under the alternate account you provided and not the account you are logged in with.

At this point you are probably wondering when we will see something out of whack.  Everything is working as advertised, right?  Well if you stop and think about it, things are really not as good as they seem.  Assuming you used a domain administrator account, ADUC is now running with administrative privileges on both the domain and local workstation.  We now essentially have a gateway where malicious code on the workstation has unlimited permissions to the domain and domain code or scripts have access to the local machine.  By now I hope things are becoming a little more clear, but just in case it’s still a little muddy let’s play out this scenario.  You go to edit a GPO script, but don’t know that the script has been infected with a virus.  If ADUC had been running as a non-privileged user on your local machine then little or no damage might have occurred, but remember it is running under your alternate domain administrator account.  The virus now has access to your profile where it puts a script that goes out and starts deleting accounts from the domain.  Now we have a serious problem, and with this behaviour of “Run As” you might as well have logged in with your domain administrator account.  The good news is that there is switch you can throw when using the CLI that will change this behaviour.

CLI

The syntax for runas is:

runas /user:mydomainnamemyusername “Program EXE“

Example 1:

runas /user:contoso.comjoe.blow “mmc dsa.msc”

If you run the above example providing your alternate credentials and check Task Manager to see what the process is running under, you will see that it is running as the account you supplied.  This is identical to the results from test scenario 2 for the GUI.  Close the ADUC MMC.

Example 2:

runas /user:contoso.comjoe.blow /netonly “mmc dsa.msc”

In this example if you check Task Manager to see what the process is running under, you will see that it is now running as the locally logged on user and NOT the supplied alternate credential.  The /netonly switch tells the secondary logon service to use the supplied credentials for remote access only.  Now we are cooking with fire and have a much more secure way to run remote applications with high privileged accounts.

The good news is that we now have a secure solution, but the downside is having to type all that in for every application every time we need to run it.  Of course we can always write a handy script to help out and in Windows Vista we could write a sidebar gadget (which I have done).  Windows Vista, however, adds a whole other caveat and we will be looking at that in the next article of this series.

PART 2