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
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

 


Comments (6)

  1. Scotte says:

    I appreciate the guidance. I've been leaving UAC enabled on my servers, but it has become a major nuisance for the reasons you've mentioned.  One I don't see though is elevating explorer.exe properly. With UAC enabled, I'm unable to open drives that permissioned soley as Administrator:F and SYSTEM:F.

    I've tried opening explorer in separate processes using a variety of means, including explorer /separate and setting "Launch folder windows in a separate process". I simply get "Access denied". No UAC prompt given. This has been very frustrating.

    The best option I've found is browsing from the "Open file" dialog from an elevated notepad.exe. This at least lets me use access the file system through the GUI. As much as I love the command line, there are some times the GUI is just better.

    [Aaron Margosis]  I thought about including something about that Explorer issue, which is (somewhat) documented in KB 950934.  That problem goes away with UAC off.  I may add that in, but I need to word it carefully.  That by itself is not a good reason to disable UAC.

  2. Dean says:

    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.

  3. Drewfus says:

    "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.

  4. Scotte says:

    KB 950934 doesn't address the issue I'm describing. I don't get a a prompt of any kind. There's no option to enter credentials that then get added to the DACL. I'm not a big fan of that either, but regardless I don't even get the option.

    To see my issue, log in as a domain admin (not the actual domain administrator account), which makes you a member of the local administrators group.  Try to open a drive that's permissioned solely with Administrators:F and SYSTEM:F

    I can't open it no way no how from explorer, short of disabling UAC.

    [Aaron Margosis]  Yes, that is a pain point.  A couple of things you can do (I know they're not great, but they ARE options):

    * Browse with elevated Cmd.exe; fix permissions with icacls (assuming you don't want the permissions that way);

    * Launch elevated Notepad; press Ctrl+O, change type of file shown from "Text files" to "All files"; use that Explorer-like interface.

    * Use a third party shell folder browser / Explorer replacement.  (I'm not familiar with what's available there, though.)

    * Not recommended and can cause all kinds of interesting issues, but kill Explorer.exe then start Explorer again from an elevated Cmd.

  5. BILL F says:

    I have been doing a lot of research and your topics come close to what Iam seeking. My situation is that I am running a fail over cluster that needs to start an application after the fail over occurs, The problem that I am having is that the program runs in the interactive dialog screen which is referenced in Session 0. I need the app to run in Session 1 which is the logged in user (ADMIN). I have tried all suggestions to no avail. This includes compatability mode, "Admin Protection Mode, UAC settings enabled and disabled. Nothing works and I have the same scenario. Any Ideas would be greatly appreciated. This is a must function! This is on Windows 2008 Server platform. I can access the session 0 thru the Interactive dialog box and see my app running, but certain parts of the program wont fuction in that environment. Thanks.

    [Aaron Margosis]  This has nothing to do with UAC.  This is about "session 0 isolation" and the fact that beginning with Windows Vista and Server 2008 all interactive users log on to terminal services session 1 or higher.  This was done in order to provide more isolation between interactive users' desktop applications and Windows services which continue to run in TS session 0.  These services displaying UI on standard user desktops created a huge elevation of privilege risk, and with the move in Vista/2008 to running as standard user by default, blocking that scenario became more important.  You have already identified the one mitigation, which is the Interactive Services Detection (UI0Detect) service which allows the interactive user to switch temporarily over to the session 0 interactive desktop to interact with the app.  (This still prevents desktop applications from interacting with the service or attempting to send window messages to it, which was a large part of the threat.)  Ultimately, the app needs to be redesigned, replaced or discarded.  Services can still use the MessageBox API with the MB_SERVICE_NOTIFICATION flag to display a message to an interactive user with minimal rewrite.  For more complex UI, the preferred model is for an app to run on the interactive user's desktop as the interactive user, and for it to interact with the service over a tightly-constrained and thoroughly threat-modeled inter-process communication mechanism such as named pipes.

  6. Derek Melber, MVP says:

    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.