Basics of privilege escalation in Windows. Elevation of rights without asking for an admin password, for a specific application All administrators work in administrator approval mode

UAC(User Account Control) is an account control technology that first appeared in Windows Vista and older. This technology prevents programs from performing actions that require administrator rights. When the program performs such actions, its work is suspended and the user is presented with a request window on the protected desktop (so that it is impossible to programmatically press the OK button). For example, if your program needs to make changes to the registry key HKEY_LOCAL_MACHINE, then she will need administrator rights.
To solve this problem, you can use the implementation of a manifest file in the project, which the operating system will read and automatically determine the parameters necessary for launch.
Let's consider introducing a manifest file into the application " Windows Form" To do this, open Visual Studio (version 2012 is used in this example) and create a project " Windows Form" Open " Solution Explorer(Solution Explorer), which provides an organized view of projects and their files, go to the menu View» - « Solution Explorer" Right-click on " Solution Explorer" by project name and select from the context menu, " Add» - « Create element...».

• asInvoker- the application starts with the rights of the parent process. This means that if you run a program from an application that is already running with administrator rights, it will automatically have the same rights. This mode is recommended by Microsoft in most cases. Those. These are those programs that do not require administrator rights;
• highestAvailable— the application is launched with higher rights than the current user has. Regedit.exe, Mmc.exe are launched with these rights;
• requireAdministrator- full administrator rights are requested. Those. required for applications that cannot run without administrator rights.

Installing applications " ClickOnce" is only possible with the value "asInvoker". Any other value will not allow installation.

Part of the article described in detail the principle of operation of User Account Control. In this part we will talk about setting up UAC in the case when your computer operates standalone, that is, it is not part of an Active Directory domain. To configure User Account Control, use the Local Security Policy feature, which can be found in the Local Group Policy Object Editor.

There are 10 Group Policy settings that are responsible for configuring User Account Control. In order to change policy settings, you need to open the snap-in "Local Group Policy Editor" node Computer Configuration\Windows Configuration\Security Settings\Local Policies\Security Settings. This article will also show you how to configure each policy setting using the system registry. The following table shows the default values ​​for each policy setting.

Default User Account Control group policy settings:

Group Policy settings that relate to User Account Control (UAC) are discussed in detail below:

All administrators work in administrator approval mode

This policy setting determines the characteristics of all User Account Control policies for the computer. This setting determines whether administrator accounts will run in “administrator approved mode,” that is, whether dialogs will be displayed asking for elevation of privileges. Disabling this setting, roughly speaking, completely disables the User Account Control functionality. If you change this policy setting, you must restart the computer. The default value is enabled.

Possible parameter values:

• Included. Administrator approval mode is enabled to allow the built-in administrator account and all other users who are members of the group "Administrators", work in administrator approval mode.
• Disabled. Administrator approval mode and all associated User Account Control policy settings will be disabled.

;Disable "EnableLUA"=dword:00000000

Detect application installation and prompt for elevation

This setting defines the application installation detection characteristics for a computer by checking whether the programs used to deploy applications are signed or not. By default, if a user is a member of a workgroup, it is enabled.

Possible parameter values:

• Enabled (default for home). If the application installer detects the need for elevated privileges, the user is prompted to enter the user name and password for the administrator account. If the user enters correct credentials, the operation continues with appropriate rights. The type of request depends on which group the user belongs to.
• Disabled (organization default). When you select this setting, application installer detection does not prompt you for elevation. Typically, this setting is used in organizations whose computers and users are part of a domain and use delegated installation technologies (Group Policy Software Install - GPSI) to deploy applications. Accordingly, there is no need to detect the installer.

Current policy settings using the registry:

;Disable "EnableInstallerDetection"=dword:00000000

Switch to the secure desktop when prompted for elevation

This policy setting determines whether elevation prompts are displayed on the user's interactive desktop or on the secure desktop when a UAC prompt is initiated. The default value is enabled. If you change this policy setting, you must restart the computer.

Possible parameter values:

• Included. All elevation requests are displayed on the secure desktop, regardless of the prompt behavior policy settings for administrators and standard users.
• Disabled. All requests for elevation of rights are displayed on the user's interactive desktop.

Current policy settings using the registry:

;Disable "PromptOnSecureDesktop"=dword:00000000

Behavior of elevation prompt for administrators in admin approval mode

The current setting allows you to determine the actions of a user who is a member of the group "Administrators" when performing an operation that requires elevation of rights. The default value is set "Request Consent for Third Party Binaries (Non-Windows)".

Possible parameter values:

• Promotion without request. Allows privileged accounts to perform an operation that requires elevation without requiring consent or entering credentials. It is advisable to use this option only in environments with maximum user restrictions. When you select this setting, the user's permissions will be identical to the built-in administrator account.
• . For any operation that requires elevation, the secure desktop will prompt you to enter the root user name and password. If correct credentials are entered, the operation will continue with the maximum available user rights.
• Request Consent on Secure Desktop. For any operation that requires elevation, the secure desktop will prompt you to select: "Allow" or "Prohibit". When selecting the option "Allow", the operation will continue with the maximum available user rights.
• Request for credentials. For any operation that requires elevation, you will be prompted to enter the user name and password for the administrator account. If you enter the correct credentials, the operation will continue with elevated privileges.
• Request for consent. When selecting this option, for any operation that requires elevation of rights, the user will be prompted to select a button: "Allow" or "Prohibit". When you press the button "Allow"
• Request Consent for Third Party Binaries (Non-Windows). When you select this option, a selection prompt will be displayed on the secure desktop: "Allow" or "Prohibit", in the case where the operation for a third-party (non-Microsoft) application requires elevation of rights. At the click of a button "Allow", the operation will continue with the user's maximum available privileges.

Current policy settings using the registry:

;Promotion without prompt "ConsentPromptBehaviorAdmin"=dword:00000000 ;Request for credentials on secure desktop;"ConsentPromptBehaviorAdmin"=dword:00000001 ;Prompt for consent on secure desktop;"ConsentPromptBehaviorAdmin"=dword:00000002 ;Prompt for credentials;"Consent PromptBehaviorAdmin" =dword:00000003 ;Consent request;"ConsentPromptBehaviorAdmin"=dword:00000004 ;Consent request for non-Windows binary data ;"ConsentPromptBehaviorAdmin"=dword:00000005

Elevation prompt behavior for standard users

This policy setting determines the actions taken when a standard user interacts with applications that require elevated privileges. Default value - "Prompt for credentials on secure desktop".

Possible parameter values:

• Request for credentials. Using this option, the standard user is prompted to select an administrator account and enter a password to perform subsequent actions. The operation will only continue if the credentials are entered correctly.
• Automatically deny elevation requests. If you select this option, a standard user will be shown an access denied error message when performing an operation that requires elevated privileges. Organizations whose desktop computers are used by regular users can select this policy setting to reduce the number of support calls.
• Prompt for credentials on secure desktop. By selecting this option, the standard user is prompted to select an administrator account and enter a password to perform subsequent actions only on the secure desktop. The operation will only continue if the credentials are entered correctly.

Current policy settings using the registry:

;Automatically reject elevation requests "ConsentPromptBehaviorUser"=dword:00000000 ;Prompt for credentials on secure desktop "ConsentPromptBehaviorUser"=dword:00000001 ; Prompt for credentials "ConsentPromptBehaviorUser"=dword:00000003

Elevate rights for UIAccess applications only when installed in secure locations

The current policy setting allows you to control the location permission of applications that request execution at the integrity level defined by the User Interface of Access (UIAccess) attribute in a secure file system location. By default, this setting is enabled and for accessible apps, the UIAccess attribute in the manifest is set to True to control the privilege escalation request window. If applications are set to false, that is, if the attribute is omitted or there is no manifest for the assembly, the application will not be able to access the protected user interface. Only the following folders are considered safe:

…\Program Files\, including subfolders

…\Windows\system32\

...\Program Files (x86)\, including subfolders for 64-bit versions of Windows

Possible parameter values:

• Included. The application will only run with the UIAccess integrity level if it is located in a secure folder on the file system.
• Disabled. The application will run with the UIAccess integrity level even if it is not in a secure file system folder.

Current policy settings using the registry:

;Disable "EnableSecureUIAPaths"=dword:00000000

Elevation of privileges only for signed and verified executables

