(For more resources on Microsoft products, see here.)
Granting temporary administrative privileges
One of the primary concerns for system administrators when implementing Least Privilege Security on notebook computers is how to solve problems that require administrative access if a remote connection cannot be established. Consider a scenario where a user arrives at a conference center but can't connect their notebook to the local network because there isn't a DHCP server available. The only way to make a successful connection is to manually configure an IP address.
While we could add users to the Network Configuration Operators group on each notebook so that they can configure local network settings, the requirement to manually configure network options is rare and granting this access is likely to create more support problems than it solves. If you've ever worked on a help desk, you'll know that a high percentage of calls from mobile workers are related to network connection problems, often caused by a misconfiguration.
Windows doesn't have any built-in mechanism that allows system administrators to temporarily grant administrative privileges, leaving IT nervous to commit to Least Privilege on notebook computers. In this section, we'll look at a couple of simple techniques that can be used to grant temporary administrative access to mobile users when all else fails. Neither method is perfect, and could potentially be hijacked by savvy users to install unsanctioned software or grant themselves permanent administrative access, but there must be a back door for system administrators to ensure confidence in the ability to provide support in any situation.
The instructions that follow use local user accounts and local policy settings, but are intended for use in a domain environment. If you wish to manage the accounts and policy settings centrally, domain users and domain-based Group Policy Objects can be used as an alternative. The following techniques shouldn't be used in high security environments.
Granting temporary administrative access using a separate logon (Vista and Windows 7 only)
For each notebook in our organization, we need to create a set of accounts that have administrative access. Let's create three accounts on each notebook—Support1, Support2, and Support 3.
Creating three support accounts
You can do this easily from the command prompt or by adding the appropriate commands to a batch file. Log on to the notebook as an administrator and run the following two commands from the command prompt:
net user Support1 ******** /expires:never /passwordchg:no /ADD
net localgroup Administrators Support1 /ADD
Replace ******** with a random password for each account. The passwords for each support account must be recorded somewhere for future reference. The password for each account should be completely random and differ on every notebook.
Creating a policy setting to automatically delete the support account at logoff
To ensure that the support account is deleted at log off, we need to create a local policy setting for each support account.
- Type MMC into the Search programs and files box on the Start menu and press Enter.
- Press Ctrl+M to add a snap-in.
- In the Add or Remove Snap-ins dialog box, select Group Policy Object Editor from the list on the left and click Add.
- In the Select Group Policy Object dialog box, click Browse.
- In the Browse for a Group Policy Object window, switch to the Users tab.
- Select Support1 in the list and click OK.
- In the Select Group Policy Object dialog box, the Group Policy Object will now read Local Computer\Support1. Click Finish.
- In the Add or Remove Snap-ins dialog box, click OK.
- In the MMC console window, expand Local Computer\Support1 Policy, User Configuration, Windows Settings under Console Root in the left pane.
- Click Scripts (Logon/Logoff) under Windows Settings.
- In the central pane, double-click Logoff.
- In the Logoff Properties dialog box, click Add.
- In the Add a Script window, type net in the Script Name field.
- In the Script Parameters field type user support1 /delete and click OK.
- Click OK in the Logoff Properties dialog box.
- Close the MMC window.
These steps need to be repeated for each support account.
Testing the support accounts
To test the configuration, log in to Windows using the Support1 account.
- You'll need to click Switch User on the log on screen and then select Other User.
- When entering the username, specify that it's a local user account using the format COMPUTERNAME\USERNAME. In this case, the computer is called WIN7.
- Check that Support1 has administrative access by performing a task such as changing the date or time. If Support1 has administrative privileges, UAC will not prompt for elevation.
- Log off Support1 and then try to log in again using the same account. This time you should be presented with The user name or password is incorrect as an error message because the Support1 account no longer exists.
To repeat the support procedure, the password for Support2 must be known by the user.
Putting into practice
The procedure outlined here can be used by help desk staff when a user requires a temporary administrative login for support:
Granting temporary administrative access without a separate logon
Sometimes we just need to give the logged in user administrative privileges without asking them to use a different account. The following technique uses the same three support accounts created earlier, but this time instead of asking the logged in user to switch user and start a new desktop session, we'll ask them to launch a preinstalled batch file using the support user's credentials supplied by the help desk.
Creating a batch file to elevate the privileges of the logged in user
We're going to create three batch files, one for use with each of the three support user accounts. The batch files are also unique for the logged in user. As this elevation technique will generally only be used for mobile users, and notebooks tend to have only one regular user, this limitation shouldn't prove too much of a problem. This technique could be developed further to accommodate more complex requirements.
Using Notepad, save the following commands as Support1.cmd:
net localgroup Administrators AD\user /ADD
@ping 127.0.0.1 -n 60 -w 1000 > nul
@ping 127.0.0.1 -n %1% -w 1000 > nul
net localgroup Administrators AD\user /DELETE
net user support1 /DELETE
So what does the batch file do?
- The logged in user, in this case firstname.lastname@example.org, is added to the notebook's local Administrators group.
- The two ping commands are used as a means of creating a timed delay in the batch file of 60 seconds. This value can be changed to meet your needs and gives email@example.com a time-limited chance to elevate his/her account.
- Once the timer has stopped, firstname.lastname@example.org is removed from the local Administrators group and the support1 user account is deleted to ensure the user can't repeat the procedure.
You should create three batch files, one for each support user account, modifying the commands as necessary—Support1.cmd, Support2.cmd, and Support3.cmd. The files should be saved to a trusted location on the user's notebook, for instance to a dedicated folder in C:\Program Files or C:\Windows, to help ensure that the user can't modify commands in the batch files. when they are running without administrative privileges.
Testing the procedure
Log in to a notebook with a standard user account and follow these instructions:
- Locate the support batch files in C:\Program Files or C:\Windows.
- Select Support1.cmd, right-click on the file, and select Run as administrator from the menu.
- User Account Control will prompt for administrative credentials. Enter the credentials for the Support1 account, remembering to use the following format: COMPUTERNAME\USERNAME.
- A command-line window will appear. Now attempt to change the time or date. UAC will still prompt for administrative credentials, but this time email@example.com can enter their own credentials to elevate and successfully change the date or time.
- After 60 seconds, the batch file will continue processing and remove firstname.lastname@example.org from the local Administrators group.
- Try again to change the time or date; enter email@example.com credentials into the UAC prompt and this time the request will be denied as firstname.lastname@example.org has been demoted back to a standard user.
Limitations of the procedure
OK, so this seems to work well, but you may have noticed some limitations. The user could close the command-line window and prevent the batch file from completing, effectively leaving email@example.com in the local Administrators group. While there's no simple way to prevent this, you can use Group Policy Restricted Groups to ensure that only approved accounts remain permanently in the Administrators group on each notebook.
firstname.lastname@example.org could also log out and log in before the batch file completes processing, again elevating themselves to a permanent administrative status if Group Policy Restricted Groups is not configured. Ultimately, it's important to understand that even in granting a user temporary administrative privileges lies the possibility that they could change system-wide configuration to prevent Group Policy settings applying or grant themselves permanent administrative access to the PC.
Help desk procedure for granting temporary administrative access:
Restricting access to firecall accounts
Consider restricting the number of help desk staff who have access to usernames and passwords for firecall accounts, to limit the reporting requirements for the purposes of SOX and PCI compliance, should these credentials be abused.
Bypassing user account control for selected operations
It may be necessary for a mobile user to perform an operation that requires administrative privileges on a regular basis. A real-world example of this that I encountered was on a notebook with a faulty wireless adapter. After the notebook resumed from hibernation, it was quite common that the adapter would not work. The only solutions were to reboot the notebook, a considerable nuisance for the user, or to disable and then enable the adapter in the Network and Sharing Center, but this operation requires administrative privileges.
Using Task Scheduler to run commands with elevated privileges
To solve this problem, log in to the notebook as an administrator and create a batch file that contains the necessary commands to disable and enable the wireless adapter.
echo --- Restarting Wireless Adapter
netsh interface set interface
name="Wireless Network Connection" admin=disabled
netsh interface set interface
name="Wireless Network Connection" admin=enabled
Save the file, wireless.bat, to a trusted location on the user's notebook; for instance to a dedicated folder in C:\Program Files or C:\Windows. In this case, I've created a folder called Support in C:\Program Files.
- Type Task Scheduler in the Search programs and files box on the Start menu and press Enter.
- In the left pane of Task Scheduler, select Task Scheduler Library.
- Right-click on Task Scheduler Library and select New Folder from the menu.
- Call the folder Support and click OK.
- Expand Task Scheduler Library, right-click the Support folder, and select Create Task from the menu.
- In the Create Task dialog box, name the task Wireless.
- Click Change User or Group and in the Select User or Group dialog box, type SYSTEM and click OK.
- Switch to the Actions tab and click New.
- In the New Action dialog box, enter the local path of the wireless.bat file in the Program/script box under Settings and click OK.
- Switch to the Conditions tab and under Power, uncheck Start the task only if the computer is on AC power.
- Click OK. In the central pane of Task Scheduler, right-click the Wireless task and select Run from the menu. Make sure that the wireless adapter is restarted as expected.
The challenge is now to allow a standard user to run this task, because, by default, standard users can't run tasks on demand that are created by an administrator. We need to change permissions on the Wireless task using Windows Explorer to allow Authenticated Users to run it.
- Launch Windows Explorer by pressing the Windows Key + E. Navigate to C:\Windows\System32\Tasks\Support, right-click on the Wireless file, and select Properties from the menu.
- In the Wireless Properties dialog box, switch to the Security tab.
- Click on Edit and in the Permissions for Wireless window, click Add.
- In the Selected Users, Computers, Service Accounts, or Groups dialog box, click on Locations, select the local computer, and click OK.
- Type Authenticated Users into the box and click OK.
- In the Permissions for Wireless window, select Authenticated Users and check Allow for Read & Execute and Read permissions.
- Click OK and then Yes in the Windows Security dialog box.
- Click OK in the Wireless Properties dialog box.
Running the Scheduled Task as a standard user
Now that the task is in place and permissions have been set, let's set up a shortcut to allow the user to run the task on demand. Log in to the notebook using a standard user account, in this case email@example.com.
- Open a command prompt and type schtasks /run /TN "Support\ Wireless" and press Enter.
- Schtasks should respond with SUCCESS: Attempted to run the scheduled task "Support\Wireless".
- Check that the wireless adapter has been restarted as expected.
- Right-click the user's desktop and select New | Shortcut from the menu.
- In the Create Shortcut dialog box, type schtasks /run /TN "Support\ Wireless" into the box and click Next.
- Give the shortcut a name and click Finish.
In this article, we've learned how to cope with difficult support situations for standard users and run common processes without the need to elevate with administrative privileges all the time.
- Solving Least Privilege Problems with the Application Compatibility Toolkit
- Solving LUA Problems with Avecto Privilege Guard