How to configure Windows UAC prompt behavior for admins and users
Microsoft introduced the User Account Control in Windows Vista in a way that it got on the nerves of many users of the system due the the sheer number of prompts that users of the operating system were bombarded with. The UAC behavior has been improved since then; the number of prompts that users receive when they work with the computer system was reduced significantly.
The behavior is not overly optimized though. You do for instance receive UAC prompts even if you are logged in with an admin account which experienced users who know what they are doing may not like at all.
What many Windows users do not know is that it is possible to modify the default User Account Control behavior. The Windows Registry holds two keys that define the UAC behavior for admins and standard users.
You need to open the Windows Registry first to check how the keys are configured on your system:
- Use Windows-R to bring up the run box on the system. Type in regedit and hit the enter key to load the Registry. You will get an UAC prompt that you need to accept.
- Navigate to the following path using the sidebar folder structure: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
This key defines the User Account Control behavior for system administrators. The default value is set to prompt but do not require credentials to be entered. Here are all possible values:
- 0: A value of 0 allows administrators to perform operations that require elevation without consent (meaning prompts) or credentials (meaning authentication).
- 1: A value of 1 requires the admin to enter username and password when operations require elevated privileges on a secure desktop.
- 2: The value of 2 displays the UAC prompt that needs to be permitted or denied on a secure desktop. No authentication is required.
- 3:Â A value of 3 prompts for credentials.
- 4: A value of 4 prompts for consent by displaying the UAC prompt.
- 5: The default value of 5 prompts for consent for non-Windows binaries.
- 0: A value of 0 will automatically deny any operation that requires elevated privileges if executed by standard users.
- 1: The value of 1 will display a prompt to enter the username and password of an administrator to run the operation with elevated privileges on the secure desktop.
- 3: The default value of 3 prompts for credentials on a secure desktop.
The changes should take effect immediately. You can for instance set the admin behavior to 0 so that no prompts are displayed, and user behavior to 0 as well to prevent them from running operations that require elevated privileges.
Additional keys are available, here is a quick overview of them:
- EnableInstallerDetection set to 1 on all versions of Windows except Enterprise where it is set to 0. It determines whether application installations prompt for elevation (0 disabled, 1 enabled).
- PromptOnSecureDesktop determines whether UAC prompts are displayed on a secure desktop (1, default) or not (0). This gets rid of the full screen prompt when disabled.
- FilterAdministratorToken is disabled by default (0) but can be set to (1) instead which would require the user to approve operations that require elevations of privileges.
- EnableUIADesktopToggleÂ is disabled by default (0). It determines whether UIAccess applications can prompt for elevation without the secure desktop. UIAccess applications are digitally signed, and only run from protected paths (program files, program files(x86) and system32). Setting it to (1) enables it.
- EnableSecureUIAPaths is enabled by default (1). If disabled (0), will allow the execution of UIAccess applications from non-secure locations.
- ValidateAdminCodeSignatures is disabled by default (0). When enabled (1), enforces PKI certification path validation for executable files before they are permitted to run.
- EnableLUA enabled by default (1). If disabled (0), will disable admin approval mode and all related UAC policy settings.
- EnableVirtualization enabled (1) by default which redirects application write failures at run time to defined user locations. Applications that write data to protected locations will fail if disabled (0.
Additional information about each setting as well as their corresponding Group Policy settings are available on Microsoft's Technet website.
UAC is best configured thru Secpol.msc instead of thru registry.
GK could you be a little more explicit:)?
Where do I go and what do I do after I get to LSP?
Secpol.msc is the best way. You can find it by typinfg it into Run for example.
UAC settings are located in Local policies – Security Options.
Provided that your version of Windows offers access to it.
You can also use Group Policy which is definitely accessible in all versions of Windows from at least Windows 2000 on. Just type mmc into SEARCH or RUN box.
Group Policy is only available in select editions of Windows, not in all.
All Windows VERSIONS from Windows 2000 include gpedit. I have never used the deprecated EDITIONS of any, such as Home Editions. Is that to what you are referring?
Yes that is right.
UAC is useless. All it does is cause issues. If someone is a local admin, chances are, they’ll click okay or continue anyway. It still comes down to the user. You can’t and shouldn’t think UAC is going to protect you. I’ve seen UAC cause a lot of unwanted behavior. For example, if you’re a local admin, if UAC is on, it ignores nesting. A directory with just SYSTEM and full control on “Administrators” should allow you to browse, but with UAC on, it doesn’t. You have to click continue to “permanently add” your account to the ACL of the directory. You end up with directories with modified default ACLs. If you’re in the local admin group, and that group is on a directory, it should let you browse. I consider this invalid behavior and as such I’ve disabled UAC on my templates.
Cody, what you describe is a deficiency (in my opinion) with the Microsoft Explorer process when it is run against local drives. With UAC, Explorer is stripped of its “admin” token. So Explorer doesn’t know you are an admin when browsing folders/files. Drop to CMD or powershell prompt and you can still see/browse everything. It is a “poor” design to not let an Admin browse folders/files. If you opt to “add”, then it mucks up the ACL as you described. Connect to that same machine remotely, and you can browser all the folders/files because the “admin” token is stripped remotely. How stupid is that?!?
Or give the ability to start Explorer “as administrator”…
It is now 2020. Do these rules still apply to UACs in Windows 10