Disabling User Account Control (UAC) on Windows Server

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

• Only administrators are able to log on to the Windows Server interactively at the console or by using Remote Desktop Services.
• Administrators log on to the Windows Server only to perform legitimate system administrative functions on the server.

If either of these conditions is not true, UAC should remain enabled. For example, if the server is configured to use the Remote Desktop Services role so that nonadministrative 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 clients, or instant messaging clients, or administrators perform other operations that should be performed from a client operating system such as Windows 7.

Notes

• 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 on Windows 7.
• 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 (KB 969371) is available for Windows Server 2008 Server Core to prevent UAC from being enabled accidentally.

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, such as the following:

• File and Registry Virtualization: When a "legacy" application tries to write to protected areas of the file system or of the registry, Windows silently and transparently redirects the access to a part of the file system or of the registry that the user is allowed to modify. This enables many applications that required administrative rights on earlier versions of Windows to run successfully by using only standard user rights on Windows Vista and on Windows 7.
• Same-desktop Elevation: Elevation lets an authorized user run a program that has greater rights than those of the interactive desktop user. Combined with the Filtered Token feature in UAC, by default, administrators can run all programs by using standard user rights, and administrators can elevate only those programs that require administrative rights by using the same user account. (This Same-desktop Elevation feature is also known as Admin Approval Mode.) Programs can also be started 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 who has administrative or other powerful privileges or group memberships logs on, Windows creates two access tokens that represent the user account. One token, the "unfiltered" token, has all the user’s group memberships and privileges, and the other token, the “filtered” token, represents the user who has the equivalent of standard user rights. By default, this filtered token is used to run the user’s programs. The unfiltered token is associated only with elevated programs. An account that is a member of the Administrators group and that gets a filtered token at logon is frequently 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 that belongs to a higher-privileged process and therefore controlling the higher-privileged process.
• Protected Mode Internet Explorer (PMIE): PMIE is a defense-in-depth feature in which Windows Internet Explorer operates in low-privileged Protected Mode and cannot write to most areas of the file system or of the registry. By default, Protected Mode is enabled when a user browses sites in the Internet or in Restricted Sites zones. PMIE makes it more difficult for malware that infects a running instance of Internet Explorer to change the user’s settings, such as by configuring itself to start every time that the user logs on. Be aware that PMIE is not actually part of UAC. But PMIE depends on UAC features such as UIPI.
• Installer Detection: Consider the following scenario. An interactive user who has standard user rights starts a program. Windows heuristically determines that this program is likely to be a legacy installation program. In this scenario, Windows proactively prompts the user for elevation instead of letting the program run by using standard user rights and then possibly to fail. Be aware that, if the interactive user does not have administrative credentials, the user cannot run the program.

If you disable the User Account Control: Run all administrators in Admin Approval Mode policy setting, this disables all the UAC features that are described in this section. This policy setting is available through the computer's Local Security Policy, Security Settings, Local Policies, and then Security Options. Legacy applications that have standard user rights that expect to write to protected folders or to registry keys will fail. Filtered tokens are not created, and all programs run with the full rights of the user who is logged on to the computer. This includes Internet Explorer because Protected Mode is not enabled for all security zones.

One of the common misconceptions about UAC and about 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 malware can be written to write just to areas in the user’s profile. More important, Same-desktop Elevation in UAC is not a security boundary and can be hijacked by unprivileged software that runs on the same desktop. Same-desktop Elevation should be considered a convenience feature. And, for security, ""Protected Administrator" should be considered the equivalent of “Administrator.” By contrast, if you log on or use Fast User Switching to a different session that has an administrator account, this involves a security boundary between the administrator account and the standard user session. For more information about security boundaries, see the "References" section.

The purpose of the Protected Administrator account on end-user client operating systems such as 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 should see few if any elevation prompts. This is because the programs that 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 these standard users do not have credentials for administrative accounts with which to enable 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 doable nor desirable. For example, 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, such prompts do not and cannot promote the goal of encouraging development of applications that require standard user rights. Also, such prompts do not improve the security posture. Instead, these prompts just encourage users to click through dialog boxes without reading them.

Be aware 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, administrative users should log on only to perform legitimate administrative functions. If administrators 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 the equivalent of a client system. In this case, UAC should remain enabled as a defense-in-depth measure.

Also, if standard users log on to the server at the console or through Remote Desktop services to run applications, and this includes web browsers, UAC should remain enabled to support file and registry virtualization and running 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. By using this setting, elevation requests are silently approved if the user who is logged on is a member of the Administrators group. This option also leaves PMIE and other UAC features enabled. However, not all operations that require administrative rights request elevation. In this case, some of the user’s programs may be elevated, and some programs may not be elevated. Typically, there is no way to distinguish between these two kinds of programs. For example, most console utilities that require administrative rights expect to be started from an command prompt that is already elevated or from other elevated program. Such utilities merely fail when they are started from a command prompt that is not elevated.

Additional Impact of Disabling UAC

• If UAC is 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 commands have no effect, and applications run in the same security context as the user who is logged on.
• If UAC is enabled, when the console utility Runas.exe is used to start a program as a user who is subject to token filtering, the program that is started runs with the user’s filtered token. If UAC is disabled, the program that is started runs with the user’s full token.
• If UAC is enabled, local accounts cannot be used for remote administration over network interfaces other than Remote Desktop (for example, by using NET USE or by using IIS Windows authentication). A local account that authenticates over such an interface obtains only the privileges that are granted to the account’s filtered token. If UAC is disabled, this restriction is removed. For more information about this feature and about a configuration setting to remove the feature, click the following article number to view the article in the Microsoft Knowledge Base:  
  951016  (http://support.microsoft.com/kb/951016/ ) Description of User Account Control and remote restrictions in Windows Vista

REFERENCES

• Inside Windows Vista User Account Control
  http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx (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 (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 (http://blogs.technet.com/b/markrussinovich/archive/2007/02/12/638372.aspx)