Disabling User Account Control (UAC) on Windows Server

[Update May 17, 2011: this blog post has been republished as Microsoft Knowledge Base article 2526083]

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
https://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx

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

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

Comments

• Anonymous
  March 04, 2011
  The comment has been removed

• Anonymous
  March 05, 2011
  How can you say in one sentence "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." and then in another sentence say "UAC should remain enabled as a defense-in-depth measure." If it doesn't prevent malware from being installed then what defense-in-depth is it providing ? Be honest. [Aaron Margosis]  A fair question, of course.  While UAC elevation is not a watertight boundary against elevation of privilege, it can mitigate the effects of malware that doesn’t know how to work around it.  Today there is still a lot of malware that doesn’t, but that will inevitably change.

• Anonymous
  March 09, 2011
  "PMIE is not actually part of UAC but depends on UAC features such as UIPI." Aaron, i'm interested in knowing exactly what the relationship is between PMIE and UIPI, and also the affects on file and registry virtualization of having PMIE turned on or off, as discussed here: blogs.msdn.com/.../is-uac-virtualization-enabled-for-internet-explorer-in-protected-mode.aspx I guess i'm requesting a blog on this at some point. Thanks for the current info. [Aaron Margosis]  It depends on UIPI so that malware that takes over a Low IL iexplore.exe process cannot pump synthetic key/mouse input or other such window messages to Medium IL apps on the desktop (like Explorer). The intersection of PMIE and some of those redirections gets pretty strange.  I actually gave a talk at a TechEd in 2008 called "Vista Security Weirdness" on that topic.

• Anonymous
  March 10, 2011
  The comment has been removed

• Anonymous
  March 29, 2011
  The comment has been removed

• Anonymous
  April 07, 2011
  I have only met Aaron one time, but we think so much alike we might be twins! Aaron strives to help all companies by promoting least privilege... for desktops and servers. Here, Aaron is helping everyone with that quest! Thanks Aaron. Only thing I will add is that UAC alone for "standard users" is not going to work! Here, Aaron is talking about Admins, not standard users. For your users, you will need to also implement a solution like BeyondTrust PowerBroker (www.beyondtrust.com), which will allow the user to run any features, application, etc as an admin, but remain a standard user! Yahoo! I love PowerBroker for Admins too... it is an elegant solution to what many complain about above, which is special processes that have issues with UAC. PowerBroker runs before the UAC proompt, so most of these issues go away, while still running UAC! Derek Melber [Aaron Margosis]  Thanks for the kind words, Derek.  For the record, though, I do not endorse or recommend elevation tools like the one you mentioned.  They do serve a purpose and there are niche cases where such offerings may be the best option, but I find those cases to be extremely rare.  There are several much safer ways to get apps that "require" admin rights to work without admin rights and that don't create a risk of unauthorized elevation of privilege.  If my customer (US Fed govt) shuts down next week or the week after, maybe I'll have some more time to update my recommendations here.