Windows Sysinternals : Windows Core Concepts - Administrative Rights

8/8/2011 6:14:10 PM
Windows NT has always had a rich access control model to protect sensitive system resources from modification by or disclosure to unauthorized entities. Within this model, user accounts are typically given Administrator rights or User rights. Administrators have complete and unrestricted access to the computer and all its resources, while Users are restricted from making changes to operating system configuration or accessing data belonging to other users. For historical reasons, however, until recently end users on Windows computers were frequently granted administrative access, so many people have remained unaware that these distinctions exist. (Even today, the first local user account created on a Windows 7 computer is a member of the Administrators group.)


Users can have effective administrative control over a computer without explicit membership in the Administrators group if they are given the ability to configure or control software that runs in a more powerful security context—for example: granting users control over systemwide file or registry locations used by administrators or services (as Power Users had before Windows Vista); granting users “admin-equivalent” privileges such as the Debug, Take-Ownership, Restore, or Load Driver privileges; or enabling the AlwaysInstallElevated Windows Installer policy, under which any MSI file launched by any user runs under the System account.

Recently, organizations wishing to improve security and reduce costs have begun moving toward a “non-admin” model for their end users. And with Windows Vista’s introduction of User Account Control (UAC), most programs run by users—including those who are members of the Administrators group—execute with user rights, not administrative rights. However, it sometimes becomes necessary to run a program with administrative rights. While many people didn’t know how to do this in Windows XP, Windows Vista changed those methods significantly.

Many of the Sysinternals utilities always require administrative rights, while many have full functionality without them. Some, however, are able to work correctly with standard user rights but have features that need administrative rights, and thus operate in a “partially degraded” mode when executed with standard user rights.

1. Running a Program with Administrative Rights on Windows XP and Windows Server 2003

If you log on to a Windows XP or Windows Server 2003 computer with an account that is a member of the Administrators group, no special steps are required to run a Sysinternals utility with administrative rights. Every program you run has full administrative rights.

But if you log on to that same computer with an account that does not have the required privileges to run a particular Sysinternals utility, you will need to get the administrative rights from a different user account. The Secondary Logon (Seclogon) service enables programs to start a new process as a different user on the current desktop by supplying alternative credentials. Two programs that expose this functionality are Explorer’s Run As dialog box and the Runas.exe command-line utility.

To use the Run As dialog box to start a program with administrative rights, right-click on any program or shortcut in Explorer or the Start menu and choose Run As from the context menu. In the Run As dialog box, choose the second radio button (“The Following User) as shown in Figure 1, type the credentials for an administrative account, and click OK. You can make Run As the default for a shortcut by opening its Properties dialog box, clicking the Advanced button, and selecting the “Run With Different Credentials check box.

Figure 1. The Windows XP Run As dialog box with the second radio button selected.

To start a program with administrative rights with the Runas.exe command-line utility, open a command prompt and start Runas.exe with this syntax:

runas /u:username program

For example, to run Process Monitor (Procmon.exe) with the local Administrator account, run the following command:

runas /u:administrator procmon.exe

After you press Enter, Runas.exe prompts you for the account’s password. You must type the password at the prompt; Runas.exe does not accept a password on the command line nor piped to it from the standard input stream. You can use the /savecred command-line option to save the account’s password the first time you enter it; subsequent use of /savecred with the same account will retrieve the saved password so that you don’t have to enter it again. While this behavior is convenient, note that the standard user under whose account the administrator’s password is saved can now use Runas.exe to launch any program without having to supply the password.

To use smartcard authentication instead of password authentication, add the /smartcard option to the command line. You will be prompted for a smartcard PIN instead of a password.

For more information and tips about using RunAs, see Aaron Margosis’ “RunAs basic (and intermediate) topics” blog post at the following URL:

If you need the Sysinternals utility to run with full administrative rights but under your nonadministrator account (for example, so that it can authenticate to domain resources), you can use Aaron Margosis’ MakeMeAdmin script. It invokes Runas.exe twice to launch a command prompt that runs under your current account but with full administrative rights. (Note that you must have credentials for an administrative account to make this work.) For more information, see his “MakeMeAdmin — temporary admin for your Limited User account” blog post at the following URL:

2. Running a Program with Administrative Rights on Windows Vista or Newer

Windows Vista and UAC changed everything when it came to running programs with administrative rights. Running as a standard user is now the default state for users’ programs, even when run by a member of the Administrators group.

If you log on to a computer running Windows Vista or newer with an account that is a member of Administrators (the first account is the only one that defaults to Administrators group membership on computers not joined to a domain) or another powerful group such as Backup Operators or that has been granted “admin-equivalent” privileges, the Local Security Authority (LSA) creates two logon sessions for the user, with a distinct access token for each. One of these tokens represents the user’s full rights, with all groups and privileges intact. The other is a filtered token that is roughly equivalent to one belonging to a standard user, with powerful groups disabled and powerful privileges removed. This filtered token is used to create the user’s initial processes, such as Userinit.exe and Explorer.exe, and is inherited by their child processes. Starting a process with the user’s full token requires UAC elevation, mediated by the Application Information (Appinfo) service. The Runas.exe command is still present, but it does not invoke the Appinfo service—so its effect is not quite the same as it was on Windows XP. If you start a program with Runas.exe and specify an administrative account, the target program runs under the “standard user” version of that account.[3]

