Portal Administration for Mac

Introduction

This topic documents configuration parameters in the Admin Portal that can be used to manage Mac Settings  and Sub Settings.

Fields that can be set/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 and Blocked Settings

Managed sudo [Mac 6.0+]

Machine Learning

Privacy Settings

Preventing Abuse

Clean up Local Admins

Supplementary Technical Information

Entra ID Support

Portal menu: Settings > Tenant Settings > Identity > ENTRA ID

A selling point for the Admin By Request EPM 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 Windows and Mac 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 the Entra ID Connector.

Okta groups on macOS (subsettings)

For group-based subsettings on macOS, use the following prerequisites:

• Admin By Request for Mac 5.2 or newer

• Platform SSO sign-in with Okta as the identity provider

This prerequisite applies to group and subsettings resolution. MFA via SAML remains a separate flow.

Run As Admin Settings

Portal menu: Endpoint Privilege Management > Settings > Mac Settings > Authorization > AUTHORIZATION

Admin Session Settings

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

Remotely terminating elevated access [Mac 6.0+]

Portal administrators can end elevated access on a managed Mac before it expires on its own. This covers both an active Admin Session and a Run As Admin elevation.

Termination takes effect immediately:

• For an Admin Session, the user is removed from the local administrators group and any elevated applications are closed.

• For Run As Admin, the elevated access is ended for the affected elevation.

A blackout period can be applied at the same time. While it is in force, the user cannot start a new Admin Session or Run As Admin request on that device, which gives IT time to investigate or remediate before further elevation is allowed. The blackout expires automatically, after which the user can request elevation again under the usual policy and approval rules.

The auditlog records who ended the session. Use remote termination, also referred to as Remote Kill, when elevated access has to stop at once: a request approved in error, work that finished earlier than expected, or a device that needs investigating.

Two points about this:

1. The user is not told why. An elevation request made during a blackout is refused with the generic message "The request was denied due to company policy". Nothing identifies the blackout, who applied it, or when it expires, so expect a support call if the user is not told separately. The portal does log the attempt as a blackout-period attempt.

2. It needs a working client. This is a portal action delivered to the endpoint, so it cannot help with a device whose client has stopped syncing.

Remote termination is started from the auditlog: expand the running entry, and use the Remote Kill panel shown beside the entry details. The example below comes from a Windows entry.

Refer to Auditlog for the full procedure.

Authentication Setting

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

Platform SSO as an identity source for Email match [Mac 6.0+]

Where MFA is configured to use Email match, macOS can take the trusted corporate email address or user principal name from Platform SSO. This lets Email match work on a Mac with no Entra ID connector configured, provided that Platform SSO is configured and the user has completed Platform SSO registration on that Mac.

Email match needs an identity that is trusted and tied to the local Mac user. There are two such sources: a registered Platform SSO identity, or a user principal name (UPN) verified through the Entra ID Connector. Outlook and Teams can supply a UPN that Admin By Request uses to look the user up, but signing in to those apps does not make that UPN trusted for Email match.

System Settings

Portal menu: Endpoint Privilege Management > Settings > Mac Settings > App Control > SYSTEM SETTINGS (moved from Endpoint Privilege Management > Settings > Mac Settings > Lockdown > SYSTEM SETTINGS)

System Settings pre-approval [Mac 6.0+]

macOS 6.0 changes how System Settings access is granted to a standard user. It becomes a pre-approval decided per setting, rather than a lockdown that hides panes:

• On means the setting is pre-approved, so a standard user can change it.

• Off means there is no pre-approval, and the setting behaves as macOS intends: a standard user can open and read it, but cannot change it.

The visible difference is that panes are no longer greyed out and no longer claim to be controlled by a profile. A standard user can open a pane that is not pre-approved and interact with it, at which point macOS raises its own administrator credential prompt. The outcome is unchanged, in that the user still cannot make the change, but the endpoint now says so up front instead of showing a profile message when no profile is involved.

A user in an active Admin Session can use all the System Settings panes except Users & Groups.

The change came out of 5.3.x deployments, where some organizations preferred Admin By Request to leave the operating system's own behavior for standard users alone.

Enabling sudo

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

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.

Sudo and managed sudo [Mac 6.0+]

Allowing sudo during an Admin Session does not give standard users unrestricted sudo. Outside a session a standard user can run only what a sudo command pre-approval rule permits, and sensitive command paths can be withheld during a session with sudo command block rules.

Pre-Approval and Blocked Settings

Portal menu: Endpoint Privilege Management > Settings > Mac Settings > App Control > PRE-APPROVE | BLOCKED

Pre-approved applications are application files that are pre-approved to run "Run As Admin", when approval is otherwise required. The intention is to remove trivial approval flows and avoid flooding the auditlog with trivial data for applications known to be good.

When an application is on the pre-approval list the difference is:

• The application is auto-approved; 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 (trivial data)

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

Managed sudo [Mac 6.0+]

