Portal Administration for Linux
Introduction
This topic describes several key areas of the Admin Portal that can be used to manage
-
Setting - the name of the field that controls the setting
-
Type - the type of value that can be entered or selected and its default value
-
Description - how the setting is used and notes about any implications it may have on other settings
To change any of the settings in the portal, log in to the portal and select the setting from the menu.
In this topic
Supplementary Technical Information
Run As Admin Settings
Portal menu: Settings > Workstation Settings > Mac Settings > Authorization > AUTHORIZATION
Settings Table - Run As Admin
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 sudo command or double-clicks an executable file.
|
Setting |
Type |
Description |
|---|---|---|
|
Allow Run As Admin |
Toggle Default: On |
On - Allows users to elevate privileges for a selected file. Enables Require approval and Require reason. Disables Block Run As Admin. Off - Denies users the ability to elevate privileges for a selected file. Enables Block Run As Admin, which is how users with admin credentials can still elevate privileges. |
|
Block Run As Admin (enabled only if Allow Run As Admin is Off) |
Toggle Default: Off |
On - Denies users the ability to execute Run As Admin even if administrator credentials are available (i.e. no Off - Allows users with administrator credentials to execute Run As Admin (i.e. |
|
Require approval |
Toggle Default: Off |
On - Sends a request to the IT team, which must be approved before elevation is granted. Makes Require reason mandatory (i.e. must be On). Off - Allows the user to elevate file privileges (and thus perform the action) as soon as the action is selected. For example, selecting "Run as administrator" to execute a program occurs immediately, without requiring approval. Makes Require reason optional (i.e. can be either On or Off). |
|
Require reason |
Toggle Default: Off |
On - Extends the Off - No reason is required by the user, but details of the actions performed are stored in the Auditlog. |
|
Save |
Button |
Saves customization and changes to any fields. Note that reloading any defaults does not take effect until Save is clicked. |
Admin Session Settings
Portal menu: Settings > Workstation Settings > Mac Settings > Authorization > AUTHORIZATION
Settings Table - Admin Session
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
|
Setting |
Type |
Description |
|---|---|---|
|
Allow Admin Sessions |
Toggle Default: On |
On - Allows users to effectively become a local administrator for the number of minutes specified in Access time (minutes). Enables Require approval, Require reason and Access time (minutes). Off - Denies users the ability to become a local administrator. Hides all other options under Admin Session. |
|
Require approval |
Toggle Default: Off |
On - Sends a request to the IT team, which must be approved before the request is granted. Makes Require reason mandatory (i.e. must be On). Off - Allows the user to become a local administrator as soon as the request is made. Makes Require reason optional (i.e. can be either On or Off). |
|
Require reason |
Toggle Default: Off |
On - Extends the Off - No further information is required by the user, but user and computer details are stored in the Auditlog. |
|
Access time (minutes) |
Integer Default: 15 (minutes) |
The maximum duration in minutes an Admin Session may last. This time must be sufficient for the user to install software or perform any other tasks that require elevation. |
|
Save |
Button |
Saves customization and changes to any fields. Note that reloading any defaults does not take effect until Save is clicked. |
Changing Admin Session Duration
Admin session duration (access time) is the maximum amount of time in minutes an Admin Session may last. This time must be sufficient for the user to install software or perform any other necessary tasks.
To change the time allocated for an administrator session:
-
Log in to the Portal and select menu Settings > Linux Settings.
-
From the Authorization left menu, make sure the AUTHORIZATION tab is displayed (it is the default) and update the Access time (minutes) field in the Admin Session panel:
-
Click Save when done.
Lockdown Settings
The Lockdown menu allows control over the following settings:
-
Admin Rights
-
Sudo
-
Root
Admin Rights
Portal menu: Settings > Workstation Settings > Linux Settings > Lockdown > ADMIN RIGHTS
Settings Table - Admin Rights
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.
|
Setting |
Type |
Description |
|---|---|---|
|
Revoke admin rights |
Toggle Default: Off |
On - Admin privileges are removed for all users except those appearing in the Excluded accounts list.. Off - Admin privileges are not removed for users configured locally as administrators. |
|
Excluded accounts |
Text |
The account name(s) to retain local admin privileges. Multiple accounts must be specified on separate lines. Domain accounts must be prefixed with domain and backslash. |
|
Save |
Button |
Saves customization and changes to any fields. Note that reloading any defaults does not take effect until Save is clicked. |
Settings Table - Sudo
Allowing sudo is strongly discouraged, because it gives the user full control over the endpoint and therefore allows the user to tamper with or completely remove any endpoint software.
Excluded accounts are not removed at logon.
|
Setting |
Type |
Description |
|---|---|---|
|
Allow sudo terminal commands |
Toggle Default: Off |
On - The logged-in user is in the sudoers file and can run sudo commands. Off - The user cannot run sudo commands, even though they are in the sudoers file. |
|
Allow sudo for non-sudoers |
Toggle Default: Off |
On - The logged-in user is not in the sudoers file, but can run sudo commands. Off - The user cannot run sudo commands. |
|
Allow sudo interactive sessions |
Toggle Default: Off |
On -The logged-in user can start a sudo interactive session. Off - The user cannot start a sudo interactive session. |
|
Save |
Button |
Saves customization and changes to any fields. Note that reloading any defaults does not take effect until Save is clicked. |
Settings Table - Root
Allow root login controls whether or not it is possible to log in as root on Linux devices.
Allow root password change controls whether or not it is possible to change the password of the root account.
|
Setting |
Type |
Description |
|---|---|---|
|
Allow root login |
Toggle Default: Off |
On - This endpoint allows users to login as root, or the logged-in user can su (switch user) to root. Off - The endpoint does not allow root logins. |
|
Allow root password change |
Toggle Default: Off |
On - This endpoint allows users to login as root, and also allows the logged-in user to change the root password. Off - The endpoint allows root logins, but the root password cannot be changed. |
|
Save |
Button |
Saves customization and changes to any fields. Note that reloading any defaults does not take effect until Save is clicked. |
Pre-Approval Settings
Portal menu: Settings > Workstation Settings > Linux Settings > App Control > PRE-APPROVE
Pre-Approval (known sometimes as Whitelisting) refers to the method of working out which applications are trusted and frequently used, and adding them to a list that automatically allows users to elevate those applications when they need to. This is essentially the opposite of Blocklisting/Blacklisting – creating a list of applications that cannot be elevated.
This method of “allow most, deny some” has proven to be extremely resource-efficient for large enterprises compared to the method of denying all applications and only allowing elevations on a case-by-case basis.
Admin By Request allows for quick pre-approval of trusted applications from the Auditlog. Pre-Approval is based on the application vendor or checksum, visible when the Application Control screen is displayed (step 3 below).
Once an application has been installed on an endpoint with Admin By Request:
-
Log in to the portal and navigate to the application’s corresponding entry in the portal Auditlog.
-
Expand on the application entry, and select Pre-approve this file under Actions:
-
On the Application Control screen, modify any settings as required. For more information on pre-approval settings, refer to the Settings Table below.
-
Click Save verify that the app has been added to the list of pre-approved applications.
For example, the following applications are pre-approved:
Settings Table - Pre-Approve
Pre-approved applications are
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
New entry
Click button New entry to create a new pre-approved application.
|
Setting |
Type |
Description |
|---|---|---|
|
Log to auditlog (hidden if User confirmation is Off) |
Toggle Default: Off |
On - .Relevant details about the application are logged. Off - No logging is performed for this application. |
|
User confirmation |
Toggle Default: On |
On - .The user must confirm elevation on the endpoint before the application can be run. This is the typical Off - The user does not need to confirm elevation on the endpoint before execution. Hides the Log to auditlog field. |
|
Type |
Selection Default: Run As Admin application pre-approval |
Run As Admin application pre-approval - Pre-approve this application for Run As Admin. Run As Admin location pre-approval (all files in folder tree) - Pre-approve all applications in the specified folder, including any sub-folders. Selecting this option enables the Directory field and hides all other fields. |
|
Protection |
Selection Default: File must be located in read-only directory |
Prevent users from bypassing pre-approval by file renaming. File must be located in read-only directory - The recommended method. File must be in a read-only location. You only need to know the name and location and you are not bound to a specific file version. File must match checksum - A checksum of a specific file version. If the file is updated, the checksum no longer matches and a new one must be collected. No protection (not recommended) - Not recommended for anything except testing. The file can be located anywhere and is a file renaming vulnerability, in case a user is aware of (or can guess) the file name. |
|
Directory (enabled when other selections are in effect):
|
Text |
A read-only location where the application to be added is stored. If the directory entered is not on the local machine, a UNC path can be used. The endpoint software will automatically translate drive letters to UNC path. |
|
Application name |
Text |
The name of the application. Mandatory, although used for convenience only to help identify applications in the list. |
|
File name |
Text |
Enter file name. Adding the app via the Auditlog will auto-populate this field. |
|
Save |
Button |
Saves customization and changes to any fields. Note that reloading any defaults does not take effect until Save is clicked. |
|
Cancel |
Button |
Cancels all work done in this setting and returns to the |
Enabled toggle
A global setting that indicates whether pre-approved applications are allowed at all (On) or not (Off).
Privacy Settings
Portal menu: Settings > Workstation Settings > Mac Settings > Data > PRIVACY
Settings Table - Privacy
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.
Changes apply only to new data. This is by design to avoid accidentally deleting existing data.
|
Setting |
Type |
Description |
|---|---|---|
|
Obfuscate user accounts |
Toggle Default: Off |
On - Create an alias for each user. Off - Do not create aliases for users. |
|
Collect user names |
Toggle Default: On |
On - Record the name of each user associated with an ABR event. Off - Do not record user names. |
|
Collect user email addresses |
Toggle Default: On |
On - Record email addresses associated with a user. Off - Do not record email addresses. |
|
Collect user phone numbers |
Toggle Default: On |
On - Record phone numbers associated with a user. Off - Do not record phone numbers. |
|
Collect inventory |
Toggle Default: On |
On - Record hardware and software inventory data. Off - Do not record inventory data. |
|
Allow geo-tracking |
Toggle Default: On |
On - Record the location of the public IP address associated with the user’s endpoint. Off - Do not record IP addresses. |
|
Save |
Button |
Saves customization and changes to any fields. Note that reloading any defaults does not take effect until Save is clicked. |
Entra ID Support
Azure AD has been renamed by Microsoft to Entra ID. This version of the
A huge selling point for the Admin By Request PAM solution is its flexibility and tools for granular access control; organizations can configure every setting to their specific needs and the needs of all, some, or even individual users.
Settings act as rules, such as whether the Run as Admin or Admin Session features are enabled, and whether or not users need approval to use them. You likely wouldn’t want the rules applied for an IT Administrator to be the same as those applied for a Customer Relations employee, so settings can be differentiated based on Sub-Settings, which allow different rules to be applied to different users and/or groups.
For all the clients, we’ve built in support for Entra ID groups, meaning you can now apply Sub-Settings to existing Entra ID / Azure AD user and device groups.
For more information, refer to Tenant Settings.
For more information on the Entra ID / Azure AD feature, refer to Features > Azure AD Connector.
Settings Table - Entra ID
The Entra ID Connector allows endpoints to retrieve Entra ID (previously Azure AD) groups for sub-settings.
If you are using on-premise Active Directory, you do not need to configure anything - collection of groups for Active Directory is "configuration-less".
The Entra ID Connector is NOT used for single sign-on to the portal; it is solely used for sub-setting groups. Example values:
|
acme.onmicrosoft.com |
|
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
|
azVqedkQlVX9bHLBZjGCQZ6+iZIh4goI7u53i9WlZN8= |
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 National Cloud regions of Azure are designed to make sure that data residency, sovereignty, and compliance requirements are honored within geographical boundaries.
|
Setting |
Type |
Description |
|---|---|---|
|
Enable Connector |
Toggle Default: Off |
On - Turns on the Entra ID Connector and allows endpoints to retrieve Entra ID groups for sub-settings. Off - The Entra ID Connector is disabled and endpoints will use sub-settings as described under "Sub-Settings", rather than using Entra ID rules. |
|
Tenant |
Text |
Standard email address format. Use a new line for each address. |
|
Application ID |
Text |
The value assigned to an application when it is registered with the Microsoft identity platform. |
|
Secret Key |
Text |
The application certificate or client secret generated when the app is registered. |
|
Hybrid Preference |
Selection Default: Prefer Active Directory |
An option available for selection when a computer is both AD-joined and the user makes an Entra ID Workjoin:
|
|
National Cloud |
Toggle Default: Off |
On - Enables selection of a physically isolated instance of Azure. Unhides National Service, which is where the actual geographic instance is selected. Off - Disables selection of a physically isolated instance of Azure. |
|
National Service (hidden if National Cloud is Off) |
Selection Default: US Government L4 / GCC High |
The geographic instance selected:
|
|
Save |
Button |
Saves customization and changes to any fields. Note that reloading any defaults does not take effect until Save is clicked. |
Preventing Abuse
So what prevents the user from abusing an Admin Session? The fact that the user has to ask IT for access will in itself prevent the most obvious abuse. But as part of your settings, you can also configure a Code of Conduct page. Here you customize wording that suits your company policy. For example, what the penalty is for using the administrator session for personal objectives. You can also choose to explain the things you can monitor from the portal.
When you enable the Code of Conduct ("instructions") screen in the settings, this screen appears right before the administrative session starts. You can also customize company name and logo for all screens, so there is no doubt this message is authentic and indeed from the user’s own company. This is the configuration part of the portal, where you set authorization, company logo, policies, email communications, etc:
Policies for Linux
Settings in the Admin By Request client application are controlled under “
Please note we do not recommend that you use
If you have any questions about portal settings or would like a demo of these, please feel free to contact us.
Supplementary Technical Information
This section provides more information on the following:
Local Administrator Accounts
By default, users logging on to a Linux workstation are not downgraded from administrator to user unless the setting ‘Revoke admin rights’ is enabled in the portal and the user is not in the excluded accounts list. The reason all users are not downgraded immediately is because you may have service accounts that you have forgotten to list in the excluded accounts list.
Also, if someone cleared the excluded accounts list and clicked Save by mistake, the result would be unusable endpoints; no users would be able to gain elevated privileges and would instead have very limited ability on their devices.
The following graphic shows Revoke Admin Rights ON, except for user accounts Steve, Jo and Mary:
Sub-Settings
The portal has two levels of settings:
-
Linux Settings (also known as Global Settings) apply to all users by default, except those settings overridden under Sub Settings.
-
Linux 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.
Example sub-settings
This can be used, for example, to allow sudo access for developers or automatically approve requests from users in the IT department.
Sudo
For security reasons, sudo access is disabled during administrator sessions by default. This can be enabled in the settings. We do not recommend enabling sudo access unless absolutely necessary.
Admin By Request has checks in place to prevent system tampering using sudo, but due to the root-level access, it is impossible to fully protect against tampering using sudo.
If only certain commands need to be run with sudo, consider using the built-in /etc/sudoers file. The Admin By Request sudo settings will not override normal /etc/sudoers settings.
Blocking
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.
You should never block solely based on the file name, as this will open up the endpoint to simple file renaming to bypass the blocking.
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.
-
Block file from running as administrator
-
Block vendor files from running as admin (digital certificate)
-
Block location from running as admin (all files in folder tree)
-
Block always
-
No condition (block always)
-
Block if located in directory
-
Block if matching digital certificate
-
Block if matching checksum
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.
Tampering
To prevent tampering with Admin By Request, the software monitors all important files during an administrator session. During a session, access to the Users & Groups preference panel is disabled to prevent users from adding new administrators. Further, by default, sudo access is disabled to prevent calling system-critical tools and user management from the terminal.
The service also monitors users and groups during the session to prevent tampering if sudo access is enabled. If Admin By Request detects that the clock has been changed, the administrator session will end instantly to prevent users from extending their session.