This User Account Control Group Policy setting allows you to determine whether to authenticate signatures of interactive Public Key Infrastructure (PKI) applications that require elevation of privileges. The purpose of PKI is to determine the policy for issuing digital certificates, issuing and revoking them, and storing information necessary for subsequent verification of the correctness of certificates. Applications that support PKI include: secure email, payment protocols, electronic checks, electronic information interchange, data security over IP networks, electronic forms, and electronically signed documents. If this check is enabled, programs initiate verification of the certificate path. The default value of this setting is Disabled.

Possible parameter values:

• Included. A path check for PKI certificates is forced before the file is executed. This setting is mainly used in organizations with a domain, if the administrator has placed PKI certificates in the trusted publishers store.
• Disabled. When this option is set, User Account Control does not initiate a PKI certificate verification chain check before allowing execution of a given executable file.

Current policy settings using the registry:

;Disable "ValidateAdminCodeSignatures"=dword:00000000

If writing to a file or registry fails, virtualize to the user's location

This setting controls whether application write failures are redirected to specific locations in the registry and file system. When this setting is enabled, for legacy applications that attempt to read or write information using protected areas of the system, User Account Control virtualizes the registry and file system. Thanks to this setting, UAC allows you to reduce the danger of legacy applications that run as an administrator and write data to the %ProgramFiles%, %Windir% folder during execution; %Windir%\system32 or to the system registry key HKLM\Software\. The default value is enabled.

Possible parameter values:

• Included. Application write failures are redirected at runtime to user-defined locations in the file system and registry.
• Disabled. Applications that write data to secure locations will fail and will not execute.

Current policy settings using the registry:

;Disable "EnableVirtualization"=dword:00000000

Allow UIAccess applications to request elevation without using the secure desktop

This new policy setting, introduced in Windows 7 and Windows Server 2008 R2, controls whether UIAccess applications can automatically disable the secure desktop for elevation requests used by a standard user. The default value is disabled.

Possible parameter values:

• Included. When you select this setting, UIAccess programs, including Windows Remote Assistance, automatically disable Secure Desktop for elevation requests. If the "User Account Control: Switch to secure desktop when prompted for elevation" policy setting is enabled, the prompt appears on the user's interactive desktop rather than on the secure desktop.
• Disabled. When this option is selected, the secure desktop can only be disabled by the user of the interactive desktop or by disabling the "User Account Control: Switch to secure desktop when prompted for elevation" policy setting.

Current policy settings using the registry:

;Disable "EnableUIADesktopToggle"=dword:00000000

Administrator approval mode for the built-in administrator account

This setting determines whether User Account Control applies administrator approval mode to the built-in account "Administrator". This default built-in account allows the user to log on in Windows XP compatibility mode, allowing them to run any application with full administrator rights. By default, this policy setting is disabled.

Possible parameter values:

• Included. When you select this option, the built-in administrator account will use administrator approval mode. In this case, any operation that requires elevation of rights will be accompanied by a request to confirm the operation.
• Disabled. The built-in administrator account runs all applications with full administrator rights.

Current policy settings using the registry:

;Disable "FilterAdministratorToken"=dword:00000000

Conclusion

This article explains all the possible User Account Control settings. All ten security policy settings are considered, which are responsible for all possible actions related to UAC. In addition to setting up User Account Control using Group Policy, the equivalent registry tweaks are also discussed.

Many programs require elevation of rights at startup (a shield icon next to the icon), but in fact they do not require administrator rights for their normal operation (for example, you manually granted the necessary rights to users for the program directory in ProgramFiles and the registry branches that are used by the program). Accordingly, when running such a program as a simple user, if User Account Control is enabled on the computer, a UAC prompt will appear and the user will be required to enter the administrator password. To bypass this mechanism, many simply disable UAC or grant the user administrator rights on the computer by adding him to the local administrators group. Naturally, both of these methods are unsafe.

Why a regular application might need administrator rights

The program may need administrator rights to modify certain files (logs, configurations, etc.) in its own folder in C:\Program Files (x86)\SomeApp). By default, users do not have rights to edit this directory; therefore, for normal operation of such a program, administrator rights are required. To solve this problem, you need to manually assign change/write rights to the user (or Users group) to the program folder as an administrator at the NTFS level.

Note. In fact, the practice of storing changing application data in its own directory under C:\Program Files is incorrect. It is more correct to store application data in the user profile. But this is a question of laziness and incompetence of developers.

Running a program that requires administrator rights from a standard user

We have previously described how you can use the RunAsInvoker parameter. However, this method is not flexible enough. You can also use it with saving the admin password /SAVECRED (also unsafe). Let's consider a simpler way to force any program to launch without administrator rights (and without entering the admin password) with UAC enabled (4.3 or level 2).

For example, let's take the registry editing utility - regedit.exe(it is located in the C:\windows\system32 directory). When you run regedit.exe, a UAC window appears and, unless you confirm the privilege elevation, the Registry Editor does not start.

Let's create a file on the desktop run-as-non-admin.bat with the following text:

cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" %1"

Now to force the application to run without administrator rights and suppress the UAC prompt, simply drag the desired exe file onto this bat file on the desktop.

After this, the Registry Editor should start without the UAC prompt appearing. Open the process manager and add a column Elevated(With a higher permission level), you will see that the system has a regedit.exe process with a non-elevated status (running with user rights).

Try editing any parameter in the HKLM branch. As you can see, access to edit the registry in this branch is denied (this user does not have rights to write to the system registry branches). But you can add and edit keys in the user's own registry branch - HKCU.

In the same way, you can launch a specific application through a bat file, just specify the path to the executable file.

run-app-as-non-admin.bat

Set ApplicationPath="C:\Program Files\MyApp\testapp.exe"
cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" %ApplicationPath%"

You can also add a context menu, which adds the ability for all applications to launch without elevation. To do this, create the following reg file and import it into the registry.

Windows Registry Editor Version 5.00

@="cmd /min /C \"set __COMPAT_LAYER=RUNASINVOKER && start \"\" \"%1\"\""

After this, to launch any application without administrator rights, just select the “” item in the context menu.

__COMPAT_LAYER environment variable and RunAsInvoker parameter

The __COMPAT_LAYER environment variable allows you to set different compatibility levels for applications (tab Compatibility in the properties of the exe file). Using this variable, you can specify the compatibility settings with which the program should run. For example, to run the application in Windows 7 compatibility mode and 640x480 resolution, set:

set __COMPAT_LAYER=Win7RTM 640x480

Among the options of the __COMPAT_LAYER variable that are interesting to us, we highlight the following parameters:

• RunAsInvoker- launching an application with the privileges of the parent process without a UAC request.
• RunAsHighest- launching the application with maximum rights available to the user (the UAC request appears if the user has administrator rights).
• RunAsAdmin- launch the application with administrator rights (the AUC prompt always appears).

Those. The RunAsInvoker parameter does not provide administrator rights, but only blocks the appearance of the UAC window.

Hmm, the difference between one and the other is only in how the compatibility parameters are set, in the first case - manually, in the second - the same thing, only through the wizard. But thanks anyway for the detailed answer))

Thanks, I know))))))))))))))))))

Ok, I'm an admin (maybe a little illiterate, but I hope to catch up...) How can I be allowed to run this application (and only this)? At the same time, so as not to constantly run to his machine (to enter the local admin password, which he should not know) when he needs to launch this application.

I am very grateful to you for reminding me of part of the lecture on the subject “Operating Systems”. Let me give you another, now classic, example:

Sometimes a user needs to change their login password. The user himself does not have rights to access the password database. However, the program he uses to change the password runs with elevated rights. Which allows him to eventually change his password.

So, my case is similar. How do I "tell" the system that a program should run with elevated rights? In this case, it will be launched by a user from the “user”/“power user” group.

This can actually be done by running the program as a "scheduled task" as a different user. Everything would be fine - it even starts, but the graphical interface (program windows) is not displayed on the user's desktop...

Conceptual contradiction??? I gave an example above - the task is quite standard for any OS. I just don’t want to solve it with third-party tools (not included in Windows Vista). I've already disabled UAC - in any case, the application works correctly only with admin rights, that's how it is - specific.... It doesn't seem possible to include this user in the local "Administrators" group for security reasons.

Regarding the script - for runas there is a flag that allows you to remember the password, but in this case the user will be able to run any program with admin rights.

This means that I don’t want to launch software whose source code no one has seen, nothing is known about the supplier, and whose website is “in the hands of the people.” What about users - eh, if that was enough, then this discussion would not have appeared on the forum..... =(

I would like to believe that not everything is so bad.