macOS 6.0 adds policy-based control of sudo for standard users. Selected commands can be allowed to run with sudo without giving the user standing local administrator rights, and selected commands can be withheld from a user who is in an Admin Session. Both are configured from the same App Control screen as application pre-approval and blocking, using two rule types added in 6.0.

This is for controlled command-line work where a user needs a small, known set of administrative commands. It is not a way to hand out broad sudo access.

The two rule types

Create a rule as you would for an application, and choose the sudo type in the Type list:

1. sudo command pre-approval (6.0+), under Endpoint Privilege Management > Settings > Mac Settings > App Control > PRE-APPROVE, allows a standard user to run the named command with sudo, with no Admin Session:

   

2. sudo command block (6.0+), under Endpoint Privilege Management > Settings > Mac Settings > App Control > BLOCKED, prevents a user who is in an active Admin Session from running the named command with sudo:

   

Both forms take the same two fields. Application name is a logical name for your own overview list, and File path is the absolute path of the executable, for example /usr/sbin/dseditgroup. The pre-approval form also carries the Log to auditlog toggle used by application pre-approvals.

How the rules apply

1. For a standard user, sudo is deny-by-default. A command runs with sudo only when a sudo command pre-approval rule names it. Everything else is denied.

2. During an Admin Session, sudo is allowed. That is why the block list exists: it is the only way to withhold a sensitive command path from a user who is otherwise entitled to use sudo for the duration of the session.

3. A pre-approval wins. Where the same command matches both a pre-approval and a block rule, the pre-approval takes precedence.

4. Rules match the command, not what it does with its arguments. Arguments and flags are recorded in the audit entry, but they are not evaluated for policy matching in 6.0, so scope rules to command paths you trust. Argument-level restriction is planned for a later release. Because arguments are recorded, see the redaction note about sensitive information at the end of this section.

5. A pre-approval does not approve an interactive root shell. sudo -i, sudo -s, sudo su and sudo bash are not covered by a rule for some other command.

6. Permanent local administrators are not affected. A user who is a local administrator outside an Admin Session keeps normal macOS sudo behavior and is not subject to managed sudo rules.

When managed sudo takes effect, and how to turn it off

Managed sudo is not enforced as soon as the 6.0 client is installed. Any sudo access that the Mac's existing sudoers configuration grants continues after installation, until the first managed sudo rule (a pre-approval or a block) reaches the endpoint. That first rule activates Admin By Request enforcement, and from then on a standard user's sudo is decided by managed sudo policy, as described above.

Managed sudo works with Apple's own sudo rather than replacing it. When a pre-approved command is allowed, Admin By Request creates a short-lived sudoers rule for the logged-in user that covers only that command, runs it with Apple's sudo, and removes the rule afterwards. This is why a pre-approved command does not ask for a password.

Two points are important when you want to stop using managed sudo:

1. An empty rule list keeps managed sudo active. Deleting the last rule does not turn managed sudo off if the policy still supplies an empty list. Enforcement continues, so a standard user can run nothing with sudo outside an Admin Session.

2. Turning it off means removing its policy configuration. That includes any managed sudo configuration the endpoint inherits. The client removes its sudo wrapper only after it receives a complete policy that carries no managed sudo lists.

Command paths, and what the user actually types

This is the part most likely to cause confusion, because the administrator and the user are working with different strings.

You configure an absolute path. The user does not have to type one. Admin By Request resolves a bare command through the user's PATH and applies policy to the path it resolves to, so a pre-approval for /usr/bin/whoami allows the user to type sudo whoami.

The approval covers that executable. A different executable with the same name in another directory is not covered by the same rule.

What is recorded

Allowed managed sudo commands are recorded in audit history, including commands run during an Admin Session. A pre-approved command run by a standard user is written to the Run As Admin auditlog rather than raised as an alert, because it was approved in advance, and it carries Approval: Pre-approved with Reason: Managed sudo. Whether an individual rule writes an entry at all is controlled by its Log to auditlog toggle.

Denied attempts are treated as higher-signal events and are reported under Events, each with a reason code: not-pre-approved where no rule allowed the command, and sudo-blocked where a sudo command block rule matched. Tampering and bypass attempts are reported the same way.

On the endpoint, a user whose command is refused sees:

Admin By Request: this sudo command is not allowed by your IT policy.

Before 6.0, sudo on macOS was reachable only inside an Admin Session and could not be logged per command at all, so this is also the point at which sudo activity becomes auditable.

Pre-approve/Block via Team ID and Auditlog

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:

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 and Oracle America, Inc. are the vendors, while 75GAHG3SZQ and VB5E2TV963 are their respective Team IDs.

Admin By Request allows for quick pre-approval/blocking of trusted/untrusted applications from the Auditlog, 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.

Protection matchers

The Protection dropdown is where the new identifiers appear, and it is identical on both forms:

• File must match vendor (pre-5.3 behavior, still available)

• File must match team id (5.3+)

• File must match team and bundle id (5.3+)

• File must match checksum

• No protection (not recommended)

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

Privacy Settings

Portal menu: Endpoint Privilege Management > Settings > Mac Settings > Data > PRIVACY

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:

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: