Privilege Elevation and Delegation Management (PEDM) (Windows)

In this article, you will learn everything you need to know about the Privilege Elevation and Delegation Management module. Privilege Elevation and Delegation Management allows you to easily elevate user rights or file executions, it gives you the ability to revoke escalations and supports zero-trust executions. Privilege Elevation and Delegation Management features a lightweight and stunning interface that puts you in complete control over the user’s elevated session. Approve or deny from the HEIMDAL Dashboard or on the go, right from your mobile device. You can keep track of sessions, block elevation for system files, live-cancel user admin rights, and set escalation periods.

1. Description
2. How does Privilege Elevation and Delegation Management work?
3. HEIMDAL Agent - Privilege Elevation and Delegation Management
4. Privilege Elevation and Delegation Management view
5. Privilege Elevation and Delegation Management settings

DESCRIPTION

Privilege Elevation and Delegation Management is a PEDM tool that can be used to give users the ability to install software they need for a period of time you select using the Administrator Session or the Run with Admin Privileges option for single file elevation. Rights granted can be revoked at any time and actions are logged for a full audit trail. This is the feature that allows an end-user to request admin privileges over his/her machine by sending a request to the HEIMDAL Dashboard Administrator who can deny or accept his/her request. The length of the session is limited and all his/her actions are logged into the HEIMDAL Dashboard. 

HOW DOES PRIVILEGE ELEVATION AND DELEGATION  ACCESS MANAGEMENT WORK?

On Windows, Privilege Elevation and Delegation Management is a product under the HEIMDAL Agent that manages the user permissions on a computer (domain-joined or non-domain-joined) and is controlled by the Heimdal Admin Privilege service (Heimdal.AdminPrivilege.exe process). Privilege Elevation and Delegation Management runs under the local SYSTEM user and can be used in 2 ways: Run with PAM (single-file elevation) or Administrator Session (Administrator rights). 

A. Run with Admin Privileges

The Run with Admin Privileges feature allows the user to right-click an executable file (.exe, .msi, .msc, .cmd, and .cpl) and run it with Administrator permissions (the file is run by the NT Authority\System by default, but it can be run by the logged-in user when User token elevation is enabled in the Group Policy settings). Running files from a Network Drive (Shared Folder) works with the Run with Admin Privileges functionality only when User token elevation is enabled.

If the Require reason option is enabled in the Group Policy, then the pop-up below will appear to add details for the elevation request (more than 2 characters should be added to be able to submit the elevation request reason). This step is skipped if Require reason is disabled. The option Other is the only option that requires at least 30 characters to be able to submit the elevation request reason.

After clicking Elevate, depending on the Group Policy configuration, a request can be sent to the server, to ask permission from the HEIMDAL Dashboard Administrator (if Approval via Dashboard is selected in the GP) and the left popup below will appear or the elevation will be automatically granted (if Auto-mode is selected in the GP) and the right popup below will appear:

After clicking Start Now, the below popup will appear to inform the user that the file has been elevated.

IMPORTANT
An elevation is granted in a 5-minute interval after being approved by the HEIMDAL Dashboard Administrator.

B. Administrator Session

The Administrator Session feature allows the user who is requesting elevation to get elevated for a specific number of minutes to run applications/processes with Administrator rights. When an Administrator Session elevation is started, the requesting user is temporarily promoted as a member of the local Administrators group (this feature supports computers managed through Azure Active Directory, Active Directory, or hybrid setups). This will ensure that the user can use his/her own credentials (username and password) to run processes/applications. To run a process/application with Administrator rights, you need to right-click the executable file and click Run as Administrator (just like you would if your user were already an Administrator), and when you get prompted by the UAC, you need to type in your user credentials (because your user has been temporarily elevated to Administrator level). 
Elevations can be requested from the HEIMDAL Agent by pressing the Elevate button, or by going into the System Tray and by right-clicking the Heimdal icon and selecting Request admin rights.

If the Require reason option is enabled in the Group Policy, then the pop-up below will appear to add details for the elevation request (more than 30 characters should be added to be able to submit the elevation request reason). This step is skipped if Require reason is disabled.

After clicking Elevate, depending on the Group Policy configuration, a request can be sent to the server, to ask permission from the HEIMDAL Dashboard Administrator (if Approval via Dashboard is selected in the GP) and the left popup below will appear or the elevation will be automatically granted (if Auto-mode is selected in the GP) and the right popup below will appear:

After the elevation has been revoked or the remaining time reached 0, the below popup will appear to inform the user that the local admin privileges have been removed.

IMPORTANT
An elevation is granted in a 5-minute interval after being approved by the HEIMDAL Dashboard Administrator or in less than a minute if Realtime communication is enabled on the Group Policy that is applying to the endpoint.

• BAT or CMD files cannot be executed during elevation;
• On multi-user sessions that usually occur on Windows Servers acting as RDP/Terminal Servers, we require the Do not show GUI option to be ticked, in order to stop the HEIMDAL Agent from wasting CPU and Memory. In this type of case, an elevation can be requested using the Heimdal Session Elevator for Servers (by pressing the Start button), which will differentiate between the requesting users. 
   
• While the option Do not show GUI is in effect, the function Run with Admin Privileges, will not work, and the Reason window will not show up. To use Run with Admin Privileges, you must first use Heimdal Session Elevator for Servers, which will trigger the GUI, and start an elevated session. If you use Run with Admin Privileges during elevation, the file will be elevated as part of the session (a new File elevation will NOT be created, and the elevated process will appear as part of the existing elevation).
• For cases where you connect to a device through RDP or Hyper V enhanced mode, you must have the option User Token Elevation enabled in the group policy so that the Run with Admin Privileges mechanism can work properly on the device.

HEIMDAL AGENT - PRIVILEGE ELEVATION AND DELEGATION MANAGEMENT

On the HEIMDAL Agent's home page view, you can see the current status of the Agent and the modules that are enabled for your computer. To access the Privilege Elevation and Delegation Management module, you can click on the Privileges & App Control icon or use the left-side menu. 

The Privilege Elevation and Delegation Management module displays information about the Total Elevations. The data that is logged in this view includes Username, Reason, Request date, Action and Duration.

Pressing the Elevate button will elevate the user or will display a Reason for elevation popup to be sent to the HEIMDAL Dashboard:

The Sign In button becomes available when the HEIMDAL Dashboard administrator enables the Azure Login functionality from the Group Policy settings. Azure Login will allow pre-selected users (based on the mentioned Azure AD Group) to log in using their Azure AD account and elevate as Administrator (on their account) instead of the logged-in user. The information displayed in the Privilege Elevation and Delegation Management section is reported to the HEIMDAL Dashboard -> Privileges & App Control -> Privilege Elevation and Delegation Management. The HEIMDAL Agent's context menu allows you to request an Administrator Session elevation or to run a series of Windows applications that can be handy for users or IT Administrators. The Tools menu will be greyed out in the following scenarios (Allow run as Administrator is disabled and Do not allow Run with AP when session is elevated is enabled, the user is not elevated and Allow run as administrator is disabled, the user is elevated or is found in the local Administrators group, Deny elevation of system files is enabled):

PRIVILEGE ELEVATION AND DELEGATION MANAGEMENT view

The Privileges & App Control - Privilege Elevation and Delegation Management view displays all the information collected by the HEIMDAL Agent that is running on the endpoints in your organization. The collected information refers to the elevation requests, the processes that are running during the elevations, and the Zero-Trust processes that are executed in your environment. On the top, you see a statistic regarding the number of Pending Requests, and the number of used Admin Rights.

The collected information is placed in the following views: Pending Approvals, History, Most Escalated Process, Most Escalating Hostname, Compliance, and Zero-Trust Execution Protection.

• Pending Approvals
  This view displays a table with the pending elevation requests and the following details: Hostname, Username, Reason given, Request Time, Type, Application, and Status. If the Status is Requested and written in red, this means the endpoint is running a 3rd Party Application that has a vulnerability with a CVSS score of 7 or higher. 
  
  Clicking on the process listed under the Application column, you will get additional information regarding the elevated process: Full Path, Publisher, Version, and MD5.
  
  When you select an elevation request, you have the option to send a message to the user by enabling the Administrator message tickbox and by filling in your message. 
• History
  This view displays a table with the elevated/de-elevated requests and the following details: Hostname, Username, Start Time, End Time, Reason Given, Action, Executed Process(es), Handled By;
  
  Process Details will provide all the additional information related to a process that has been executed via PEDM. You can access this view just by pressing on one of the processes listed in the Executed Process column.
  
  
• Most Executed Processes
  This view displays a table with the number of executed processes (during the elevated session) and the following details: Process Name, Number of Executions, Hostname, and Username. 
  
  
• Most Escalating Hostname
  This view displays a table with the number of escalating hostnames and the following details: Hostname, Username, and Total Number of Elevations.
  
  
• Compliance
  This view displays a table with the compliant endpoints and the following details: Hostname, Active User, Domain Name, Local Groups, AD Groups, and Admin rights (Y/N). The Local Group field populates if the active user is found in any of the local groups or AD Groups. If it is found, it is marked as Admin (Yes). 
  
  
• Zero - Trust Execution Protection
  
  This view displays a table with the processes (non-signed executable files) intercepted by the Zero-Trust Execution Protection engine and the following details: Hostname, Username, Process Name, MD5 Hash, Timestamp, and Status. Clicking the 3-dot button will give you the option to search the file hash on VirusTotal or to Copy the file path to the Clipboard. The status of detection can be: Unknown (intercepted by ZTEP and not found in our database; files that are whitelisted globally by the Heimdal Support Team propagate to the endpoints after 3 days since the whitelist), Allowed (intercepted by ZTEP, but whitelisted in our database). The data in this view gets updated in real time.
  
  Selecting a file from the list allows you to add it to the exclusion list or upload it to the storage.
• Primary User
  In the newly created tab, a grid, containing information about endpoints and their primary users, will be displayed.
  
  Each row will display a unique hostname, the primary user set on that machine, and the source from where the primary user was defined – if it was configured from Azure AD or was the first logged-in user, the AAD Primary user (if it was previously configured in Azure AD), the username with the highest number of logins, on that machine, during the last 30 days (“Most logins user”) and an “Action” column, containing a drop-down list, at hostname level, displaying all users that logged in on that machine in the last 30 days will be displayed (selecting a user from this drop-down will update the primary user for that specific hostname).
  Post clicking on the action a confirmation modal window will be displayed, showing the hostname(s) and corresponding user(s) which will be unassigned as primary user(s):
  The Action column drop-down lists allow you to manually choose which users are mapped to each hostname. The drop-downs contain all the users that have been logging in on each machine during the last 30 days:
  When one of the users is selected, a pop-up window will appear, displaying the hostname, the old primary user selection, and the new one, asking you to confirm if you want to update the assignment. Clicking cancel will abort the operation.
  
  The entries from this grid can be sorted ascending/descending by any column except the Action one; also, a search bar will give the possibility to filter the entries by any column (except the number of logins for the most active user and the way that the Primary User was set). The stats from the page header will display at customer level: the number of primary users configured in Azure AD (“AAD primary users”), the number of primary users configured based on the first login on each machine (“First login primary users”), the number of logins for each primary user for each machine (“Most logins primary users”) and the number of hostnames that do not have any primary users configured yet (“Unassigned hostnames”). On the agent side, we will restrict the possibility of requesting any admin privileges (“Run as administrator” or “Administrator session”) only to the user that is configured as the “Primary User”. In case there are any WIP elevations in use on that machine, while a new Primary User info is received, all of them will be terminated immediately and the “Elevate” button from the agent will be grayed out. Also, the “Run with Admin Privileges” option from the context menu, used for file elevations, will be removed.In case the feature is enabled and non-primary users, in a scenario where one of these non-primary users wants to request a file elevation, in case the “Disable Windows Consent” option is enabled in Endpoint settings, the custom consent window will display the following message:
  

If you use Application Control besides Privilege Elevation and Delegation Management and require to allow or block an executed application, you can select the elevated application from the Most Executed Processes view and add it via a rule in the Application Control module. Select the process, and from the drop-down menu select the action you want to take.

The tables in each view have a 60-second refresh rate. The Download CSV functionality allows you to generate and download a CSV report that includes all the information in Standard or Verbose mode corresponding to each view.

PRIVILEGE ELEVATION AND DELEGATION MANAGEMENT settings

The Privilege Elevation and Delegation Management module will allow you to give users the ability to install software they need for a period you select using the Administrator Session or the Run with Admin Privileges option for single file elevation. Rights granted can be revoked at any time and actions are logged for a full audit trail. This is the feature that allows an end-user to request admin privileges over his machine by sending a request to the Heimdal Dashboard System Administrator who can deny or accept his request.

Allow run as administrator - turn ON/OFF the single-file elevation request (Run with AdminPrivilege) feature;
Require reason - when requesting an elevation, the Heimdal Agent will display a pop-up to request a reason for the elevation. You can also choose to enable Require phone number, Require email, and Elevation reason no. of characters (if the feature is disabled and an elevation, falling under the aforementioned scenario, is requested, the default character range will remain between 30 and 1000, as before);
Prevent spawning other processes - any process that is spawned by an application started with the Run with AdminPrivilege will be terminated;
Disable Windows Consent - when enabled, the UAC prompt will be replaced with a PAM prompt, and running an application will require just a double-click. This checkbox is alterable (enable/ disable) only if the User token elevation functionality is enabled;
Machine Learning auto-approval - allows a file elevation request to be automatically approved by the HEIMDAL server if the elevation for the same file/processes has been historically granted by an IT Administrator, an X number of times, which is equal or higher than the set threshold. ML auto-approved files/processes are listed in the History tab of the Privilege Elevation and Delegation Management view;
Elevation approvals threshold - allows you to set the approval threshold for the Machine Learning auto-approval;
Auto-mode - all single-file elevation requests (Run with AdminPrivilege) will be automatically approved and queried in the Heimdal Dashboard (under Products -> Privileges & App Control -> Privilege Elevation and Delegation Management -> History filter);
Approval via Dashboard - all single-file elevation requests and responses will require the approval of the HEIMDAL Dashboard Administrator. The pending elevations will be displayed in the Heimdal Dashboard (under Products -> Privileges & App Control -> Privilege Elevation and Delegation Management -> Pending Approvals filter). Once approved, the requesting user will be able to start the session after receiving a Start elevation pop-up (this is automatically displayed in 1-5 minutes);

Local token elevation - requires the requesting user to enter a local token (no matter if the endpoint is online or offline) provided by the HEIMDAL Dashboard Administrator (a local token can be generated by the HEIMDAL Dashboard Administrator from each client specifics in the Privileges & App Control tab -> Privilege Elevation and Delegation Management);

Approval via Dashboard when online - the elevation request is approved via the HEIMDAL Dashboard only (if the endpoint is online), without requiring a local token. If the endpoint is offline, the elevation request can be approved via the local token provided by the HEIMDAL Dashboard Administrator; 

Administrator Session

Allow administrator session - turn ON/OFF the full administrator elevation request feature. Note that some changes cannot be committed during an Administrator Elevation although the user has Administrator rights;
Require reason - when requesting an elevation, the Heimdal Agent will display a pop-up to request a reason for the elevation. You can also choose to enable Require phone number or Require email:
Automatically close all processes started during an elevation when the session ends - all processes that were started during an Administrator session will be terminated once the elevation session ends;
Allow user to end elevation - allows the elevated user to stop/revoke the Administrator session;
Auto-mode - all Administrator Session elevation requests (Run with AdminPrivilege) will be automatically approved and queried in the Heimdal Dashboard (under Products -> Privileges & App Control -> Privilege Elevation and Delegation Management -> History filter);
Approval via Dashboard - all Administrator Session elevation requests and responses will require the approval of the HEIMDAL Dashboard Administrator. The pending elevations will be displayed in the Heimdal Dashboard (under Products -> Privileges & App Control -> Privilege Elevation and Delegation Management -> Pending Approvals filter). Once approved, the requesting user will be able to start the session after receiving a Start elevation pop-up (this is automatically displayed in 1-5 minutes);

Local token elevation - requires the requesting user to enter a local token (no matter if the endpoint is online or offline) provided by the HEIMDAL Dashboard Administrator (a local token can be generated by the HEIMDAL Dashboard Administrator from each client specifics in the Privileges & App Control tab -> Privilege Elevation and Delegation Management);

Approval via Dashboard when online - the elevation request is approved via the HEIMDAL Dashboard only (if the endpoint is online), without requiring a local token. If the endpoint is offline, the elevation request can be approved via the local token provided by the HEIMDAL Dashboard Administrator;
Allow user to end elevation - allows the user to revoke/stop the elevation;
Azure login - allows the member of an Azure AD group (the group can be specified in the Azure Group Name field that is displayed after enabling the option) to log in with the Azure AD credentials to be able to request elevation on an endpoint. This feature is meant for Administrators who remote on the endpoints of standard users to get elevated with their credentials. In Azure, you will need to allow the Heimdal Security PAM Sign-in action so that the function will allow you to sign. This functionality is supported in hybrid environments. Azure AD-only or on-prem-only environments are NOT supported;
Do not allow Run with AP when session elevated - prevents the user from running with Admin Privileges while the system is already running an Administrator session. This means that the Run with Admin Privileges option (in the context menu) will not be available;
Keep user elevated on screen lock - allows end users to remain elevated even if their machine’s screen is locked. The following actions will still de-elevate the current user: Shutdown (turning off the computer will terminate all user sessions, including that of the current user), Restart (rebooting the system will also close all active sessions, causing the current user to lose their elevated privileges or session state), Sign out (this action will end the user's session, de-elevating their privileges), Other user connected with RDP to the machine - if another user connects to the machine via Remote Desktop Protocol (RDP), it can force the current user to be logged out, which also results in de-elevation, another user signing into a different account on the same machine - if this occurs while the main account is in an elevated session, the main account will lose its elevated status;
SESSION LENGTH (2 MIN -24 H) - allows you to set the interval for the elevation session;

Group Settings

Allow only a specific user to request elevation rights - allows only a specific user to initiate elevation requests from a specific workstation. Their name has to be the same or is included in the hostname of the workstation from which the elevation is requested and the username must be separated from the rest of the workstation name by the '-' character.(e.g. MyLaptop-Username1 or Username1-MyLaptop);
Map users to group - allows you to specify a single local group name to allow the users that are members of the local group to request elevations (this field is case sensitive). The group must be present locally in the Local Users and Groups and only the members of that group will be allowed to request elevation; 

Additional Settings

Accepted requests availability time - allows you to specify the time interval until an approved elevation can be started If the approved elevation session is not started in the specified timeframe, it will be automatically revoked after 24 hours. When this feature is turned OFF, the approved elevation session is revoked after 24 hours if it is not started by the user that requested it;
Time to live (1-24 hours) - allows you to set the time interval for the above-mentioned option;
Zero - Trust Execution Process - enables the protection against zero-hour threats compromising your environment (it can be enabled/disabled from the Endpoint Detection -> Next-Gen Antivirus module and from the Privileges & App Control -> Privilege Elevation and Delegation Management module as well). Zero-Trust Execution Protection checks the unsigned executable files and blocks their execution if deemed untrusted;
Reporting mode - allows the scan and logging of the applications with Zero - Trust Execution Protection, without taking any action: allow, block.
Exclusions - the exclusion area allows you to exclude a process from the Zero-Trust Execution Protection by File Name, File Path, Directory, or MD5;

Revoke existing local admin rights - allows you to downgrade the Administrator users (both Local and Domain users) to Standard users. The HEIMDAL Agent takes a snapshot of the local Administrators' Group on each endpoint and removes all the members, users, and Groups, (except the default Administrator user) from that group, thus, downgrading them to Standard permissions. Once enabled, the users that are logged in will preserve the Administrator permissions until the first logoff/reboot. On domain-joined computers, the downgrading of the members of the local Administrators' Group will be performed only if the endpoint is communicating with the domain (domain controller). If the computer is not able to communicate with the domain (domain-controller), the members of the local Administrators' Group will NOT be removed from the group. The members of the local Administrators group are cached on service start (preserved users are not cached because they will not be removed) in our local storage. The members of the local Administrators Group are added back on service stop or when the Revoke existing local admin rights feature is disabled; 
Preserved Users - allows you to preserve the Administrator permissions of the specified users/domain groups on a specific computer/group of computers (or all computers). If the user/domain group is preserved, the HEIMDAL Agent will not remove it from the local Administrators Group. Preserving a hostname without specifying a username (or a domain group) means that all users on that endpoint will be members of the local Administrators Group. Preserving a username (or a domain group) without specifying the hostname means that all users with this username will be a member of the local Administrators group on all the computers that are applying this Group Policy policy. The Username field allows you to select from the local Administrators that are detected on the endpoints. If the username that you are looking for is not among the ones present in the dropdown selector, you can manually type the username you want to preserve. For this case, ".\admin" is not an accepted value and is not supported; 

Enforce token refresh - this option works, only if the above-mentioned option (Revoke existing local admin rights) is enabled and forces a log-off on the user that is logged in (if he is part of the local Administrators Group) to revoke his membership from the local Administrators Group. A popup will appear in the right-side corner of the screen, to inform the user that he will be automatically logged off in 5 minutes, to completely remove his Administrator privileges. The popup has a button that allows the user to log off right away;
Disable interactive logon - allows you to disable interactive logon to force the users that are logging in to enter both the username and password. Enabling/disabling this option will modify the following registry value: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\dontdisplayusername.
When Interactive Logon is disabled, we get the current value of that registry and override it with 1. The current value is then saved in our repository in the Windows Registry, with the key CachedDontDisplayLastUsername. When Interactive logon is re-enabled, we update dontdisplaylastusername value with the one we cached and then will delete our cached value. This improvement was made because we used to set by default dontdisplaylastusername to 0 if Revoke existing local admin rights was disabled (which it was, by default), even though some of our users needed to set that value to 1.

Customize Tools - manage and customize the applications list (up to 12 applications) displayed in the PEDM Tools functionality from the Agent context menu. 

You can add an entry to match an application based on several conditions:

• Friendly name – “custom” name given to the app. and displayed in the Heimdal Agent context menu, Tools list (e.g.: for “cmd.exe” we’ll display “Command Prompt”);
• Path - represents the path to the directory or file of the app(s);
• File name - is populated automatically from the path information;
•  Action – 2 options are available: editing (allowing the modification of the friendly name and/ or file path info) or deleting an entry.

Use default Tools - allows the use of predefined applications (Command Prompt, Windows Powershell, Services, Registry Editor, Computer Management) in the PEDM Tools functionality from the Agent context menu.