Applies To

Windows Server 2008 (all editions except Server Core)

Windows Server 2008 R2 (all editions except Server Core)

Summary

Under certain constrained circumstances, disabling User Account Control (UAC) on Windows Server can be an acceptable and recommended practice. These circumstances arise only when both of the following are true:

  • Only Administrators are allowed to log on to the Windows Server interactively at the console or through Remote Desktop services.

 

  • Administrators log on to the Windows Server only to perform legitimate system administrative functions on the Server.

If either of the above is not true, then UAC should remain enabled. For example, if the Server is configured with the Remote Desktop Services role so that non-administrative users can log on to the Server to run applications, UAC should remain enabled. Similarly, UAC should also remain enabled if administrators run risky applications on the Server such as web browsers, email or instant messaging clients, or perform other operations that should be performed from a client operating system such as Windows 7.

Note that this guidance applies only to Windows Server operating systems such as Windows Server 2008 and Windows Server 2008 R2. UAC should always remain enabled on client operating systems such as Windows Vista and Windows 7.

Note also that UAC is always disabled on Windows Server 2008 R2 Server Core and should always be kept disabled on Windows Server 2008 Server Core. A hotfix is available for Windows Server 2008 Server Core (KB 969371) to prevent UAC from being enabled accidentally.

More Information

User Account Control (UAC) was introduced in Windows Vista and enhanced in Windows 7 to help Windows users move toward using standard user rights by default. UAC includes several technologies to achieve this:

  • File and Registry Virtualization. When a "legacy" application tries to write to protected areas of the file system or registry, Windows silently and transparently redirects the access to a portion of the file system or registry that the user is allowed to modify. This enables many applications that required administrative rights on earlier versions of Windows to run successfully with only standard user rights on Windows Vista and Windows 7.
  • Same-desktop Elevation. Elevation allows an authorized user to run a program with greater rights than those of the interactive desktop user. Combined with UAC's "Filtered Token" feature, this allows administrators to run all programs with standard user rights by default and to elevate only those programs that require administrative rights with the same user account. (This feature is also known as "Admin Approval Mode".) Programs can also be launched with elevated rights under a different user account, so that an administrator can perform administrative tasks on a standard user's desktop.
  • Filtered Token. When a user with administrative or other powerful privileges or group memberships logs on, Windows creates two access tokens representing the user account. One has all the user's group memberships and privileges, while the "filtered" token represents the user with the equivalent of standard user rights and is used to run the user's programs by default. The unfiltered token is associated only with elevated programs. An account that is a member of the Administrators group and gets a filtered token at logon is often called a "Protected Administrator" account.
  • User Interface Privilege Isolation (UIPI). UIPI prevents a lower-privileged program from sending window messages such as synthetic mouse or keyboard events to a window belonging to a higher-privileged process and thus controlling it.
  • Protected Mode Internet Explorer (PMIE). PMIE is a defense-in-depth feature in which Internet Explorer operates in low-privileged "Protected Mode" and cannot write to most areas of the file system or registry. Protected Mode is "on" by default when browsing sites in the Internet or Restricted Sites zones. PMIE makes it more difficult for malware that infects a running instance of IE to change the user's settings, such as by configuring itself to start every time the user logs on. (PMIE is not actually part of UAC but depends on UAC features such as UIPI.)
  • Installer Detection. When an interactive user running with standard user rights starts a program that Windows heuristically determines is likely to be a legacy installation program, Windows proactively prompts the user for elevation, rather than allow the program to run with standard user rights and possibly fail. Note that if the interactive user does not have administrative credentials, the user will not be able to run the program.

In Local Security Policy | Security Settings | Local Policies | Security Options, disabling the policy named "User Account Control: Run all administrators in Admin Approval Mode" disables all the UAC features described above. Legacy applications with standard user rights that expect to write to protected folders or registry keys will fail. Filtered tokens are not created, and all programs run with the logged on user's full rights. This includes Internet Explorer, as Protected Mode is "off" for all security zones.

One of the common misconceptions about UAC - and same-desktop elevation in particular - is that it prevents malware from being installed or from gaining administrative rights. First, malware can be written not to require administrative rights, and to write only to areas in the user's profile. More importantly, UAC's same-desktop elevation is not a security boundary and can be hijacked by unprivileged software running on the same desktop. Same-desktop elevation should be considered a convenience feature, and for security purposes "Protected Administrator" should be considered equivalent to "Administrator". By contrast, logging in or Fast User Switching to a different session with an administrator account involves a security boundary between it and the standard user session. (See the References section for more information about security boundaries.)

The purpose of the Protected Administrator account on end user client operating systems (Windows Vista and Windows 7) is to encourage developers to write their applications to require only standard user rights while enabling as many applications that share state between administrative components and standard user components to continue working. The stated goal and expectation is that over time end users would see few if any elevation prompts, as the programs they run should never require administrative rights. This becomes increasingly necessary as more enterprises adopt a model in which their end users log on as standard users and do not have credentials for administrative accounts with which to allow elevations.