[3] With UAC enabled, there is one exception to this rule. By default, UAC token filtering and “admin approval mode” does not apply to the built-in Administrator account. Anything run under that account always runs with full administrative rights. However, the built-in Administrator account is disabled by default.

UAC elevation can be triggered for a new process in one of several ways:

  • The program file contains a manifest that indicates that it requires elevation. Sysinternals GUI utilities such as Disk2Vhd and RAMMap that always require elevation contain such manifests.

  • The user explicitly requests that the program run elevated—for example, by right-clicking it and choosing Run As Administrator from the context menu.

  • Windows heuristically determines that the application is a legacy installation program. (Installer detection is enabled by default, but it can be turned off through a security policy.)

  • The application is associated with a compatibility mode or shim that requires elevation.

If the parent process is already running with an administrative token, the child process simply inherits that token and the UAC elevation sequence is not needed. By convention, console utilities that require administrative rights (for example, Sysinternals LogonSessions) do not request UAC elevation. Instead, you should start them from an elevated command prompt or Windows PowerShell console.

Once triggered, UAC elevation can be accomplished in three ways:

  • Silently The elevation occurs without end-user interaction. This option is available only if the user is a member of the Administrators group. By default in Windows 7, silent elevation is enabled for certain Windows commands. Silent elevation can be enabled for all elevation requests through security policy.

  • Prompt For Consent The user is prompted whether to permit the elevation to occur with a Yes/No dialog box. (See Figure 2.) This option is available only if the user is a member of the Administrators group and is the default (for elevations other than the default silent elevations of Windows 7).

  • Prompt For Credentials The user is prompted to provide credentials for an administrative account. (See Figure 3.) This is the default for nonadministrative accounts and is the only way that UAC elevation can be achieved by a nonadministrative user. You can also configure this option for administrative users with a security policy setting.

Note that UAC elevations can be disabled for standard users via security policy. When the policy is configured, users get an error message whenever an elevation is requested.

Figure 2. Windows 7 elevation prompt for consent.

Figure 3. Windows 7 elevation prompt for credentials.

When User Account Control is disabled, Windows reverts to a mode similar to that of Windows XP. In that case, the LSA does not create filtered tokens, and programs run by members of the Administrators group always run with administrative rights. Further, elevation prompts do not display, but Runas.exe can be used to start a program with administrative rights. Note that disabling UAC also disables Internet Explorer’s Protected Mode, so Internet Explorer runs with the full rights of the logged-on user. Disabling UAC also turns off its file and registry virtualization, a feature that enables many applications that required administrative rights on Windows XP to work with standard user rights.

Other -----------------
- Overview of Process Management in Microsoft Visio 2010 (part 4)
- Overview of Process Management in Microsoft Visio 2010 (part 3) - Validation of process diagrams
- Overview of Process Management in Microsoft Visio 2010 (part 2) - New process flow templates
- Overview of Process Management in Microsoft Visio 2010 (part 1)
- Windows 7 : Working with Scanners and Cameras (part 2) - Manipulating Pictures in Windows Media Player & Printing Your Masterpiece
- Windows 7 : Working with Scanners and Cameras (part 1) - Using Windows Pictures Library with a Digital Camera, Scanner
- Windows 7 : Understanding and Resolving Installation Failures (part 2) - Understanding Installation Restrictions with AppLocker
- Windows 7 : Understanding and Resolving Installation Failures (part 1) - Verifying Software Installation Requirements
- Sysinternals License Information
- The Windows Sysinternals Web Site
- Overview of Internet Explorer 8 (part 4) - Installing Add-Ons to IE8 & Configuring Windows Internet Explorer 8 Options
- Overview of Internet Explorer 8 (part 3) - Using New Security and Safety Features of IE8 & Working with SmartScreen Filters
- Overview of Internet Explorer 8 (part 2) - Defining IE8 Web Slices & Using IE8 Compatibility View
- Overview of Internet Explorer 8 (part 1) - Defining IE8 Accelerators
- Windows 7 : Configuring Hardware and Applications - Managing Applications
- Windows 7 : Configuring Hardware and Applications - Managing Printers
- Windows 7 : Configuring Hardware (part 2) - Installing and Updating Device Drivers & Driver Signing
- Windows 7 : Configuring Hardware (part 1) - Device Stage & Using Device Manager
- Windows 7 : Scripting Windows with PowerShell - Creating PowerShell Scripts
- Windows 7 : Scripting Windows with PowerShell - Scripting Objects
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS
Most View
- SharePoint 2010 : Edit the Contents of a Page
- What's New in SharePoint 2013 (part 1) - THE PROGRAMMING MODEL
- Windows Server 2008 : Controlling Access to Web Services (part 2)
- Sharepoint 2010 : Optimizing Outside of SQL Server
- jQuery 1.3 : Headline rotator (part 6)
- Windows Server 2008 : Configuring Network Authentication (part 1)
- Sharepoint 2010 : Excel Service - Demonstration Scenario (part 1)
- Windows7: Managing Network Connections (part 1)
- Windows Help Desk (Part 2) - AppCleaner backup, Moving partitions to resize them
- SQL Server 2012 : T-SQL Enhancements - The INSERT OVER DML Syntax (part 2) - Consuming CHANGES