A (non-hacking) tutorial on elevating privileges on Windows

Running as a normal user can be real pain on Windows (however it has become better with every version). This is because every program runs on the behalf of a given user and the credentials of that user determine what the program can or can not do. Usually you wish to run as user to protect your computer from malicious code you may inadvertently execute (for example normal users can't install drivers or change firewall settings), but there are some operations for which you might wish to elevate your privileges. A classical example for this would be changing system settings or installing software.

One method would be to use fast user switching and switch to an other user to perform this tasks. This option is rather complicated and time consuming, however it provides excellent protection, since the programs with elevated privileges won't run in the same window station as the low privilege ones (this is important because otherwise there is the possibility of a shatter attack). The big drawback is that it is very difficult to communicate between privileged and non-privileged programs (you don't have the option of drag and drop for example) and that it's very time consuming to switch between the two users (you have to type in two passwords every time).

An other standard way which is available in every Windows installation (starting from XP) is the Run As option in the context menu (the menu which appears when you right-click on elements in explorer and its command-line equivalent runas (to get more help on runas, type runas /? in a command prompt). This is less secure (because programs run in the same window station), however shatter attacks are mostly a theoretical (but real) threat and the assumption is that you are running mostly trusted programs. An other drawback would be that when you run a program as an other user, it will inherit the profile of that user (this means for example that it will see a different desktop directory than your current user, you won't see your bookmarks in the browser because they are stored on a per user basis – not that you would usually want to run your browsers with elevated privileges). You can partially work around this by using the command line version with the /env parameter which uses the current users environment variables rather then the environment variables which correspond to the impersonated user. To see the difference try running two instances of notepad as follows (this example assumes that the windows installation directory is c:\Windows and that Administrator is a user with administrative privileges but not identical to the currently logged in user – meaning that you are not logged in as Administrator)

runas /env /user:Administrator "c:\WINDOWS\NOTEPAD.EXE"

and

runas /user:Administrator "c:\WINDOWS\NOTEPAD.EXE"

Create a text file with each of them and save it on the desktop (what they see as the desktop). One of the notepads will save it on the current desktop (quick quiz: can you tell which one?) and the second one will save it on the desktop of the Administrator user (which in the default case would be C:\Documents and Settings\Administrator\Desktop). This works however only partially. By this I mean that it works only for programs which don't use the registry to store user specific information, because the user specific parts of the registry are still different for the normal processes and the processes started with runas (even with the /env switch). An other inconvenience is that you must time in your password each time, unless you use the /savecred option, which saves your credentials the first time you authenticate and then you don't have to type in your password the next time you execute something with the same credentials (if you use the /savecred option again). The problem from a security standpoint is that your credentials are cached until you log off (that is you can't control the period for which the credentials are cached). An other problem with it is that it's not available in the GUI version (from the right-click menu), only from the command line.

Now the third option would be to use sudowin. This is an open source project distributed under the BSD License (which is a very permissive license – an example about how permissive it is is the fact that for a long time parts of the Windows network stack were taken from an externally developed source code licensed under this license) written in .NET 2.0. What it does is that it gives administrative credentials to the programs you want to, but they will still run with your profile (meaning that they will see the same registry, the same desktop / my documents directory and so on). An other important differnce is that you must enter your password to elevate privileges. It also contains both a GUI and a command line component. To install it, take the following steps:

1. go to the website and download it (in a rather confusing move the download link is where it displays the version number, towards the upper middle of the page, currently it says 0.1.1-r95). If you didn't download anything from sourceforge.net until now, it will ask you to select a mirror.
2. You'll need the .NET framework 2.0. You can download it from the microsoft site if you don't already have it (be sure to download the redistributable package not the software development kit). Here is a direct link if you are running a 32 bit Intel or AMD machine. If you already have the .NET framework 1.0 or 1.1, it will prompt you during the installation and offer you the possibility to download and install the 2.0 version without interrupting the installation.
3. Install the software. Remember to do this from an account with administrative privileges (you can use the methods described earlier to run the installation with enough privileges).
4. Using a notepad with administrative privileges edit the sudoers.xml file located in the Server subdirectory of the install directory (this is C:\Program Files\sudowin by default or C:\Program Files (x86)\sudowin on 64 bit systems). Go to the users section and add the users you want to have sudo capabilities (remember to enter the names in the format of <domain or="" computer="">\<username>. If you are a home user, you can find out your complete name by entering whoami at the command prompt). Now go towards the end and enter the commands which you want to be able to run with elevated privileges. Also look around the file and change other settings to fir your need. Save the file.
5. Use the command runas /user:Administrator "cmd /c start lusrmgr.msc" (assuming that Administrator is a user with administrative privileges to which you know the password) to display the user management console (anyone else finds the name funny?). Go to each user you want to be able to perform sudo and add them to the Sudoers group which was created by sudowin during the installation (you can do this by right clicking on them, clicking properties, going to the "Member of" tab, clicking Add, writing Sudoers and clicking Ok).
6. Use the command runas /user:Administrator "cmd /c start services.msc", find the sudowin service and restart it.

Now you're good to go. Remember that you must enter your password when asked by sudo!

A quick comparative table of the three methods:

	Switch user	RunAs	sudowin
Built-in	Yes	Yes	No
Number of password you must enter	2	1 (the target users) or 0 (if already cached)	1 (your own) or 0 (if already cached and cache has not expired)
Password can be cached	No	Yes (but it will cache it until logout)	Yes (the timeout of the cache can is configurable)
Keeps user profile	No	Partially (can keep environment if launched from command prompt with the right switches, but not the registry)	Yes
Contains logging and other advanced features	No	No	Yes

A final trick (which applies also to the RunAs method): If you try to launch explorer exe nothing happens: normally all explorer instances share the same process (this is probably a leftover optimization from Windows 9x days). When you try to launch a new instance, it detects the old instance (the one that's displaying your taskbar and desktop), but that one's already running with a lower set of credentials. To fix this, you must set explorer to use a different process for each window. You can do this by creating a DWORD value with the name DesktopProcess in the registry at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer and giving it the value 1 (advice taken from here). Now it should work.