Microsoft Windows Registry Guide, Second Edition

Elevating Privileges of Processes

Privileges are a nasty little paradox. On one hand, you don't want to add users to the local Administrators group. Restricting users is a best practice that prevents human error, senseless distractions, opportunistic viruses, and so on. On the other hand, deploying software to restricted users is difficult. They don't have the privileges necessary to install most applications, such as Office 2003 Editions. Chapter 8, “Configuring Windows Security,” shows you a variety of features that you can use to reach a happy medium between unbridled access and totally locked-down desktops. What I want to show you in this chapter is how to run processes elevated so that you can perform many of the tasks I've described in locked-down environments.

The sections following this one go from elegant to dodgy. Group Policy, specifically the InstallAlwaysElevated policy, is one way to allow restricted users to install Windows Installer–based applications. You can also use the Secondary Logon feature or Scheduled Tasks. The section “AutoLogon,” later in this chapter, describes a method that Microsoft Systems Management Server (SMS) uses, and I tend to like this solution. The last two methods that I describe in this section are very risky and can be used against you if you're not careful.

Group Policy

The policy InstallAlwaysElevated installs Windows Installer–based applications with elevated privileges. This policy is one way to allow users to install Windows Installer–based applications that they couldn't otherwise install because their accounts are in restricted groups or you've locked down the desktops.

Keep in mind the consequences of using this policy. Users can take advantage of this policy to gain full control of their computers. Potentially, users can even permanently change their privileges and circumvent your ability to manage their accounts and computers. Not only that, this policy opens the door to viruses disguised as Windows Installer package files. For these reasons, this isn't a setting that I recommend in any but the most necessary scenarios when there's no other method available other than to toss users into the local Administrators group.

For this policy to be effective, you must enable both the per-computer and per-user versions of it at the same time. In other words, enable it in Computer Configuration as well as User Configuration. If you're going to use this policy, I recommend that you enable it for each rollout unit prior to deploying software to it. Deploy your package, and then immediately remove the policy for that unit. You can at least limit your exposure to the perils that this policy creates.

NOTE

If you have Active Directory and Group Policy, you shouldn't consider using the InstallAlwaysElevated policy. The only reason you'd use this policy is in lieu of a software management infrastructure. If you have Active Directory and Group Policy, however, you have at your disposal an elegant solution for small and medium businesses: Software Installation And Maintenance. This feature enables you to deploy software through GPOs. The best part is that you can deploy Windows Installer–based software to restricted users and locked-down desktops because applications you deploy through Group Policy install with elevated privileges. The white paper “Understanding Software Installation” is an excellent walkthrough for the subject. You can find this document at http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_adeconcepts_01.mspx.

Secondary Logon

Secondary Logon, also called Run As, enables users to run programs in the context of accounts other than their own. For example, if I'm logged on to the computer using the account Jerry, which is in the Power Users group, but I need to run a program as an administrator, I hold down the SHIFT key, right-click the program's shortcut icon, click Run As, and then type the Administrator account's name and password. The program runs under the Administrator account. Because Secondary Logon relies on users knowing the credentials (which they won't know), it's not a really useful tool for software deployment. I include it here to answer the inevitable question about whether you can use it for that purpose.

You can use Secondary Logon from a command prompt window, too. The following shows you the syntax for this command:

RUNAS [ [/noprofile | /profile] [/env] [/netonly] ] /user:Username Program RUNAS [ [/noprofile | /profile] [/env] [/netonly] ] /smartcard [/ user:Username] Program

Scheduled Tasks

One thing I like about Scheduled Tasks is that you have remote access to the Scheduled Tasks folder on each computer. Also, you can include an account name and a password in each task. You're not relying on users to provide the credentials necessary to run a job, such as installing software. For this reason, Scheduled Tasks beats Secondary Logon. In My Network Places, find the computer on which you want to add a task. Open the computer's Scheduled Tasks folder, right-click the within folder, point to New, click Scheduled Task, and then rename the task. Configure the task as follows (shown in Figure 18-5).

• In the Task tab's Run text box, type the command that you want to execute. Remember to keep the command's path relative to the computer on which you're running it.

• In the Task tab's Run As text box, type the account in which you want to run the task, and then click Set Password to set the matching password. As shown in Figure 18-5, type the account in the form domain\username.

• On the Schedule tab, configure the task's schedule. In the scenarios that I've described (deploying software and settings), you'd want to schedule the task to run once.

• On the Settings tab, configure Windows to remove the task from the Scheduled Tasks folder after it runs. There is no reason to leave behind artifacts.

Figure 18-5 Scheduled Tasks is a useful way to run programs on remote computers with elevated privileges, particularly in one-off scenarios.

NOTE

Be careful not to schedule tasks that require user interaction. Users won't see the task running unless they look in Windows Task Manager and view tasks for all users. For example, if you schedule a task to run on a computer as the local administrator and the user Jerry is the current console user, Jerry won't be able to interact with the task. If the task requires user interaction, it'll hang. Many programs, particularly setup programs, have command-line options that run them quietly. Install Office 2003 Editions with no user interaction, for example, using the /qn command-line option. Also, use this method to install software or run programs that don't interact with the current console user's profile, because this method will affect only the profile of the user you typed in the Run As box. In other words, install applications that support per-computer installations or run programs that interact with HKLM.

AutoLogon

This is my favorite method when I don't have a software management infrastructure available for deploying software: I use AutoLogon. This is the same capability that you can configure in answer files, as described in Chapter 14, “Deploying with Answer Files,” but you can use it after deployment. Table 18-4 describes the settings you need to configure for AutoLogon. To enable this feature, you must set the REG_SZ value AutoAdminLogon to 1. Then you set the REG_SZ value DefaultUserName to the account that you want to use, and the REG_SZ value DefaultPassword to the account's password. If the user name doesn't include the domain, set the REG_SZ value DefaultDomainName to the name of the domain authenticating the account. Just remember that you must add the account to one of the local groups to log on to Windows using that account. The domain administrator is already a member of the local Administrators group, but I don't recommend using the domain administrator account with this technique. Instead, you can use the local Administrator account, which is always available. The last value you set is the REG_DWORD value AutoLogonCount. Set this value to the number of times that you want to automatically log on to Windows.

Here's how it works. If the AutoAdminLogon value is 1 and the AutoLogonCount value is not 0, Windows automatically logs on to the computer using the credentials provided in the values DefaultUserName, DefaultDomainName, and DefaultPassword. The operating system then decrements the value in AutoLogonCount. When AutoLogonCount reaches zero, Windows removes the values AutoLogonCount and DefaultPassword from the registry and no longer logs the user on to it automatically.

The last step is to put the command you want to run in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce. Because you're putting this command in the RunOnce key, Windows runs this command one time and then removes the value from the registry. Each value in RunOnce is a command. The name of each REG_SZ value doesn't matter, but you store the command line you want to execute in it.

An example will tie everything together for you. I want to deploy an application to a computer but the users in my organization are restricted and can't install it. I configure the values described in Table 18-4 so that when the current user logs off or when Windows restarts, the operating system automatically logs the local Administrator on to the computer. I know that the application reboots the computer one time during the installation process, so I have to set AutoLogonCount to 2. The first time Windows logs the user on to it starts the setup program, and the second logon continues the setup program. The script shown in Listing 18-4 shows a way to automatically configure Windows for this scenario.

Listing 18-4 Install.inf

[Version] Signature=$CHICAGO$ [DefaultInstall] AddReg=Reg.Settings [Reg.Settings] HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon,AutoAdminLogon,0,"1" HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon,DefaultUserName,0\ ,"Administrator" HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon,DefaultDomainName,0\ ,"HONEYCUTT" HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon,DefaultPassword,0\ ,"PASSWORD" HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon,AutoLogonCount\ ,0x10001,0x02 HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce,Setup,0\ ,"\\Server\Share\Setup.exe"

The last thing that you should know about this technique is that after Windows automatically logs the user on and the task completes, you're going to want to log the account off of the computer. Otherwise, you leave Windows vulnerable because anybody wandering by the computer has access to the account that you used. The Windows Support Tools, which you install from the Windows CD in the Support\Tools folder, contain a utility named Shutdown. After installing the application, run the command shutdown -l to log the user off of Windows. To restart the computer, run shutdown –r. To chain the application's setup program to the Shutdown command, use a batch file and the Start command with the /wait command-line option, which enables you to run programs synchronously, one after the other. To see the command-line options for the Shutdown command, type shutdown /? in a command prompt window. Type start /? to see the options for the Start command.