Portal Administration for macOS

Introduction

This topic describes several key areas of the Admin Portal that can be used to manage Mac Settings and Mac 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

Run As Admin Settings

Admin Session Settings

Authentication Confirm Setting

Enabling sudo

System Settings

Pre-Approval Settings

Machine Learning

Privacy Settings

Entra ID Support

Preventing Abuse

Policies for macOS

Supplementary Technical Information

Run As Admin Settings

Portal menu: Settings > Workstation Settings > Mac Settings > Authorization > AUTHORIZATION

Admin Session Settings

Portal menu: Settings > Workstation Settings > Mac Settings > Authorization > AUTHORIZATION

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:

  1. Log in to the Portal and select menu Settings > Mac Settings.

  2. 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:

  3. Click Save when done.

Authentication Confirm Setting

Portal menu: Settings > Workstation Settings > Mac Settings > Endpoint > AUTHENTICATION

System Settings

Portal menu: Settings > Workstation Settings > Mac Settings > Lockdown > SYSTEM SETTINGS

Enabling sudo

Portal menu: Settings > Workstation Settings > Mac Settings > Lockdown > ADMIN SESSION

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 Settings > Workstation 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: Settings > Workstation 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.

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.

For example, the following applications are pre-approved:

You can enter the following commands to get the vendor’s name for the files for Pre-Approval, without having to use the Auditlog in your User Portal. For example:

For applications (.app) For packages (.pkg)
Command:
codesign -d -vv /path/app.app
Command:
pkgutil –check-signature /path/app.pkg
Result:
Authority=Developer ID Application: VideoLAN (75GAHG3SZQ)
Result:
Developer ID Installer: Oracle America, Inc. (VB5E2TV963)

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

Machine Learning

Portal menu: Settings > Workstation 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.

The way it works is, it allows you to create a simple rule that says:

“If approval for elevation of an application is granted X times, that application is now automatically approved for incoming requests from then on.”

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: Settings > Workstation Settings > Mac Settings > Data > PRIVACY

Entra ID Support

NOTE:

Azure AD has been renamed by Microsoft to Entra ID. This version of the site pages uses both terms interchangeably, but future versions will refer to Entra ID only.

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.

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 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.

Copy
{
    “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 restart the service using:

   sudo killall adminbyrequest.

Key

Type

Default

Description

AdminMinutes

Integer

15

Number of minutes the user is administrator. This can also be set in your portal settings.

AllowAppStore

Boolean

1

Allow users to install software from the App Store without admin rights or an active Admin By Request session.

AllowSudo

Boolean

0

Allow users to run sudo commands. Should not be enabled unless there is a good reason to, because it allows the user to tamper the endpoint software.

CompanyName

String

 

Overrules the company name that appears on user interfaces, which is by default the licensed company name.

ComputerGroups

Array of Strings

 

Computer groups to match machine to sub settings when not using Active Directory.

DockIcon

Boolean

1

Place an icon in the dock.

ExcludedAccounts

Array of Strings

 

List of accounts that will not be downgraded to user role, such as service accounts.

EnableSessions

Boolean

1

User can request an admin session.

EnableAppElevations

Boolean

1

User can authenticate apps without session.

Instructions

String

 

Body text on Code of Conduct (“Instructions”) screen.

InstructionsHeader

String

 

Header text on Code of Conduct (“Instructions”) screen.

LogoUrl

String

 

URL from which to download logo. If not specified, default icons will be used.

RemoveRights

Boolean

1

Downgrade users from Admin to User, unless the account is in excluded accounts or is a domain administrator in on a domain-joined device.

RequireApproval

Boolean

0

Elevate without requiring someone to approve requests.

RequireReason

Boolean

1

Require reason to elevate.

RequireAppApproval

Boolean

0

Elevate Run As Admin without requiring someone to approve requests.

RequireAppReason

Boolean

1

Require reason to Run As Admin.

ShowInstructions

Boolean

0

Show Code of Conduct screen.

UploadInventory

Boolean

1

Upload inventory data to the portal.

UserGroups

Dictionary with Array of Strings

 

User groups to match machine to sub settings when not using Active Directory.

IMPORTANT:

Please note we do not recommend that you use a policy file to control client behavior. Instead, we recommend that you use portal settings and sub settings for better transparency and for real-time control of computers not connected to your LAN.

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

In the policy file, you can setup all groups to correspond to the Subsetting in the ABR portal, as per the example below:

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:

Removed in macOS Version 3.0 Onwards

  • Last Admin Check – no longer relevant, removed in 3.0. The Last Admin Check feature is no longer relevant thanks to the addition of the PIN Code uninstall feature. The purpose of the Last Admin Check was to ensure that you always have at least one administrator account left, but is no longer necessary because you can now use PIN Code uninstall to remove the software on the endpoint and regain local admin rights (in the case of accidentally downgrading all users to standard user).

  • Log Files – this service previously logged helpful information such as software version, detected Active Directory settings, admin downgrades, and similar changes to /var/log/adminbyrequest.log. It has been replaced in recent versions with functionality to submit diagnostics information from the About window, under Diagnostics.