Portal Administration for Mac

Introduction

This topic describes several key areas of the Admin Portal that can be used to manage Mac Settings  and Sub Settings.

Fields that can be set and/or configured in the portal are presented in tables, with each table showing:

• 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

Entra ID Support

Run As Admin Settings

Admin Session Settings

Authentication Setting

System Settings

Enabling sudo

Pre-Approval Settings

Machine Learning

Privacy Settings

Preventing Abuse

Policies for macOS

Clean up Local Admins

Supplementary Technical Information

Entra ID Support

Portal menu: Settings > Tenant Settings > Groups > ENTRA ID / AZURE AD

A 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 endpoint 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. The Entra ID Connector is NOT used for single sign-on to the portal; it is used solely for sub-setting groups.

If you are using on-premise Active Directory, you do not need to configure anything - collection of groups for Active Directory is "configuration-less".

Example values:

Tenant	acme.onmicrosoft.com
Application ID	xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Secret Key	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.

NOTE

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 On | Off 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: Prefer Active Directory - User is AD-joined only. Prefer Entra ID / Azure AD - User is AD-joined and makes an Entra ID Workjoin.
National Cloud	Toggle On | Off 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: US Government L4 / GCC High - Azure portal (global service) US Government L5 / DoD - Azure portal for US Government China (21Vianet) - Azure portal China operated by 21Vianet
Save	Button	Saves customization and changes to any fields. Note that reloading any defaults does not take effect until Save is clicked.

Run As Admin Settings

Portal menu: Endpoint Privilege Management > 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 drops an application on the Admin By Request dock icon to install it or by running a .pkg file. After re-authenticating with credentials, the user is able to install the application or .pkg file without having administrator rights.

Full Disk Access must be enabled. Please refer to Mac Client - Install / Uninstallfor more information.

Setting	Type	Description
Allow Run As Admin	Toggle On | Off 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.
Require approval (hidden if Allow Run As Admin is OFF)	Toggle On | Off 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 (hidden if Allow Run As Admin is OFF)	Toggle On | Off Default: Off	On - Extends the authentication window and asks the user to enter email address, phone number and reason. Reason must comprise at least two words. This information is stored in the Auditlog. 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: Endpoint Privilege Management > 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 menu bar icon to request a protected administrator session, which makes the user a temporary member of the local administrator's group for a limited period of time under full audit.

Setting	Type	Description
Allow Admin Sessions	Toggle On | Off 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 On | Off 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 On | Off Default: Off	On - Extends the authentication window and asks the user to enter email address, phone number and reason. This information is stored in the Auditlog. 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.

Authentication Setting

Portal menu: Endpoint Privilege Management > Settings > Mac Settings > Endpoint > AUTHENTICATION

Settings Table - System Settings

The setting allows portal administrators to specify the style of prompt that is presented when users must authenticate to elevate privileges.

Setting	Type	Description
Mode	Choice: Confirm Multi-factor Authentication Default: Confirm	Confirm - User must confirm with Yes or No (or via the reason screen) to perform the operation.. Multi-factor Authentication - User must validate identity using MFA through Single Sign-on. Choosing this option unhides Multi-factor Configuration (see table below).
Save	Button	Saves customization and changes to any fields. Note that reloading any defaults does not take effect until Save is clicked.

Multi-factor Configuration

Appears when Multi-factor Authentication is chosen as the Mode.

Setting	Type	Description
Email match	Toggle On | Off Default: On	On - SSO authentication must match the email address from Active Directory or Azure AD. Off - Email address does not need to match.
MFA on pre-approvals	Toggle On | Off Default: Off	On - Force multi-factor authentication on pre-approved applications. Off - Multi-factor authentication is not required on pre-approved applications

System Settings

Portal menu: Endpoint Privilege Management > Settings > Mac Settings > Lockdown > SYSTEM SETTINGS

Settings Table - System Settings

System Settings (also known as System Preferences in earlier macOS versions) have long been part of the macOS platform, enabling users to locally customize the look and feel of their Macs. This can lead to problems if users have admin rights, because some settings chosen by users might conflict with requirements of the organization.

The Admin By Request System Settings Lockdown feature controls access to specific system settings in macOS by enabling or disabling access to their corresponding right-hand panels. Each of seven panels can be enabled or disabled from the portal simply by setting a toggle to On or Off.

Setting	Type	Description
Users & Groups	Toggle On | Off Default: Off	On - Users & Groups panel is not blocked for this user and will display. Off - Panel is blocked for this user and will not display. No changes can be made.
Login Items	Toggle On | Off Default: Off	On - Login Items panel is not blocked for this user and will display. Off - Panel is blocked for this user and will not display. No changes can be made.
Network	Toggle On | Off Default: Off	On - Network panel is not blocked for this user and will display. Off - Panel is blocked for this user and will not display. No changes can be made.
Sharing	Toggle On | Off Default: On	On - Sharing panel is not blocked for this user and will display. Off - Panel is blocked for this user and will not display. No changes can be made.
Startup Disk	Toggle On | Off Default: On	On - Startup Disk panel is not blocked for this user and will display. Off - Panel is blocked for this user and will not display. No changes can be made.
Transfer or Reset	Toggle On | Off Default: On	On - Transfer or Reset panel is not blocked for this user and will display. Off - Panel is blocked for this user and will not display. No changes can be made.
Wi-Fi	Toggle On | Off Default: On	On - Wi-Fi panel is not blocked for this user and will display. Off - Panel is blocked for this user and will not display. No changes can be made.
Save	Button	Saves customization and changes to any fields. Note that reloading any defaults does not take effect until Save is clicked.

Enabling sudo

Portal menu: Endpoint Privilege Management > Settings > Mac Settings > Lockdown > ADMIN SESSION

Settings Table - Admin Session

These settings control whether or not users are able to run sudo commands during a terminal session.

Setting	Type	Description
Deny PIN code unlock	Toggle On | Off Default: Off	On - Remove the option to use a PIN Code to unlock an admin session or unlock a blocked application. If this option is Off and admin sessions are disabled, the system tray menu item to start an admin session will be removed. Off - Allow access to the PIN Code unlock option (unless Allow Admin Sessions is Off under Authorization > AUTHORIZATION).
Force sudo close at end	Toggle On | Off Default: On	On - Forcibly close any sudo command or interactive sudo session at the end of the admin session. Off - Do not force closure of sudo sessions.
Allow sudo terminal commands	Toggle On | Off Default: Off	On - Allow user to issue sudo commands from a terminal prompt. Off - Do not allow user to issue sudo commands.
Save	Button	Saves customization and changes to any fields. Note that reloading any defaults does not take effect until Save is clicked.

For security reasons, sudo access is disabled during administrator sessions by default. This can be enabled in the settings or a policy file (see Policies for macOS). We do not recommend enabling sudo access unless absolutely necessary.

To enable sudo for Mac devices, login to the portal, go to Endpoint Privilege Management > Settings > Mac Settings > Lockdown > ADMIN SESSION and set Allow sudo terminal commands to On.

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.

Pre-Approval Settings

Portal menu: Endpoint Privilege Management > Settings > Mac 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.

Use the following commands to get a vendor’s name for the files for Pre-Approval, without having to use the Auditlog in the portal. For example:

In these examples, VideoLAN (75GAHG3SZQ) and Oracle America, Inc. (VB5E2TV963) are the vendors.

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:

1. Log in to the portal and navigate to the application’s corresponding entry in the portal Auditlog.

2. Expand on the application entry, and select Pre-approve this file under Actions:

   

3. On the Application Control screen, modify any settings as required. For more information on pre-approval settings, refer to the Settings Table below.

4. Click Save verify that the app has been added to the list of pre-approved applications.

Settings Table - Pre-Approve

Pre-approved applications are application files that are pre-approved to run Run As Admin, when approval would normally be required. The intention is to remove trivial approval flows and avoid flooding the audit log with trivial data for applications known to be good, such as Adobe Reader installs.

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

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

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

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

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

Enabled toggle

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

New entry (APPLICATION tab)

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

Setting	Type	Description
Log to auditlog (hidden if User confirmation is Off)	Toggle On | Off Default: Off	On - .Relevant details about the application are logged. Off - No logging is performed for this application.
User confirmation	Toggle On | Off Default: On	On - The user must confirm elevation on the endpoint before the application can be run. This is the typical authentication window. 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 vendor pre-approval - Pre-approve this vendor for Run As Admin. Selecting this option enables the Vendor field and hides all other fields.
Vendor (enabled when Run As Admin vendor pre-approval is selected)	Text	Enter vendor name. Adding the app via the Auditlog will auto-populate this field.
Protection	Selection Default: File must match vendor	Prevent users from bypassing pre-approval by file renaming. File must match vendor - The application name and the file name must align with the same details provided by the vendor. 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.
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. Note that 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 Mac Workstation Global Settings page.

Machine Learning

Portal menu: Endpoint Privilege Management > Settings > Mac Settings > App Control > MACHINE LEARNING

The idea behind Machine Learning Auto-Approval is to kill two birds with one stone by allowing customers to build a Pre-Approved list as their employees use the software. This removes the need for enterprises to spend considerable amounts of time and effort figuring out and manually configuring which applications should be pre-approved ahead of time.

This allows the system to handle creating the list of applications that are safe for approval as applications are used.

