Megosztás a következőn keresztül:

User Account Control

  • Cikk

Applies To: Windows Server 2008, Windows Vista

User Account Control (UAC) is a new security component of the Windows Server® 2008 and Windows Vista® operating systems.

What does User Account Control do?

UAC allows an administrator to enter credentials during a non-administrator's user session to perform occasional administrative tasks without having to switch users, log off, or use the Run as command.

UAC also can also require administrators to specifically approve applications that will make "system-wide" changes before those applications are allowed to run, even in the administrator's user session.

Who will be interested in this feature?

Understanding the operation of UAC is important for the following groups:

  • Administrators

  • IT security professionals

  • Developers creating applications for Windows Server 2008 or Windows Vista

Are there any special considerations?

At first, users might encounter a larger number of UAC prompts because there are a lot of system-wide changes to make when first configuring the operating system. Over time, however, those kinds of changes become much less frequent.

While UAC appears in both Windows Server 2008 and Windows Vista, the default configurations differ in the following ways:

  • The Admin Approval Mode (AAM), by default, is not enabled for the Built-in Administrator Account in either Windows Server 2008 or Windows Vista.

  • The Built-in Administrator account is disabled by default in Windows Vista, and the first user account created is placed in the local Administrators group, and AAM is enabled for that account.

  • The Built-in Administrator account is enabled by default in Windows Server 2008. AAM is disabled for this account.

What new functionality does this feature provide?

UAC includes several features and security improvements.

Admin Approval Mode

Admin Approval Mode (AAM) is a UAC configuration in which a split user access token is created for an administrator. When an administrator logs on to a Windows Server 2008-based computer, the administrator is assigned two separate access tokens. Without AAM, an administrator account receives only one access token, which grants that administrator access to all Windows resources.

Why is this functionality important?

AAM helps prevent malicious programs from silently installing without an administrator's knowledge. It also helps protect from inadvertent system-wide changes. Lastly, it can be used to enforce a higher level of compliance where administrators must actively consent or provide credentials for each administrative process.

What works differently?

The primary difference between a standard user (a non-administrator) and an administrator in Windows Server 2008 is the level of access the user has over core, protected areas of the computer. Administrators can change system state, turn off the firewall, configure security policy, install a service or a driver that affects every user on the computer, and install software programs for the entire computer. Standard users cannot perform these tasks.

When AAM is enabled, an administrator receives both a full access token and a second access token, called the filtered access token. During the logon process, authorization and access control components that identify an administrator are removed or disabled, to create the filtered access token. The filtered access token is then used to start Explorer.exe, the process that creates and owns the user's desktop. Because applications normally inherit their access token from the process that starts them, which in this case is Explorer.exe, they all run with the filtered access token as well.

Note

When a standard user logs on, only one user access token is created. A standard user's full access token grants no more access privileges than an administrator's filtered access token.

After an administrator logs on, the administrator's full access token is not used unless until he or she attempts to perform an administrative task.

Important

Because the user experience is configurable with the Local Group Policy Editor (secpol.msc) and with the Group Policy Management Console (GPMC) (gpedit.msc), there is no single UAC user experience.

By the nature of how a server is used, except for terminal servers, an administrator logs on to a server much more frequently than an administrator needs to log on to a client workstation. For this reason, AAM is disabled by default for the Built-In Administrator account in Windows Server 2008. By default, AAM is enabled for other accounts that are members of the local Administrators group.

How do I resolve any issues?

If the operating system cannot correctly identify an administrative application, it might fail to run properly, because it does not use the full access token.

For more information about how to use configure existing applications, see Additional resources later in this topic.

How should I prepare for this change?

For information about planning, see How should I prepare to deploy this feature? later in this topic.

Elevation for standard users

The elevation prompt appears when a standard user attempts to perform a task that requires privileges not held by a standard user. In this case, however, the prompt requires the entry of administrative credentials.

Why is this functionality important?

UAC allows an administrator to enter credentials during a standard user's session to perform occasional administrative tasks without having to switch users, log off, or use the Run as command.

