Elevating Processes Privileges

Elevating Processes' Privileges

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 XP. Chapter 7, "Managing Registry 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 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 "

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 in 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 paper "Understanding Software Installation" is an excellent walkthrough for the subject. The URL is http://www.microsoft.com/technet/prodtechnol/winxppro/proddocs/sag_ADEconcepts_01.asp.

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 the command prompt, 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 

/noprofile	Specifies that Runas should not load the user profile. Programs load faster but often don't work properly.
/profile	Specifies that Runas should load the user profile.
/env	Uses the current environment instead of the user's.
/netonly	Specifies that the credentials are for remote access only.
/savecred	Uses the credentials previously saved by the user.
/smartcard	Specifies that the credentials are provided by a smartcard.
/user Username	Specifies the account name to use. This should be in the form of user@domain or domain \ user.
Program	Specifies the command to execute.

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 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 folder, point to New, click Scheduled Task, and then rename the task. Configure the task as follows (shown in Figure 15-5).

• In the Task tab's Run box, type the command 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 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 15-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 XP to remove the task from the Scheduled Tasks folder after it runs. No reason to leave behind artifacts.

Figure 15-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 XP 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 12, "Deploying with Answer Files," but you can use it after deployment. Table 15-2 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 in order to log on to Windows XP 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 you want to automatically log on to Windows XP.

Table 15-2: Configuring Autologon

Setting	Name	Type	Data
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Enable Autologon	AutoAdminLogon	REG_SZ	0 | 1
User name	DefaultUserName	REG_SZ	Name
User domain	DefaultDomainName	REG_SZ	Domain
User password	DefaultPassword	REG_SZ	Password
Number of times to log on to Windows XP	AutoLogonCount	REG_DWORD	N
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
Program to run	Name	REG_SZ	Command

Here's how it works. If the AutoAdminLogon value is 1 and the AutoLogonCount value is not 0, Windows XP 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 XP 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 XP 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'd configure the values described in Table 15-2 so that when the current user logs off or when Windows XP restarts, the operating system automatically logs the domain 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 XP logs the user on to it starts the setup program, and the second continues the setup program. The script shown in Listing 15-5 shows a way to automatically configure Windows XP for this scenario.

Listing 15-5: 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 XP automatically logs the user on to it and the task completes, you're going to want to log the account off of the computer. Otherwise, you leave Windows XP vulnerable because anybody wandering by the computer has access to the account you used. The Windows XP Support Tools, which you install from the Windows XP CD in the Support\Tools folder, contain a utility called Shutdown. After installing the application, run the command shutdown -l to log the user off of Windows XP. 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 /? at the command prompt. Type start /? to see the options for the Start command.