For more information, including step-by-step procedures, refer to Features > Machine Learning.

Privacy Settings

Portal menu: Endpoint Privilege Management > 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 collects both 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.

NOTE

Changes apply only to new data. This is by design to avoid accidentally deleting existing data.

Setting	Type	Description
Obfuscate user accounts	Toggle On | Off Default: Off	On - Create an alias for each user. Off - Do not create aliases for users.
Collect user names	Toggle On | Off 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 On | Off Default: On	On - Record email addresses associated with a user. Off - Do not record email addresses.
Collect user phone numbers	Toggle On | Off Default: On	On - Record phone numbers associated with a user. Off - Do not record phone numbers.
Collect inventory	Toggle On | Off Default: On	On - Record hardware and software inventory data. Off - Do not record inventory data.
Allow geo-tracking	Toggle On | Off 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.

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.

For example:

Policies for macOS

Settings in the Admin By Request client application are controlled under “Mac Settings” in the Settings menu, when logged in to the portal. If, for whatever reason, you want to overrule these settings on specific clients, you can set overruling policies in a policy file.

To overrule portal settings with a policy file, edit this file:

   /Library/Application Support/Admin By Request/adminbyrequest.policy

Note that this file is protected during administrator sessions and therefore cannot be hacked by end-users. The file is in json format and has an example non-used setting by default, as shown below. Simply add more settings from the following table to overrule web settings.

{
    “ExampleSetting”: “ExampleValue”
}

Also note that any change to the policy file will take effect after the next reboot. Alternatively, if a policy change must take effect immediately without a reboot, an admin user or MDM can refresh the service using:

open -g -n /Applications/Admin\ By\ Request.app --args -refresh

If you do decide to use a policy file, you can use it if you do not have an AD or an Entra ID.

If you have any questions about portal settings or would like a demo of these, please feel free to contact us.

Clean up Local Admins

The Clean Up Local Admins  feature in Admin By Request is designed to help IT administrators easily manage and remove unused or rogue local administrator accounts across multiple endpoints. A quick check (and subsequent clean up if necessary) can be done directly from the portal, giving administrators an immediate and holistic view of just who currently has admin access on which computers.

The feature simplifies the process of identifying and revoking unnecessary admin rights, reducing the attack surface and enhancing security within an organization.

Purpose

The feature addresses the common problem of unmanaged or forgotten local admin accounts that could pose security risks. These accounts may belong to former employees or be leftover from previous configurations, making them prime targets for cybercriminals seeking to exploit elevated privileges.

Functionality

The feature centralizes the management of local admin accounts by allowing administrators to revoke admin rights from a single interface within the portal. This eliminates the need to manually disable accounts on individual endpoints.

How It Works

1. Access the Feature:

   Navigate to the Inventory page within the portal.

   Select the desired endpoint and click Local Admins from the left-hand menu. This brings up a 'birds-eye' view of all administrator accounts associated with that endpoint, displayed as individual account cards.

2. Identify Admin Accounts:

   Each account card is labeled with an icon and a name indicating the type of account (e.g., Local Administrator, Domain Administrator etc.).

   Rogue or unused accounts may be identified by non-descriptive names, often represented by long numeric sequences.

3. Revoke Admin Rights:

   To revoke admin rights, click the Revoke Rights button located on the account card. This button is highlighted in orange.

   The button will change to Cancel Revoke, allowing you to undo the action if it was selected by mistake.

4. Restore Admin Rights:

   Admin rights can be restored by selecting the Restore Rights button within the Restore Revoked Local Administrators section during the two-week window.

Safeguards

The feature includes built-in safeguards to prevent the removal of essential accounts, such as the first Administrator account used to setup the computer. This ensures that critical administrative access is not inadvertently revoked, which could otherwise render endpoints inaccessible.

Using the Feature via Reports Page

Alternative Access

The Clean Up Local Admins  feature can also be accessed through the Reports  page for bulk management of admin accounts.

Navigate to Reports > User Reports > Local Admins to view admin accounts in a list format, grouped by account type.

Rogue accounts can be removed in bulk by selecting the Remove button next to the corresponding account group.

Undoing Removal:

If an admin account is mistakenly removed, the action can be reversed by going to the RESTORE RIGHTS tab on the Local Admins page.

The removed group will be listed, and selecting the Undo button will restore the admin rights to the affected accounts.

Example - Olivia's Mac

The procedure is straightforward:

1. Log in to the portal and go to the Inventory.

2. Locate the endpoint concerned and drill-down using either its name in the Computer  column, or Details in the Details  column.

3. In the left menu, click Local Admins:

   

4. Finally, identify the users who should not be admin and use the Revoke Rights button to remove their administrator privileges.

Supplementary Technical Information

This section provides more information on the following: