Run As Admin (also known as Application Elevation) elevates privileges for only the file or application selected.

It is invoked when a user runs a file that triggers User Account Control (UAC). The user is able to run the program sandboxed, without being local administrator. Only the process (not the user) has administrator rights. When enabled, the Explorer right-click icon is replaced by an Admin By Request icon.

Admin Session (also known as User Elevation) elevates the current user's privileges across the endpoint for the duration of the session.

Invoked when the user clicks the tray or desktop icon to request a protected administrator session, which makes the user a temporary member of the local administrator's group for a limited period of time under full audit.

Revoke admin rights at logon means that all user accounts will be downgraded from an Admin role to a User role, unless the account appears in the Excluded accounts list.

Excluded accounts are not removed at logon.

Tray Tools are items that appear when users click the Admin By Request system tray icon. As well as executable files, these tools could be web links with instructions, Control Panel applets or program shortcuts.

Minimum requirements

Tray Tools require Admin By Request version 7.1 or newer. Control Panel tools require Windows 10 version 2004 (build 19041) or newer.

New Tray Tool

Click button New Tray Tool to create a new entry in the tray tools menu.

Quick add list

The Quick add list is a preset list of common Control Panel applets. It is a selection list, accessed by clicking the drop-down arrow at the right of the field. You can add other Control Panel applets by creating a tool that runs control.exe followed by a .cpl file.

Pre-approved applications are EXE, MSI, MSC or CPL files that are pre-approved to run with elevated privileges (i.e. Run as administrator), when approval would normally be required. The intention is to remove trivial approval flows and avoid flooding the audit log with trivial data for applications known to be good, such as Visual Studio or Adobe Reader installs.

When an application is on the pre-aproval list, the difference is:

• The application is auto-approved, so the approval flow is bypassed

• A reason is not required, as the application is known to be good

• You have the option to not log to the Auditlog (e.g. for trivial data)

• If Run As Admin is disabled, a pre-approved application will still run

• A pre-approved application will overrule Deny elevating system files

• You can force applications to always run elevated (legacy applications)

New entry

Click button New entry to create a new pre-approved application.

Quick add list

The Quick add list is a preset list of common applications. It is a selection list, accessed by clicking the drop-down arrow at the right of the field.

Enabled toggle

A global setting that indicates whether pre-approved applications are allowed at all (On) or not (Off).

The PRIVACY tab provides a way to anonymize data collection, so that data is still logged and available for analysis, but identification of individual users is not possible.

Key points:

• Obfuscation creates an alias for each user. You can track activity, but you cannot decode the true identity of any user.

• Collection of data should be left on unless you have a reason not to do this. If disabled, you will have to find contact information elsewhere.

• Inventory is a hardware and software inventory. If disabled, only the computer name is collected and shown in the "Inventory" menu.

• Geo-tracking maps the endpoint IP address to location using a public IP-to-location database to show in inventory and reports.

The Entra ID Connector allows endpoints to retrieve Entra ID (previously Azure AD) groups for sub-settings.

The Entra ID Connector is NOT used for single sign-on to the portal; it is solely used for sub-setting groups. Example values:

Refer to https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app for more information on registering apps with the Microsoft identity platform.

The first method requires that a user be allowed to grant consent to apps in Azure AD, as indicated in the screenshot below.

The second method is more complex and is needed when users are not permitted to grant consent to apps in Azure AD, as indicated in the screenshot below:

1. Modify Admin consent settings:

   Admin consent settings must be modified so that users can request admin consent to apps they are normally unable to consent to:

   

   Determine which Users, Groups and/or Roles will be permitted to approve consent requests. To ensure approval requests are handled efficiently, those able to review requests for approval for a given application should be specified at this point.

2. Elevate a program as a normal user:

   The first user to initiate SSO validation from an endpoint is presented with an Approval required dialog:

   

   To ensure first use is controlled, login as an ordinary user and create a consent request for the application by elevating a program. Enter the reason why you want this and click Request approval.

3. Approve the request as an authorized approver:

   Once the first approval request is made, go to your AAD tenant > Enterprise Applications | Admin consent requests > All (Preview) as one of the Users/Groups/Roles specified earlier. The following shows one request in the list:

   

   For the request shown, click Admin By Request SSO to open it.

   Finally, click Accept to approve it:

   

   Once accepted, all users can run the application.

The software works exactly the same for computers without a domain or for computers joined to Azure AD. For Azure AD, you can set up a connector in the portal settings. You do not need to do this for Azure AD, unless you need to use sub-settings, in which case you can set up the connector to create sub-settings based on Azure AD groups.

The portal has two levels of settings:

1. Windows Settings (also known as Global Settings) apply to all users by default, except those settings overridden under Sub Settings.

2. Windows Sub Settings, where you can define special settings based on Active Directory computer or user groups and/or Organizational Unit(s).

Settings here are the global settings for all endpoints. You can overrule settings for certain domain users or computers under the sub-settings menu.

Sub settings will overrule the global settings for the users or computers to which they apply. Both users and computers can be in Active Directory groups or organizational units.

If a user or computer hits multiple sub settings, the first in listed order that includes the setting concerned wins.

The software works exactly the same for computers without a domain or for computers joined to Azure AD. For Azure AD, you can set up a connector in the portal settings. You do not need to do this for Azure AD, unless you need to use sub-settings, in which case you can set up the connector to create sub-settings based on Azure AD groups.

You can specify programs and applications that you wish to prevent users from executing with administrator privileges. You can block applications based on one or more of the conditions: file name, checksum, vendor or file location.

PIN code exceptions: The option is available to use a PIN code in case you allow the execution as an exception - simply retrieve the PIN code from the computer's inventory. If you do not wish to offer a PIN option, you can disable this under the Run As Admin tab.

Application name is a label only - used for convenience in the overview list.

File name allows you to point to a file name that will be blocked from executing. You can specify wildcards in the file name, such as *.sh.

Blocking message will appear as a denial message to the user when execution of the application is attempted.

You can also block users from elevating any Windows system file, which prevents users from running cmd.exe, regedit.exe, mmc.exe, etc as administrator.

User Account Control (UAC) is still enforced (if enabled) to maintain the extra layer of security. If the user needs to run an application during an Admin Session, the user still has to envoke “Run as administrator” directly or indirectly and enter own credentials. This is intentional to avoid reducing the security level. Admin By Request does not replace or tap into UAC for the reasons stated in the previous section.

Admin By Request does not replace User Account Control, like some other solutions do. This is a design choice. Replacing Windows system files or components is dangerous and can lead to future problems because of Windows Updates, which could ultimately break your OS installs to the extent that computers can no longer boot. This is especially true with Windows 10 feature updates that often change basic functioning of the operating system. A significant advantage to the Admin By Request endpoint software is that it does not change or replace any system files or components and only uses what is already built into Windows. Because of this, it also does not consume any resources at all, unless the user invokes the software.

Windows Subsystem for Linux (WSL) can be used with ABR installed on the endpoint and ABR handles this as it does other applications.