However, for a Windows Server on which the sole reason for interactive logon is to administer the system, the goal of fewer elevation prompts is neither feasible nor desirable. System administrative tools legitimately require administrative rights. When all the administrative user's tasks require administrative rights and each task could trigger an elevation prompt, the prompts are only a hindrance to productivity. In this context, they do not and cannot promote the goal of encouraging development of applications that require standard user rights. Nor do they improve security posture. Instead they simply encourage users to click through dialog boxes without reading them.

Note that this guidance applies only to well-managed Servers on which only administrative users are allowed to log on interactively or through Remote Desktop services, and they do so only to perform legitimate administrative functions. If they run risky applications such as web browsers, email or instant messaging clients, or perform other operations that should be performed from a client operating system, then the Server should be considered equivalent to a client system and UAC should remain enabled as a defense-in-depth measure.

Further, if standard users log on to the Server at the console or through Remote Desktop services to run applications, including web browsers, UAC should remain enabled to support file and registry virtualization as well as Protected Mode Internet Explorer.

Another option to avoid elevation prompts without disabling UAC is to set the security policy, "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" to "Elevate without prompting." With this setting, elevation requests are silently approved if the logged-on user is a member of the Administrators group. This also leaves PMIE and other UAC features enabled. However, not all operations that require administrative rights request elevation. This can result in a situation in which some of the user's programs are elevated and some are not, often with no way to distinguish between them. For example, most console utilities that require administrative rights expect to be launched from an already-elevated Command Prompt or other elevated program. Such utilities simply fail when launched from a non-elevated Command Prompt.

Additional impact of disabling UAC

  • With UAC disabled, Windows Explorer continues to display UAC "shield" icons for items that require elevation and to include "Run as administrator" in the context menus of applications and application shortcuts. Because the UAC elevation mechanism is disabled, these have no effect, and applications run in the same security context as the logged-on user.
  • With UAC enabled, when the console utility Runas.exe is used to launch a program as a user that is subject to token filtering, the launched program runs with the user's filtered token. With UAC disabled, the launched program runs with the user's full token.
  • With UAC enabled, local accounts cannot be used for remote administration over network interfaces other than Remote Desktop (e.g., via NET USE or IIS' Windows authentication). A local account that authenticates over such an interface gets only the privileges granted to the account's filtered token. With UAC disabled, this restriction is removed. (This feature and a configuration setting to remove it are described in Microsoft KB article 951016.)

References

Inside Windows Vista User Account Control
http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx

Inside Windows 7 User Account Control
http://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx

PsExec, User Account Control and Security Boundaries
http://blogs.technet.com/b/markrussinovich/archive/2007/02/12/638372.aspx

Applies To

 

Windows Server 2008 (all editions except Server Core)

Windows Server 2008 R2 (all editions except Server Core)

Summary

Under certain constrained circumstances, disabling User Account Control (UAC) on Windows Server can be an acceptable and recommended practice. These circumstances arise only when both of the following are true:

·         Only Administrators are allowed to log on to the Windows Server interactively at the console or through Remote Desktop services.

·         Administrators log on to the Windows Server only to perform legitimate system administrative functions on the Server.

If either of the above is not true, then UAC should remain enabled. For example, if the Server is configured with the Remote Desktop Services role so that non-administrative users can log on to the Server to run applications, UAC should remain enabled. Similarly, UAC should also remain enabled if administrators run risky applications on the Server such as web browsers, email or instant messaging clients, or perform other operations that should be performed from a client operating system such as Windows 7.

Note that this guidance applies only to Windows Server operating systems such as Windows Server 2008 and Windows Server 2008 R2. UAC should always remain enabled on client operating systems such as Windows Vista and Windows 7.

Note also that UAC is always disabled on Windows Server 2008 R2 Server Core and should always be kept disabled on Windows Server 2008 Server Core. A hotfix is available for Windows Server 2008 Server Core (KB 969371) to prevent UAC from being enabled accidentally.

More Information

User Account Control (UAC) was introduced in Windows Vista and enhanced in Windows 7 to help Windows users move toward using standard user rights by default. UAC includes several technologies to achieve this:

·         File and Registry Virtualization. When a “legacy” application tries to write to protected areas of the file system or registry, Windows silently and transparently redirects the access to a portion of the file system or registry that the user is allowed to modify. This enables many applications that required administrative rights on earlier versions of Windows to run successfully with only standard user rights on Windows Vista and Windows 7.

·         Same-desktop Elevation. Elevation allows an authorized user to run a program with greater rights than those of the interactive desktop user. Combined with UAC’s “Filtered Token” feature, this allows administrators to run all programs with standard user rights by default and to elevate only those programs that require administrative rights with the same user account. (This feature is also known as “Admin Approval Mode”.) Programs can also be launched with elevated rights under a different user account, so that an administrator can perform administrative tasks on a standard user’s desktop.

·         Filtered Token. When a user with administrative or other powerful privileges or group memberships logs on, Windows creates two access tokens representing the user account. One has all the user’s group memberships and privileges, while the “filtered” token represents the user with the equivalent of standard user rights and is used to run the user’s programs by default. The unfiltered token is associated only with elevated programs. An account that is a member of the Administrators group and gets a filtered token at logon is often called a “Protected Administrator” account.

·         User Interface Privilege Isolation (UIPI). UIPI prevents a lower-privileged program from sending window messages such as synthetic mouse or keyboard events to a window belonging to a higher-privileged process and thus controlling it.

·         Protected Mode Internet Explorer (PMIE). PMIE is a defense-in-depth feature in which Internet Explorer operates in low-privileged “Protected Mode” and cannot write to most areas of the file system or registry. Protected Mode is “on” by default when browsing sites in the Internet or Restricted Sites zones. PMIE makes it more difficult for malware that infects a running instance of IE to change the user’s settings, such as by configuring itself to start every time the user logs on. (PMIE is not actually part of UAC but depends on UAC features such as UIPI.)

·         Installer Detection. When an interactive user running with standard user rights starts a program that Windows heuristically determines is likely to be a legacy installation program, Windows proactively prompts the user for elevation, rather than allow the program to run with standard user rights and possibly fail. Note that if the interactive user does not have administrative credentials, the user will not be able to run the program.

In Local Security Policy | Security Settings | Local Policies | Security Options, disabling the policy named “User Account Control: Run all administrators in Admin Approval Mode” disables all the UAC features described above. Legacy applications with standard user rights that expect to write to protected folders or registry keys will fail. Filtered tokens are not created, and all programs run with the logged on user’s full rights. This includes Internet Explorer, as Protected Mode is “off” for all security zones.

One of the common misconceptions about UAC – and same-desktop elevation in particular – is that it prevents malware from being installed or from gaining administrative rights. First, malware can be written not to require administrative rights, and to write only to areas in the user’s profile. More importantly, UAC’s same-desktop elevation is not a security boundary and can be hijacked by unprivileged software running on the same desktop. Same-desktop elevation should be considered a convenience feature, and for security purposes “Protected Administrator” should be considered equivalent to “Administrator”. By contrast, logging in or Fast User Switching to a different session with an administrator account involves a security boundary between it and the standard user session. (See the References section for more information about security boundaries.)

The purpose of the Protected Administrator account on end user client operating systems (Windows Vista and Windows 7) is to encourage developers to write their applications to require only standard user rights while enabling as many applications that share state between administrative components and standard user components to continue working. The stated goal and expectation is that over time end users would see few if any elevation prompts, as the programs they run should never require administrative rights. This becomes increasingly necessary as more enterprises adopt a model in which their end users log on as standard users and do not have credentials for administrative accounts with which to allow elevations.

However, for a Windows Server on which the sole reason for interactive logon is to administer the system, the goal of fewer elevation prompts is neither feasible nor desirable. System administrative tools legitimately require administrative rights. When all the administrative user’s tasks require administrative rights and each task could trigger an elevation prompt, the prompts are only a hindrance to productivity. In this context, they do not and cannot promote the goal of encouraging development of applications that require standard user rights. Nor do they improve security posture. Instead they simply encourage users to click through dialog boxes without reading them.

Note that this guidance applies only to well-managed Servers on which only administrative users are allowed to log on interactively or through Remote Desktop services, and they do so only to perform legitimate administrative functions. If they run risky applications such as web browsers, email or instant messaging clients, or perform other operations that should be performed from a client operating system, then the Server should be considered equivalent to a client system and UAC should remain enabled as a defense-in-depth measure.

Further, if standard users log on to the Server at the console or through Remote Desktop services to run applications, including web browsers, UAC should remain enabled to support file and registry virtualization as well as Protected Mode Internet Explorer.

Another option to avoid elevation prompts without disabling UAC is to set the security policy, “User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode” to “Elevate without prompting.” With this setting, elevation requests are silently approved if the logged-on user is a member of the Administrators group. This also leaves PMIE and other UAC features enabled. However, not all operations that require administrative rights request elevation. This can result in a situation in which some of the user’s programs are elevated and some are not, often with no way to distinguish between them. For example, most console utilities that require administrative rights expect to be launched from an already-elevated Command Prompt or other elevated program. Such utilities simply fail when launched from a non-elevated Command Prompt.

Additional impact of disabling UAC

·         With UAC disabled, Windows Explorer continues to display UAC “shield” icons for items that require elevation and to include “Run as administrator” in the context menus of applications and application shortcuts. Because the UAC elevation mechanism is disabled, these have no effect, and applications run in the same security context as the logged-on user.

·         With UAC enabled, when the console utility Runas.exe is used to launch a program as a user that is subject to token filtering, the launched program runs with the user’s filtered token. With UAC disabled, the launched program runs with the user’s full token.

·         With UAC enabled, local accounts cannot be used for remote administration over network interfaces other than Remote Desktop (e.g., via NET USE or IIS’ Windows authentication). A local account that authenticates over such an interface gets only the privileges granted to the account’s filtered token. With UAC disabled, this restriction is removed. (This feature and a configuration setting to remove it are described in Microsoft KB article 951016.)

References

Inside Windows Vista User Account Control
http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx

Inside Windows 7 User Account Control
http://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx

PsExec, User Account Control and Security Boundaries
http://blogs.technet.com/b/markrussinovich/archive/2007/02/12/638372.aspx