What works differently?

Without UAC, applications attempt to run but fail when they attempt an operation that requires administrator privileges. Some applications detect this gracefully, while others do not.

In some cases, the appearance of the elevation prompt requesting credentials might generate confusion for users or additional help-desk calls. Therefore, you might prefer that users not see these prompts, and that the application simply be prevented from starting.

How do I resolve these issues?

This standard user default prompt behavior is configurable with the Local Group Policy Editor (secpol.msc) and with the Group Policy Management Console (GPMC) (gpedit.msc).

How should I prepare for this change?

For information about planning, see How should I prepare to deploy this feature? later in this topic.

Shield icon

Administrative tasks and programs are marked with a new "shield" icon.

Why is this functionality important?

The shield icon is used consistently in Windows Server 2008 to indicate that starting a particular task or program requires administrative privileges. This helps make it clear what requires elevation, educating users and administrators, and reducing help-desk calls.

UAC file and registry virtualization

Windows Server 2008 includes file and registry virtualization technology for applications that are not UAC compliant and that may require an administrator's access token to run correctly.

Why is this functionality important?

UAC virtualization helps ensure that even applications that are not UAC compliant are compatible with Windows Server 2008.

What works differently?

When a non-UAC-compliant administrative application attempts to write to a protected directory, such as Program Files, UAC gives the application its own virtualized view of the resource it is attempting to change, using a copy-on-write strategy. The virtualized copy is maintained under the user's profile. As a result, a separate copy of the virtualized file is created for each user that runs the non-compliant application.

The virtualization technology ensures that non-compliant applications do not silently fail to run or fail in a way that is inconsistent and hard to troubleshoot.

Note

Virtualization does not apply to applications that require a full access token.

How do I resolve these issues?

Most application tasks operate properly using virtualization features. However, UAC virtualization is a short-term fix and not a long-term solution. Application developers should modify their applications to be compliant with UAC as soon as possible, rather than relying on file, folder, and registry virtualization.

For guidance about how to design applications to be UAC compliant, see Additional resources.

Note

Virtualization will not be supported on native Windows 64-bit applications. These applications are required to work with UAC and to write data into the correct locations.

Note

Virtualization is disabled for an application if a program includes an application manifest with a requested execution level attribute.

How should I prepare for this change?

For information about planning, see How should I prepare to deploy this feature? later in this topic.

What settings have been added or changed?

The following system settings control the behavior of UAC in Windows Server 2008. You can configure these settings by using the Local Group Policy Editor (secpol.msc) or the GPMC (gpedit.msc).

The following settings can be found in the Security Options node of Local Policy, under Security Settings.

Setting Description Default Value

User Account Control: Admin Approval Mode for the Built-in Administrator account.

Two possible settings:

  • Enabled—The Built-in Administrator runs as an administrator in Admin Approval Mode.

  • Disabled—The administrator always runs with a full access token.

Disabled

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

Three possible values:

  • No prompt—The elevation occurs automatically and silently. This option allows an administrator in Admin Approval Mode to perform an operation that requires elevation without consent or credentials.

    Note
    This scenario should only be used in the most constrained environments and is NOT recommended.

  • Prompt for consent—An operation that requires a full access token prompts the administrator in Admin Approval Mode to select either Continue or Cancel. If the administrator clicks Continue, the operation continues with the highest available privilege.

  • Prompt for credentials—An operation that requires a full access token prompts an administrator in Admin Approval Mode to enter an administrator user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.

Prompt for consent

User Account Control: Behavior of the elevation prompt for standard users

Two possible values:

  • No prompt—No elevation prompt is presented and the user cannot perform administrative tasks without using Run as administrator or by logging on with an administrator account. Most enterprises running desktops as standard user will configure the “No prompt” policy to reduce help desk calls.

  • Prompt for credentials—An operation that requires a full access token prompts the user to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.

Prompt for credentials

User Account Control: Detect application installations and prompt for elevation

Two possible values:

  • Enabled—The user is prompted for consent or credentials when Windows detects an installer.

  • Disabled—Application installations are allowed to run, but they are denied access to system-wide resources. This can result in failures that might be difficult to troubleshoot. In an enterprises environment, with standard user desktops, or managed installation technologies, such as System Management Server (SMS), installer detection is unnecessary and you might want to disable this setting.

Enabled

User Account Control: Only elevate executables that are signed and validated

Two possible values:

  • Enabled—Only signed executable files will run. This policy enforces public key infrastructure (PKI)-based signature checks on any interactive application that requests elevation. Enterprise administrators can control the administrative application allowed list through the population of certificates in the local computers Trusted Publisher Store.

  • Disabled—Both signed and unsigned code will run.

Disabled

User Account Control: Only elevate UIAccess applications that are installed in secure locations

Two possible values:

  • The system will only give UIAccess privileges and user rights to executables that are started under %ProgramFiles% or %windir%. The access control lists (ACLs) on these directories ensure that the executable is not user-modifiable (which would otherwise allow elevation of privilege). UIAccess executables started from other locations start without additional privileges (that is, they run "asInvoker").

  • Disabled—The location checks are not done, so all UIAccess applications start with the user's full access token upon user approval.

Enabled

User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop

Two possible values:

  • Enabled -UIAccess programs, including Windows Remote Assistance, can automatically disable the secure desktop for elevations prompts. This allows increased functionality in certain UIAccess scenarios, including when providing remote assistance to a standard user.

  • Disabled—the secure desktop can only be disabled by an administrator at the computer or by Group Policy.

Disabled

User Account Control: Run all administrators in Admin Approval Mode

Two possible values:

  • Enabled—Both administrators and standard users are prompted when attempting to perform administrative operations. The prompt style is dependent on policy.

  • Disabled—UAC is essentially "turned off" and the Application Information Service (AIS) service is disabled from automatically starting. The Windows Security Center also notifies the logged on user that the overall security of the operating system has been reduced and gives the user the ability to self-enable UAC.

    Note

    Changing this setting requires a system restart.

Enabled

User Account Control: Switch to the secure desktop when prompting for elevation

Two possible values:

  • Enabled—Displays the UAC elevation prompt on the secure desktop. The secure desktop can only receive messages from Windows processes, which eliminates messages from malicious software.

  • Disabled—The UAC elevation prompt is displayed on the interactive (user) desktop.

Enabled

User Account Control: Virtualize file and registry write failures to per-user locations

Two possible values:

  • Enabled—This policy enables the redirection of pre-Windows Vista application write failures to defined locations in both the registry and file system. This feature mitigates those applications that historically ran as administrator and wrote runtime application data back to %ProgramFiles%; %Windir%; %Windir%\system32; or HKLM\Software. This setting should be kept enabled in environments that utilize non-UAC compliant software. Applications that lack an application compatibility database entry or a requested execution level marking in the application manifest are not UAC compliant.

  • Disabled—Virtualization facilitates the running of pre-Windows Vista (legacy) applications that historically failed to run as a standard user. An administrator running only Windows Vista-compliant applications might choose to disable this feature as it is unnecessary. Non-UAC compliant applications that attempt to write %ProgramFiles%; %Windir%; %Windir%\system32; or HKLM\Software silently fail if this setting is disabled.

Enabled

Do I need to change any existing code?

New applications should be written to be able to work with UAC, and should include an embedded manifest.

For more information about creating new programs for Windows Server 2008 and Windows Vista, see Additional resources.

How should I prepare to deploy this feature?

UAC can significantly reduce your exposure to malicious software and allow older applications to run with standard user credentials. In order to have the greatest success with UAC, see the information listed in Additional resources.

Is this feature available in all editions of Windows Server 2008?

UAC is an integral part of the operating system in all editions of Windows Server 2008. UAC is also part of the Windows Vista operating system.

Additional resources

For more detailed information about UAC, see the following: