Dive into the Privilege Elevation and Delegation Management (PADM) module—your complete solution for dynamic user rights control. PADM simplifies the process of elevating user rights or file executions while fully supporting zero-trust executions and instant revocations. Its intuitive, lightweight interface gives you complete control over every elevated session. Approve or deny requests instantly from the HEIMDAL Dashboard or your mobile device. With PADM, you can effortlessly track sessions, enforce escalation periods, and even live-cancel admin rights or block elevation for sensitive system files.
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?
Privilege Elevation and Delegation Management (PEDM) is the HEIMDAL Agent component responsible for dynamic management of user permissions. It functions on all endpoints (domain or non-domain) and is controlled by the dedicated Heimdal Admin Privilege service (Heimdal.AdminPrivilege.exe). PEDM offers flexibility, capable of running under either the SYSTEM context or the USER context. This flexibility allows you to deploy PEDM for two primary use cases: Run with PEDM/Run as administrator, which grants elevation for a single file execution, or a broader Administrator Session, which provides temporary, full administrator rights.
A. Run with PEDM/Run as administrator
The Run with PEDM/Run as administrator functionality provides granular, temporary elevation for select file types, including .exe, .msi, .msc, .cmd, and .cpl. When running under the SYSTEM context, upon execution, the file is typically run by the NT Authority\System account, granting it the necessary Administrator permissions. When running under the USER context (User context elevation needs to be enabled in the Group Policy settings), upon execution, the process runs using the logged-in user's security context instead. The user is presented with the Run with PEDM context menu option, whether running under SYSTEM or USER context:
When disabling the Windows UAC (Disable Windows consent needs to be enabled in the Group Policy), the HEIMDAL Agent enforces the the HEIMDAL UAC, and the custom Run as administrator option is available within the context menu.
IMPORTANT
To successfully execute files directly from a Network Drive (Shared Folder) using this feature, you must have User context elevation 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 the 'Require reason' option is disabled. The Other option in the dropdown 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 following toaster notification will be displayed to the user:
When a HEIMDAL Dashboard Administrator approves the elevation, or it is automatically granted (if Auto-mode is selected in the Group Policy settings), the following toaster notification will appear:
The elevation starts after pressing the Start Now button, and the following toaster notification informs the user that the file has been elevated.
IMPORTANT
The response to an elevation request is automatically propagated to the HEIMDAL Agent within 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 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 2 characters should be added to be able to submit the elevation request reason). This step is skipped if the 'Require reason' option is disabled. The Other option in the dropdown 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 following toaster notification will be displayed to the user:
When a HEIMDAL Dashboard Administrator approves the elevation, or it is automatically granted (if Auto-mode is selected in the Group Policy settings), the following toaster notification will appear:
The elevation starts after pressing the Start Now button, and the following toaster notification informs the user that the file has been elevated.
IMPORTANT
The response to an elevation request is automatically propagated to the HEIMDAL Agent within a 5-minute interval (or in less than a minute if Real-time communication is enabled on the Group Policy that is applying to the endpoint) after being approved by the HEIMDAL Dashboard Administrator.
- BAT or CMD files cannot be executed during elevation.
-
On multi-user sessions that usually occur on Windows Servers acting as RDP/Terminal Servers, the Do not show GUI option is required 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 Run with PEDM functionality will not work, and the Reason window will not show up. To use Run with PEDM, you must first use Heimdal Session Elevator for Servers, which will trigger the GUI and start an elevated session. If you use Run with PEDM 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 the User context elevation enabled in the Group Policy so that the Run with PEDM 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 elevation requests made on the endpoint and gives the user (or a supporter) the ability to request elevation.
Pressing the Elevate button will elevate the user or will display a reason for elevation pop-up 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, 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 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, the Zero-Trust processes that are executed in your environment, and the Primary User Management.
A. PEDM
At 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 filling in your message.
The Pending Approvals view includes advanced filtering options that allow administrators to refine and narrow down elevation requests based on multiple criteria, including the operating system (Devices OS), elevation type such as Session, File, IASME Session, IASME File or non‑elevated executions, and request status such as Requested, Awaiting elevation, Awaiting file elevation, or requests restricted due to risk‑based conditions. These filtering capabilities enable administrators to quickly identify and prioritize elevation requests, improve visibility over pending actions, and streamline approval workflows in environments with a high volume of requests. -
History
This view displays a table with the elevated/de-elevated requests and the following details: Hostname, Username, Start Time, End Time (an info bubble with the number of extensions is displayed when an elevated session has been extended), 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.
The History view includes filtering options that enable administrators to efficiently navigate past elevation events by refining results based on criteria such as operating system (Devices OS) and elevation type, including Session, File, IASME Session, IASME File, or non‑elevated executions. These capabilities allow administrators to quickly isolate relevant elevation activity, improve auditing and troubleshooting workflows, and efficiently analyze historical data across endpoints, while maintaining consistency in filtering behavior and terminology across PEDM views. -
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. If you use Application Control next to Privilege Elevation and Delegation Management, and need 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. -
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 or the Exclusion list). 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.
The tables in each view have a 60-second refresh rate.
B. Primary User Management
In environments with hundreds or thousands of computers, which are often used by multiple users, IT Administrators might want to restrict the ability for users to request elevation to only a predominant user on that specific device. This can be achieved with Primary User Management. On the top, you see a statistic regarding the number of AAD Primary Users, First login primary users, Most logins primary users, and the number of Unassigned hostnames.
In the Standard view, you see a grid containing information about endpoints and their primary users listed as follows: Hostname, Primary user (set on the device), AAD Primary user (the source used to fetch the Primary user, Azure AD or first logged-in user), Most logins user (the user with the highest number of logins in the last 30 days), and Action (a dropdown that allows you to select between the users that logged-in on the device in the last 30 days).
The grid allows you to assign a Primary User by selecting it from the Action dropdown, or you can unassign a Primary User.
Assigning a Primary User
To assign a Primary User, you just need to click on the Action dropdown and select a user that you want to be assigned as Primary User on the specific endpoint. The dropdown includes all the users who 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.
On the HEIMDAL Agent side, only the user who is configured as Primary User will get the ability to request an elevation (single-file or Administrator Session), while other logged-in users will not be able to elevate.
IMPORTANT
In case there are any WIP elevations in use on the endpoint while a new Primary User info is received, all the elevations will be terminated immediately, and the Elevate button will be grayed out. Also, the Run with Admin Privileges option from the context menu (used for file elevations) will be removed. In case Primary Users is enabled and one of the non-Primary Users wants to request a file elevation while Disable Windows Consent is enabled, the custom consent window will display the following message:
Unassigning a Primary User
To unassign a Primary User, you just need to select a hostname in the grid and apply the Unassign primary user action: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 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. The Filters button allows you to filter by criteria specific to each section.
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 their machine by sending a request to the Heimdal Dashboard System Administrator, who can deny or accept their request.
Privilege Elevation and Delegation Management - turn ON/OFF the Privilege Elevation and Delegation Management module.
Deny elevation of system files - allows you to deny elevation of system files (e.g., cmd.exe, powershell.exe, services.msc).
Forbid elevation if CVSS >= 7 - denies elevation requests made from endpoints where a 3rd-party application (managed by the HEIMDAL Agent through the 3rd Party Patch Management) is detected as vulnerable (with a CVSS score of 7 or higher) if the elevation approval mode is set to Auto-mode. This applies to endpoints where 3rd Party Patch Management is enabled.
User context elevation - installs a kernel mini-driver that allows the user to elevate files only under the User context (Run with Admin Privilege under the User context, instead of the System context). The software VC Redistributable 2015-2022 is needed for the option to function properly. This functionality does NOT work if the user is a member of the Network Configuration Operators group. However, Run with Admin Privileges works if the user is moved to any of the following groups: Device Owners, Distributed COM Users, Event Log Readers, Hyper-V Administrators, Access Control Assistance Operators, IIS_IUSR, Network, Performance Log Users, Performance Monitor Users, Power Users, Remote Desktop Users, Remote Management Users, System Managed Accounts Group, Backup Operators.
Multi-Factor Authentication - any type of elevation request will require an MFA code, after which it will proceed to the flow configured in the GP. Once the option gets activated in the GP, the end user will receive an MFA pop-up with a QR code for registration using an authenticator application. Resetting the authenticator: Heimdal Agent -> Settings -> Privileges and App Control -> Privilege Elevation and Delegation Management -> Reset MFA button. The password to reset the MFA is the Master Uninstall Password that can be generated in the Heimdal Dashboard, under Guide -> Your Heimdal activation key.
Primary user - allows only the primary user to request any admin privileges on that specific machine and will start collecting information (over 30-day timeframes) about each user that logs in on that particular machine, to determine the primary user, based on the selected settings.
- Primary user based on AAD - will set the Primary User to be the one defined in the Microsoft Azure AD configuration. This info will be retrieved through an API call, if available, and will automatically set that user as the “Primary User”.
-
Primary user based on first login - will set the Primary User to be the username that is the first non-admin one to log in on each machine that is part of the GP where the feature is enabled, whether it is a local or a domain account.
Note: If both options are enabled, the AAD settings will prevail over the first login mechanism when determining the Primary user.
De-elevate and block elevation for users with risk of infections - automatically removes the Administrator privileges and blocks elevation requests for a user if there were any malware detections found on the endpoint by the Heimdal Agent's Next-Gen Antivirus (statuses: None, QuarantinePending, ExcludePending, RepairPending, DeletePending, ErrorRepair, ErrorDelete, ErrorQuarantine) or VectorN detections in the past 7 days.
Enable PEDM Compliance data retrieval - allows the HEIMDAL Agent to retrieve information about the administrators found on the endpoints where the HEIMDAL Agent is installed.
Webhooks - allow IT Administrators to manage elevations from their own 3rd Party management applications. Enabling Webhooks will open 2 new fields that can get a Friendly Name and a URL (a maximum of 5 URLs are allowed). You can also decide whether the information should be sent as an adaptive card or not (this option is enabled by default). When Adaptive card is enabled, the transmitted data will be sent as an Adaptive Card, allowing for a rich, interactive user experience. If disabled, the data will be sent as a simple JSON object.
Least privilege flow - Enabling this feature securely elevates privileges using a temporary admin account (prefixed HeimdalUser-xxxxx).The account is deleted immediately after use, fulfilling IASME compliance requirements. In the Heimdal Dashboard, these elevations appear as IASME Session-type entries in both the Pending Approvals and History views. Hovering over the icon next to the elevation type reveals the specific user identity that is or has been elevated.
*Note: To be IASME compliant, the following options have to be enabled in the group policy settings:
- Least Privilege Flow
- User Context Elevation
- No Administrator session (file elevation only allowed)
Run as Administrator
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 context 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 to 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.
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.
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's 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. The data regarding an elevation that occurred when the endpoint was offline will be passed to the HEIMDAL Dashboard after the endpoint is restarted. The HEIMDAL Agent can fetch the data for the last 7 days.
Local token elevation validity - allows you to customize the validity of the token.
Pre-elevation cloud AV scanning - the file is scanned before the elevation request is allowed to follow the set approval flow. When the approval is set to auto-mode, detecting an infected file with a risk score higher than the set limit, will trigger a pop up on the device informing that file is flagged as malicious and advises the user to contact the administrator. For the Approval via Dashboard setting, in the dashboard, the request will display the risk score and approving the request will trigger an additional confirmation dialog window. The setting is available only for: Auto-mode and Approvals via Dashboard. Enabling the Local token elevation disables the option.
Block elevation when scan risk score exceeds - allows setting the maximum allowed threshold for the scanned file before the elevation request is blocked.
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's 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. The data regarding an elevation that occurred when the endpoint was offline will be passed to the HEIMDAL Dashboard after the endpoint is restarted. The HEIMDAL Agent can fetch the data for the last 7 days.
Local token elevation validity - allows you to customize the validity of the token.
Cloud AV scanning of admin executed files - enables an automatic scan only for the non-system files that are elevated during the session. When running with admin rights a file detected as infected, the user will be automatically de-elevated, and a pop up will be triggered, informing the user about the detection. The setting is available only for: Auto-mode and Approvals via Dashboard. Enabling the Local token elevation disables the option.
De-elevate user when scan risk score exceeds - allows setting the maximum allowed threshold for the scanned files before the elevation is terminated and the user is de-elevated.
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 Entra ID/Azure AD credentials to be able to request elevation on an endpoint. This feature is meant for Administrators who remotely connect to 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 in. To utilize this functionality, devices must be present in Microsoft Entra ID as Registered, Joined, or Hybrid Joined. Please note that only hybrid identities (users synchronized from on-premises AD) are supported; cloud-only accounts are currently excluded.
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.
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.
Session length (2 MIN -24 H) - allows you to set the interval for the elevation session.
Allow end users to extend the Administrator Session length - allows you to allow the end user to extend an ongoing elevated session with the number of minutes configured in the Extended session length (between 2 minutes and 1 hour).
Extended session length - allows you to specify the interval an extended session should last (between 2 minutes and 1 hour).
Number of admin rights extensions allowed - the number of extensions an end user is allowed to make.
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 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 who 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 - you are allowed to exclude a process or a file from the Zero-Trust Execution Protection by File Name, File Path, Directory, Wildcard (C:\*\MyFolder\*.exe), or MD5.
Automatic Administrator message - allows you to configure an approval and a denial message to be sent automatically to users when accepting/revoking their requests. To validate this functionality, at least one of the two sub-settings must be enabled, and if any of them is configured, a corresponding message needs to be configured.
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 who are logged in will preserve the Administrator permissions until the first logoff/reboot. 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 members of the local Administrators group on all the computers that apply this Group 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 who is logged in (if he is part of the local Administrators Group) to revoke his membership from the local Administrators Group. A pop-up will appear in the right-hand 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 pop-up 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 who 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 the dontdisplaylastusername value with the one we cached, and then we 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.
Select Tray Tools to add - this dropdown menu allows you to add several commonly used applications from the System32 folder:
-
Add or Remove Programs – appwiz.cpl - Because this prompt requires Administrator permissions, this action replaces the default Add or Remove Programs with a custom tool that allows performing the same operations.
- Allow Remote Access – SystemPropertiesRemote.exe
- Command Prompt – cmd.exe
- Computer Management – compmgmgt.msc
- Device Manager – devmgmt.msc
-
Network Adapter Settings – ncpa.cpl - Because this prompt requires Administrator permissions, this action replaces the default Network Settings with a custom tool that allows performing the same operations.
- Regedit – regedit.exe
- Services – services.msc
- Turn Windows Features On or Off – OptionalFeatures.exe
- View Event Logs – eventvwr.msc
- Windows PowerShell – powershell.exe
The grid allows you to change the order of the items according to your preferences.