Living the "Least Privilege" Lifestyle, Part 3: Surviving as a Mere User
- The Windows Secondary Logon Service
- Coping with LUA Issues
- Tools for Simplifying the LUA Life
- Windows Vista
- Least Privilege for Mere Mortals
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In the first two parts of this series, I explained why running as an admin on your local Windows workstation is a bad thing, giving malware nearly free rein over the machine, and why running with a least-privileged user account (LUA) is far safer. But as I explained in part 2, running as a member of the Users group can cause problems with applications and can be a hassle. So, in this installment, I'll explore the tools and techniques that make running as a mere user both possible and survivable.
The Windows Secondary Logon Service
The primary savior of running as a mere user is the Windows Secondary Logon Service that was introduced in Windows 2000. Installed and started automatically by default, it enables additional sessions beyond the user logged into the current interactive session. This means that you can interactively log into Windows using your LUA and then start a new process that requires administrative privileges for specific tasks. The Windows user interface implements this feature through Run As. When you opt to run as a different user, Windows pops up the Run As dialog box to prompt you for the alternative credentials (see Figure 1). The User Name list is populated with available administrative accounts on the local machine, or you can type in any other available username and enter that user's password. The process is then launched with the specified user's credentials, no matter which user is interactively logged in.
)
Run As is most commonly available when you use the runas command from a command prompt (discussed shortly) or right-click an executable file in Windows Explorer (see Figure 2). If the Run As option doesn't appear in the pop-up menu, try holding down the Shift key when you right-click; most of the time that trick will cause the Run As option to appear.
)
You can also configure shortcuts to automatically show the Run As dialog every time you launch an application from the shortcut. For example, I keep a shortcut to the Computer Management Control Panel applet in my quick launch bar. Since virtually everything for which I use Computer Management requires administrative privileges (adding and changing users, starting and stopping most services, and so on), it's convenient not having to remember to right-click the shortcut every time to select Run As. Configure the shortcut by right-clicking it, select Properties from the pop-up menu, and click the Advanced button on the Shortcut tab. Check the Run with Different Credentials box as shown in Figure 3, and you'll get the Run As dialog box every time you use the shortcut. This technique works for any shortcut on the system, whether on the quick launch bar, in Windows Explorer, or an item in the Windows Start menu.
)
Some intelligent installation programs will detect that you are starting the setup program as a LUA and present you with the Run As dialog. But as I discussed last time, most just crash or do a partial installation.
The runas command is available from the command prompt, if you prefer that option to GUIs. In its simplest form, you can log in as another user and launch an application. The following code runs Internet Explorer with the credentials of the MyAdminLogin login on the local MyComputer machine
runas /user:MyComputer\MyAdminLogin iexplore.exe
An interesting option for runas is /netonly. The following command opens a new command prompt with a domain login's credentials, but uses them only for accessing network resources:
runas /netonly /user:Domain\Login cmd
Any local resources are still accessed using the credentials of the command prompt in which you run the runas command, typically those of the logged-in user.
There are lots of other options to explore for runas. However you use it, it will prompt you for the specified user's password. Once you enter the password, it will launch the specified app with the selected credentials.
Run As Issues
Run As is a great way to run an application as an administrative user, but it has limitations. One is that if the application by default reuses existing instances and is already running, Run As reuses the existing instance. This means that while you might have many Microsoft Word windows open, for example, only one Word process is running because Word reuses an existing instance. Windows Explorer also reuses instances. For these applications, the new instance has the same credentials as the existing process, no matter what you enter in the Run As dialog box. Many applications allow you to configure this setting, however. In Windows Explorer, choose Tools, Folder Options and click the View tab. Scroll about halfway down the Advanced Settings list and select the Launch Folder Windows in Separate Process option. Most of the time this approach will work, but Explorer seems to balk sometimes. If that happens, you can use Internet Explorer instead, as I describe later in this article.
Some activities require you to be logged in as an administrator; using Run As with administrative credentials just won't cut it. Probably the most common example is Windows Update and the newer Microsoft Update services. Running Internet Explorer as an admin from a LUA interactive login and selecting Windows Update from the Tools menu will result in a page that tells you to log in as an administrator. As annoying as this is, it sort of makes sense because the changes made during an update can affect the deepest bowels of the Windows kernel, including the Windows Secondary Logon Service itself and other security features. Some third-party applications have the same problem.
But a bigger problem is what I call a profile context switch. When you Run As another login, you're using that login's Windows profile. Anything you do while logged in as that user affects that user's profile, not yours. So if you run an application that saves configuration settings to the current profile, say during installation, those settings will not be available when you run the application as your regular LUA. This restriction applies to user-specific Windows settings as well, such as for desktop configuration. This is one of the main reasons why installation programs that write configuration information to the user's profile break when you run them the first time. Because you install the application as an administrator and run the application as a different user, the settings and data are not where the program expects them. Some die gracefully, others die ugly.
One of the rules you'll need to learn is when to use Run As and when you don't need it, particularly when configuring Windows. In general, if the setting is user-specific (in other words, every user who logs into the machine can have her own setting), Windows will probably let you set it; otherwise, it won't. Sometimes Windows will warn you up front when something isn't going to work, such as when you access the Device Manager in the Control Panel. In that case, you can see devices and make superficial changes, but it will warn you (by displaying the dialog box in Figure 4) that various settings are off-limits to LUA users.
)
After you click OK, you get the regular Device Manager window with many options disabled.
At other times, Windows chooses not to tell you there's a problem until after you've made the changes and click Apply or OK. For example, this happens when you try to add a user to the Administrators group or set the machine's Power options. And there are many other variations on the theme.