In the fight against malicious code, security experts have long recommended that administrators have two accounts--one for everyday use and one for administrative tasks. Running as an administrator leaves you vulnerable to a malicious software (malware) attack. Moreover, administrator privileges grant a user sweeping powers such as setting passwords, file permissions, users and groups, and many others. Security administrators face the dilemma of limiting the use of administrator privileges while giving users adequate permissions to perform their routine tasks. One solution that accommodates both needs is to let some users run as administrators and configure those applications that are most vulnerable to a malware attack--email, IM, and Web browsing--to run as low-privilege Guest accounts. Let's look at when you might want to use a Guest account and how to set one up.
Why Use a Guest Account?
Because some users require privileged access for many of their daily functions, either forcing a restrictive permissions policy on users or granting all users full administrator rights could prove counterproductive. Take, for example, one company I visited several years ago that had a security-aware network administrator. He forced everyone in the company, even the developers, to run as nonadministrators on their own workstations for day-to-day tasks. Everyone felt this policy was overbearing and either complained about it or, if they had the know-how, broke in to their own systems to gain administrator access.
When that network administrator left the company and a new administrator replaced him, the new admin faced so much user and management resistance to this policy that he decided to abandon it completely. Unfortunately, after that everyone ran as an administrator on their local systems, which posed a much greater risk than letting a few power users run as local administrators. A better solution would have been to work with users to find the best balance of security and productivity, so that users more willingly participated in the security process. Guest accounts let you accommodate power users who need privileged access and yet still provide them the protection they need for certain tasks.
Least Privilege
Guest accounts are an example of using least privilege: granting each user only those privileges required to fulfill his or her role and responsibilities. As I mentioned, some attacks exploit security flaws in certain software applications. Typically, these attacks occur as email-based viruses or browser vulnerabilities that are the medium through which spyware or Trojan horses are installed on a system. If you aren't logged on as an administrator, malicious code is less likely to damage your system.
Unfortunately, in practice least privilege sometimes inconveniences users so much that they start seeking ways to circumvent it. Such circumventions might cause a greater security exposure than if you hadn't used least privilege at all. In fact, many administrators and security experts who support least privilege still find it difficult to run as nonadministrators and don't follow the least-privilege policy themselves. Guest accounts provide a way to implement a degree of least privilege that prevents users from completely circumventing security.
Account Choices
Typically, you should run as a nonadministrator and use tools such as the Runas utility (runas.exe) to perform specific tasks as an administrator. For this strategy, certain users may log in as administrators for most of their tasks yet perform particular highexposure tasks as guests. The drawback of using Runas is that it requires users to maintain two accounts--a user account and an Administrator account--each with its own password to remember, set of permissions to manage, and profile to administer. Furthermore, regular user accounts still have enough power to do significant damage and usually have access to network and other sensitive resources.
For many Internet activities, though, you don't need the level of privilege of even a regular user account. The Windows built-in Guest account is perfect for this situation. It already has limited access configured and, because it's a local account, it doesn't have access to the domain. Also, because it's a limited account, you can relax a bit in your efforts to keep it secure. For example, you might let users go as long as 6 months without requiring a password change for that account.
Preparing the Guest Account
The Guest account needs some preparation before you use it. By default, the account is disabled and has no password. You also might have Group Policy restrictions that disable or rename the account.
First, adjust or disable any security policies you've set that might affect the Guest account. Next, configure basic account options by running this command at a command prompt:
net user "Guest" * /active:yes /passwordchg:yes /passwordreq:yes /workstations:%COMPUTERNAME%
(The command wraps to several lines here because of space limitations; you should actually type it on one line.) After you press Enter, you're prompted to enter a new password for the account. Type an appropriate password, and retype the password to confirm it.
Finally, you need to log off and log back on by using the Guest account. Doing so lets you configure your browser's preferences and security settings. You might also find it helpful to make some changes to your Windows and browser UI settings so that you can easily distinguish which account you're using. For example, you could use a different toolbar or skin setting depending on which browser you use. You can also configure a different background bitmap for Microsoft Internet Explorer (IE). To do so, see the instructions at http://www.winguides.com/registry/display.php/ 66. After you finish configuring your applications, log off and log on again by using your regular Administrator account.
Because you'll probably want to download files from the Internet, you might want to create a shared folder that the Administrator and Guest accounts share. Make sure that you limit the permissions on this folder to allow only the minimal access needed to save downloaded files. You might, for example, not allow the Guest account to execute any files in that directory.
Running as Guest
You can launch your applications to run under the Guest account in several ways. The quickest way is to simply run the Runas command or invoke runas.exe in a batch file. To run the Runas command, right-click the application's icon and select Run as from the menu. (In Windows 2000, you need to hold down the Shift key and right-click.) In the dialog box that's displayed, click The following user radio button and enter the username (Guest) and password you want to use, as Figure 1 shows.
You can also execute Runas at a command line and specify the /save cred parameter to let you save the password so that you don't have to enter it every time. As a rule, using this feature isn't prudent, but because in this case you're using Runas to impersonate the Guest account from an Administrator account, saving the password poses little risk. If someone already has access to your privileged account, they'd have little to gain from running programs as a local Guest.
If you want more features than the built-in Runas command provides, many third-party tools provide them. For example,Wingnut Software provides a tool called Encrypted RunAs that lets you save account credentials in an encrypted format. Another tool, a freeware utility called SUperior SU, lets you not only launch a process as another user, but it also switches to a unique desktop for that user, providing even further protection.
The best way to remind users to use the Guest account for security-sensitive activities, such as browsing the Internet, is to replace all the regular desktop and Start menu icons with new icons that launch the applications under the Guest account. That way, users don't have the opportunity to forget to log on as a Guest. On a shortcut's properties, if you click Advanced, you can select the Run with different credentials check box, so that when the user double-clicks a shortcut to start an application, it always prompts for different credentials, as Figure 2 shows. This method requires the user to enter a password each time he or she runs the application, so you might find one of the previously mentioned utilities more convenient to use. These other utilities let you save the user credentials and provide more options for launching the application.
Partial Solution
Bear in mind that using a Guest account should be only one part of your security strategy. It doesn't completely eliminate security threats; it only minimizes the effects of those threats. Using a Guest account is one implementation of a least-privilege strategy that, as part of a larger security policy, can greatly reduce a user's exposure to attack. For greater security, you should connect user workstations only to trusted networks and use mechanisms such as personal firewalls and antivirus software, antispam software, and antispyware tools to limit network traffic, filter incoming email messages, and block the downloading and installation of malware. Most important, you should actively work to educate users about the risks and techniques for protecting themselves.
