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
Supplementary Technical Information
Entra ID Support
Portal menu: Settings > Tenant Settings > Identity > ENTRA ID
Azure AD has been renamed by Microsoft to Entra ID. This version of the
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.
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:
|
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. Reveals National Service, which is where the actual geographic instance is selected. Off - Disables selection of a physically isolated instance of Azure. Hides National Service. |
|
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. |
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 / Uninstall for more information.
|
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. |
|
Require approval (hidden if Allow Run As Admin is OFF) |
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). IMPORTANT
The Free Plan default for this setting is Off, which means that users simply have to request elevated access and it will be automatically granted. We recommend changing this setting to On. Note that the default setting may be changed in a future release. |
|
Require reason (hidden if Allow Run As Admin is OFF) |
Toggle Default: On |
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: 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
|
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). IMPORTANT
The Free Plan default for this setting is Off, which means that users simply have to request elevated access and it will be automatically granted. We recommend changing this setting to On. Note that the default setting may be changed in a future release. |
|
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 > Mac 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.
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:
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 reveals 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 |
|---|---|---|
|
Sign-on method |
Selection:
Default: |
Microsoft 365 / Entra ID - Use this as the SSO method. -- ADD NEW METHOD -- - Create a new method. Choosing this option takes you to the portal's Single Sign-on (SSO) Setup page. Note the following:
|
|
Email match |
Selection:
Default: |
No matching - If using Entra ID and this option is selected for Email match, the Entra ID Connector must be configured. This ensures that only users within the same Azure tenant can authenticate. Email match - MFA authentication must match the email address or User Principal Name (UPN) from Entra ID or Active Directory. Account separation - MFA authentication must be done via a secondary account. This is a requirement for those organizations wishing to maintain compliance with Cyber Essentials Plus. |
|
MFA on pre-approvals |
Toggle 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 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 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 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 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 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 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 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 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 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 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 Portal Administration for Mac). 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:
|
For applications (.app) |
For packages (.pkg) |
|---|---|
|
Command:
|
Command:
|
|
Result:
|
Result:
|
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:
-
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-approval allows users to run some applications without approval, typically used to define exceptions when approval is required.
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
-
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 at all (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 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 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 |
Export buttons
Four export buttons are also provided:
-
Export to PDF
-
Export to XLSX
-
Export to CSV (;)
-
Export to CSV (,)
These buttons export all entries in the list.
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.
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: 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.
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. |
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
-
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.
-
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.
-
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.
-
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:
-
Log in to the portal and go to the Inventory.
-
Locate the endpoint concerned and drill-down using either its name in the Computer column, or Details in the Details column.
-
In the left menu, click Local Admins:
-
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:
Local Administrator Accounts
By default, users logging on to a Mac 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:
Active Directory
If a Mac is bound to an Active Directory, all local admin users will be downgraded unless listed in the excluded accounts setting. Admin By Request respects any group defined in the Directory Utility under “Allow administration by” and will not downgrade these users:
If no administrator groups are defined, the client will automatically grant administrator rights to members of the default Active Directory “Domain Admins” group. This is to prevent machines from ending up with no administrator accounts if the Active Directory binding is not setup correctly.
Sub-Settings
The portal has two levels of settings:
-
Mac Settings (also known as Global Settings) apply to all users by default, except those settings overridden under Sub Settings.
-
Mac 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 participating in the feature. You can overrule settings for listed 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.
For Macs, the feature is only available if the mac is bound to Active Directory or using NoMAD or Idaptive. Sub settings can also be used by specifying machine / user groups in the policy file. Refer to Portal Administration for Mac and Sub-Settings for more information.
Sudo
For security reasons, sudo access is disabled during administrator sessions by default. This can be enabled in the settings or a policy file (see Portal Administration for Mac). 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.
Machine Settings
You can use a local policy file to override all portal settings locally. Refer to Portal Administration for Mac for more information. Any setting defined in the policy file will override both default and sub settings. The policy file is locked during an Admin By Request administrator session, so users are unable to tamper with policy settings.
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.
