Admin By Request (ABR) manages privilege elevation on macOS by applying policies to users based on which group they belong to in the organisation's Identity Provider (IdP) - typically Microsoft Entra ID or Okta. To do that, ABR needs to know who is actually logged in to the Mac in corporate identity terms: not just the local macOS account name, but the user's corporate email address or User Principal Name (UPN) that the IdP recognises.

Platform SSO is Apple's solution for binding macOS login directly to a corporate IdP. When it is configured, the macOS login screen itself authenticates against Entra ID or Okta, and the OS stores the resulting identity in a system location that trusted applications can read. ABR reads that identity at the top of its lookup chain, before any application-based fallback is consulted. As long as the user has completed Platform SSO registration on their device, ABR gets a reliable, fresh UPN on every check - which in turn means Sub-Settings apply correctly and consistently.

This technical note explains what Platform SSO requires, how to configure it end-to-end for both Entra ID and Okta environments, how to verify that it is working, and what to do when it is not.

Applies to: macOS [Entra ID: ABR v5.1+, Okta: ABR v5.2+]

• Background: What is Platform SSO?

• How ABR uses Platform SSO - the identity lookup chain

• Entra ID vs Okta: an important difference

• Prerequisites

• Configuration

  • Step 1 - Deploy the Full Disk Access (PPPC) profile

  • Step 2 - Deploy the Extensible SSO (ESSP) profile

  • Step 3 - Verify the IdP selection

  • Step 4 - Deploy the ABR agent

  • Step 5 - Have users complete Platform SSO registration

• Verifying the configuration

• Common issues

• Diagnostic logs

Platform SSO is an Apple capability introduced in macOS 13 Ventura that allows the macOS login screen to authenticate against a corporate IdP rather than against a local password. Instead of the user typing in a password stored only on their Mac, the macOS login dialog hands the authentication challenge off to an SSO plugin - provided by Microsoft (for Entra ID) or Okta - which authenticates the user with the IdP and receives back an identity token. macOS stores that token in a system location and makes it available to applications that are registered as trusted consumers.

The mechanism that delivers the SSO plugin to a Mac is a configuration profile called an Extensible Single Sign-On Profile (ESSP). This profile is pushed to devices via Mobile Device Management (MDM) - Intune or Jamf in most ABR environments. Once the profile is installed and the user has completed the initial registration flow (which typically happens at their next macOS login), Platform SSO is active and the OS-level identity token is available.

ABR does not configure Platform SSO itself. There is no toggle for it in the ABR portal. ABR's role is to read the Platform SSO identity attributes exposed by macOS on the local user record. Whether a token exists depends entirely on the MDM configuration and on whether the user has completed registration.

Step 1 is setup, once per device and steps 2-7 run at every user login. By design, ABR never participates in authentication - it's a consumer at the end of the pipeline, not a participant.

When ABR needs to identify the currently logged-in user, it works through a fixed priority list of identity sources - called the identity lookup chain - and stops at the first source that returns a usable UPN. The chain, from highest to lowest priority, is:

1. Platform SSO - The OS-level identity token from the SSO plugin. Used when an ESSP profile is deployed and the user has authenticated through it. This is the most reliable source, because the OS holds the identity rather than any specific application.

2. Microsoft Intune Company Portal - The plist file written to disk when the user signs in to Company Portal.

3. Microsoft Outlook - The preferences file that Outlook writes when the user is signed in to their Microsoft account.

4. Microsoft Teams - The Teams settings file. Requires Full Disk Access because Teams stores its data in a sandboxed container.

5. Jamf Connect - Jamf's credential provider plugin, used in Jamf-only environments that do not have Microsoft applications installed.

ABR checks these in order and uses the first source that returns a non-empty UPN. This order is fixed - it cannot be changed by configuration.

Identity lookup is not the same as trust for MFA. Every source in the chain can supply a UPN that Admin By Request uses to look the user up. That does not make the UPN trusted for MFA Email match. In particular, signing in to Outlook or Teams lets those apps supply a UPN for lookup, but it does not make that UPN trusted for Email match.

From macOS client version 6.0, Email match needs a trusted identity tied to the local Mac user: either a registered Platform SSO identity, or a UPN verified through the Entra ID Connector. Platform SSO needs configuration and user registration, but no Entra ID Connector, for this purpose. See Platform SSO as an identity source for Email match.

ABR stops at the first source returning a UPN. Platform SSO is checked first - a returned UPN ends the lookup, but a registration with no UPN falls through to the next source.

Both Entra ID and Okta environments use the same Platform SSO mechanism described above. The configuration steps are nearly identical. However, there is a fundamental difference in what happens when Platform SSO is not working:

• Entra ID environments: Platform SSO is the preferred identity source, but it is not strictly required. If Platform SSO is not configured on a device at all, ABR falls through to Company Portal, Outlook, and Teams - all of which can supply an Entra ID identity. ABR can identify most Entra ID users without Platform SSO. Platform SSO makes this identification more reliable and consistent, but it is not mandatory.

  There is one exception, from macOS client version 6.0. MFA Email match does not trust a UPN supplied by Outlook or Teams. If you use Email match without the Entra ID Connector, Platform SSO is the only trusted identity source, so it becomes a requirement for those users.

• Okta environments: Platform SSO is an essential requirement. The entire fallback chain below Platform SSO (Company Portal, Outlook, Teams, Jamf Connect) consists of Microsoft and Jamf applications. None of them carry Okta identity data. If Platform SSO is not configured, or is registered but unauthenticated, ABR has no way to discover the user's Okta identity and cannot match any Okta-group-based Sub-Setting. The official product documentation states this explicitly: "It is a requirement for using the Okta Connector with Macs that users login to their Mac devices using Platform SSO."

This means that for Okta deployments, any gap in Platform SSO coverage - an ESSP profile not deployed to a device, a user who has not completed registration, an ESSP profile misconfigured without the ABR allow-list entry - results directly in users getting Global Settings with no fallback. The operational risk of a misconfigured or partially deployed Platform SSO is higher in Okta environments than in Entra ID environments.

The following table illustrates the differences:

Before starting configuration, confirm that all of the following are in place:

With ABR portal requirements, neither connector needs a separate macOS-specific configuration. Platform SSO is auto-detected by ABR at the device level - there is no toggle to enable it in the portal.

The configuration has five steps:

1. Step 1 - Deploy the Full Disk Access (PPPC) profile

2. Step 2 - Deploy the Extensible SSO (ESSP) profile

3. Step 3 - Verify the IdP selection

4. Step 4 - Deploy the ABR agent

5. Step 5 - Have users complete Platform SSO registration

ABR requires Full Disk Access (FDA) for macOS identity-related reads and application fallback sources. Platform SSO identity is resolved from local identity attributes and App SSO status metadata.

This example shows the App Bundle ID for the ABR System Extension in Jamf:

To verify that FDA has been granted on a device, go to System Settings > Privacy and Security > Full Disk Access on the Mac and confirm that both adminbyrequest and Admin By Request System Extension are listed with their toggles on:

This profile is what tells macOS to use Platform SSO and which SSO plugin to use (Microsoft's for Entra ID, or Okta's). It also controls which applications on the Mac are allowed to access the Platform SSO identity token - and this is where the most commonly missed configuration step lives.

The AppPrefixAllowList key in the ESSP profile is a whitelist of application bundle ID prefixes that are allowed to read the Platform SSO token. ABR's bundle IDs start with com.fasttracksoftware., so that prefix must be in the list. If it is missing, the Platform SSO token is available to other applications (including the SSO plugin itself) but not to ABR. ABR will then behave as if Platform SSO is not configured - falling through to application-based sources on Entra ID, or returning Global Settings on Okta.

In the Intune settings catalog policy, add these three keys under Extension Data. Key 1, the AppPrefixAllowList entry is the one customers most often miss - this is the key that lets ABR in (and don't forget the trailing period). Keys 2 and 3 are needed only for YubiKey and smartcard authentication and for Conditional Access policies that restrict login by operating system, as described above. Microsoft's own defaults are browser_sso_interaction_enabled = 1 and disable_explicit_app_prompt_and_autologin = 0.

Do the following:

1. In Jamf Pro, go to Computers > Configuration Profiles > New.

2. Add a Single Sign-On Extensions payload.

3. Add a new extension entry for the relevant IdP (Microsoft or Okta), using the Extension Identifier, Team Identifier and Type given above. Configure the remaining Platform SSO settings as described in Microsoft's or Okta's Jamf Pro guidance.

4. In the extension data / additional configuration section, add the key AppPrefixAllowList with string value com.apple.,com.microsoft.,com.fasttracksoftware. for Microsoft, or a value that includes com.fasttracksoftware. for Okta. If the key already exists, append to it.

5. Scope the profile to the target computer group and save.

Once ABR has the user's UPN from Platform SSO, it needs to use that UPN to look up the user's group memberships in the IdP. That lookup happens through (1) the Authentication tab and (2) the identity connector configured in the ABR portal.

In the portal, the Mac-side configuration that affects this is on the EPM macOS Authentication tab (under Mac Settings); the connector itself is managed in Tenant Settings and is shared across platforms.

There is no Platform SSO-specific toggle in the portal - ABR auto-detects Platform SSO from the device state.

On the EPM macOS Authentication tab, the Authentication Mode panel offers three mutually-exclusive options: Confirm, Multi-factor Authentication, and Authenticate. The Sign-on method and Email match settings that select the IdP for Platform SSO are only visible when Multi-factor Authentication is selected. If the tenant currently has Confirm or Authenticate selected, switch to Multi-factor Authentication first.

On the Authentication tab itself:

1. Log in to the ABR portal.

2. Navigate to EPM > Settings > Mac Settings > Endpoint > Authentication.

3. In the Authentication Mode panel, confirm Multi-factor Authentication is selected.

4. In the Multi-factor Configuration panel, confirm:

   • Sign-on method is set to the IdP you want ABR to use. The combo lists the SSO methods configured for this tenant (typically Microsoft 365 / Entra ID, plus any ADFS / Okta / SAML methods that have been added). A trailing "-- ADD NEW METHOD --" option opens a separate form for registering a new SSO method.

   • Email match is set per your matching policy (No matching / Email match / Account separation). See the on-tab About text for the semantic difference.

The Mac Authentication tab itself does not contain the Entra ID Connector or Okta Connector credentials (Client ID, Tenant ID, Client Secret, Okta URL, API token). Those are managed at a different portal location and shared across platforms.

Confirm with your portal administrator that the relevant connector is already configured and connected before proceeding to Step 4. If the connector is not yet configured, follow the standard ABR portal procedure for the relevant IdP:

• Entra ID: create an App Registration in Entra ID with Directory.Read.All Application permissions, then enter the resulting Client ID, Tenant ID, and Client Secret in the ABR Entra ID Connector page.

• Okta: create a token in the Okta Admin Console (Security > API > Tokens > Create token; copy the value at creation time as it is only displayed once), then enter your Okta tenant URL and the token in the ABR Okta Connector page.

Refer to Tenant Settings > Identity for more information on configuring IdP Connectors.

For your Sign-on method to appear in the dropdown list, configure it at Entra ID Single-Sign-on or Okta Single-Sign-on, depending on your environment. This example shows Okta-Endpoint-SSO (Okta) - a name that was created during the configuration procedure:

Deploy the ABR Mac PKG file to devices via MDM only after Steps 1 and 2 are confirmed as complete on target devices. The PKG is available for download from the ABR portal under the macOS installation section. It is tenant-specific: signed with your tenant's licence key - and should not be shared with other organisations.

Confirm that the PPPC profile (Step 1) and ESSP profile (Step 2) show as successfully installed in your MDM before pushing the agent. If the agent arrives before the PPPC profile, Full Disk Access will not be in place when the agent first starts and ABR will log an FDA error. Although the PPPC profile will eventually be installed later, FDA may not be recognised until the device is rebooted.

For the broader MDM deployment picture - including the SRA companion mobileconfig, package signing notes, and Jamf-side policy construction - see Multiple endpoint installation in the install docs.

Deploying the ESSP profile is not the same as completing Platform SSO registration. The profile tells macOS how to use Platform SSO, but the user's identity token does not exist until the user has actually authenticated through the Platform SSO flow at least once on that device.

On newly enrolled Macs, registration typically happens the first time the user logs in at the macOS login screen after the ESSP profile is deployed. The macOS login screen may present a different prompt than usual - asking the user to sign in with their corporate credentials rather than their local password.

The most reliable way to trigger and confirm registration is via Company Portal:

1. Open Microsoft Company Portal on the Mac and sign in with Entra ID credentials if not already signed in.

2. Watch for a "Registration required" notification in macOS Notification Centre. Click it if it appears and follow the sign-in and MFA prompts.

3. After completing registration, click "About Admin By Request" in the ABR menu bar icon to trigger an immediate identity sync.

1. Log out of macOS and log back in. If the ESSP profile is correctly installed, the macOS login dialog should be backed by Okta. Log in with Okta credentials and complete any MFA required by your Okta policy.

2. After logging in, click "About Admin By Request" in the ABR menu bar icon to trigger an immediate identity sync.

After completing all five configuration steps, confirm that everything is working before rolling out to additional devices.

1. Check the Groups tab in portal Inventory. In the ABR portal, go to Inventory and open the record for a target device. If Platform SSO is active and the identity connector is working, a Groups tab will appear in the device record, listing the IdP group memberships that ABR has collected for that device. If the Groups tab is absent entirely, ABR has not been able to collect any group data - something in the configuration chain is broken.

2. Check the Sub-Settings match view. Navigate to the Sub-Setting that should apply to your test user and open the "Who matches this sub-setting?" view. Confirm that the expected device or user appears in the list.

3. Trigger a manual sync if needed. ABR caches group membership data and refreshes it on a four-hour automatic cycle. To verify immediately without waiting, click "About Admin By Request" in the ABR menu bar icon on the test device. This triggers an immediate identity check and group lookup.

4. Test an elevation. Request an elevation on the test device (for example, try to run an installer that requires admin rights). Confirm that the elevation request is handled according to the Sub-Setting that should apply to that user, not according to Global Settings.

The following issues are recorded here:

• AppPrefixAllowList missing from the ESSP profile

• Platform SSO registered but user not yet authenticated

• Full Disk Access not granted

• ESSP profile configuration errors

• Platform SSO artifacts persist after profile removal

• New combined EPM mobileconfig deployed over old separate profiles

• [Okta only] v5.2.0 and v5.2.1 - device groups fail when HostName and NetBIOS name differ

Symptom:

Platform SSO appears to be working for other applications (for example, the user can sign in to macOS with their corporate credentials), but Sub-Settings are not applying correctly in ABR. The Groups tab in portal Inventory is absent or incorrect. There is no ABR log entry that specifically identifies this as the cause.

Cause:

The ESSP profile does not include com.fasttracksoftware. in the AppPrefixAllowList. macOS restricts access to the Platform SSO identity token to applications whose bundle ID prefix appears in this list. Without the entry, the token is inaccessible to ABR. On Entra ID environments, ABR will fall through to the application-based sources (Company Portal, Outlook, Teams). On Okta environments, identity resolution fails entirely.

Fix:

1. Open the ESSP configuration profile in your MDM.

2. Locate the Additional configuration or Extension Data section.

3. Add the key AppPrefixAllowList with string value com.fasttracksoftware. (including the trailing period). With Microsoft's SSO extension, use com.apple.,com.microsoft.,com.fasttracksoftware. so the plug-in's default prefixes are kept. If the key already exists, append to its value rather than adding a second key, and add it to the existing SSO profile rather than a new one. See Step 2 - Deploy the Extensible SSO (ESSP) profile.

4. Save the updated profile and push it to devices. The change takes effect on the next MDM sync.

Symptom:

Users are getting "Admin Session denied by policy" or landing on Global Settings despite being in the correct Entra ID or Okta group. The ABR diagnostic log contains a message like:

Entra ID UPN - macOS Platform SSO enabled, but user has not authenticated

Cause:

ABR can see that Platform SSO is registered on the device (the ESSP profile has been deployed and macOS has processed it) but the user has not yet completed the authentication flow that creates the identity token. Platform SSO therefore returns no UPN, and Admin By Request continues down the identity lookup chain. The user ends up on Global Settings when none of the later sources supplies a UPN either: always on Okta, and on Entra ID when the user is not signed in to Company Portal, Outlook or Teams. This is the most common issue seen immediately after deploying Platform SSO to a Mac fleet.

Fix:

For Entra ID:

1. Open Microsoft Company Portal and sign in.

2. Look for a "Registration required" notification in macOS Notification Centre and follow any prompts.

3. After completing registration, click "About Admin By Request" in the menu bar icon to sync immediately.

For Okta:

1. Log out of macOS and log back in using the Okta-backed login screen.

2. Complete any MFA prompted by Okta.

3. Click "About Admin By Request" to sync.

Symptom:

Sub-Settings are not applying and the ABR diagnostic log contains a message like:

Entra ID UPN - macOS Platform SSO enabled, but Full Disk Access not enabled

Cause:

The PPPC profile granting Full Disk Access to ABR was not deployed before the ABR agent, or was deployed but not recognised by macOS until after a reboot. ABR cannot read identity data without FDA.

Fix:

1. On the affected Mac, go to System Settings > Privacy and Security > Full Disk Access.

2. Check whether both adminbyrequest and Admin By Request System Extension appear in the list. If either is missing, the PPPC profile is incomplete - FDA is required on both the main executable (path /Library/adminbyrequest/adminbyrequest) and the System Extension (bundle ID com.fasttracksoftware.adminbyrequest.extension), as in the shipped profile. If either appears but its toggle is off, the profile may be present but not correctly enforced.

3. Verify in MDM that the PPPC profile is assigned to and installed on this device.

4. If the profile is present but FDA is still not applied, reboot the device. macOS sometimes requires a reboot to pick up FDA grants from MDM profiles.

5. On macOS 26.1 or 26.2, if you need to add FDA entries manually as a workaround, drag-and-drop the binary from Finder rather than using the privacy-settings picker (the picker can fail to list binaries on those OS versions; fixed in 26.3).

Symptom:

The ABR diagnostic log contains one or more messages such as:

• [AppSSO] JSON parsing error for Device Configuration: The data couldn't be read because it isn't in the correct format.

• [AppSSO] JSON parsing error for Login Configuration: The data couldn't be read because it isn't in the correct format.

• [AppSSO] No extensionIdentifier/accountDisplayName found. Exiting early.

Cause:

ABR cannot read the ESSP profile configuration at all. This is distinct from the "user has not authenticated" error - it means the configuration profile itself is broken or absent, not just that the user has not registered. Common causes include:

• The ESSP profile was not assigned to this device in MDM (check the assignment scope).

• The profile extension data contains a syntax error.

• For Okta: Okta Verify, which provides Okta's Platform SSO extension, is not installed on the Mac.

• A conflict with another ESSP or SSO configuration profile on the device. For example, an older Intune Device features SSO app extension profile still assigned alongside a settings catalog Platform SSO policy (Microsoft error 10002: multiple SSOe payloads configured).

Fix:

1. In your MDM, confirm that the ESSP profile is assigned to this specific device and that its status is successful (not pending or failed).

2. Review the profile's extension data configuration for syntax errors.

3. For Okta: confirm that the Okta device management app components are installed and running on the Mac.

4. Check whether any other SSO-related profile is deployed to this device that might conflict.

Symptom:

A device was removed from the Platform SSO ESSP profile (for example, a device was taken out of an Intune group during or after a pilot). Even after removal, ABR still behaves as if Platform SSO is registered - it looks for a token, cannot find one (because the user has not re-authenticated since PSSO was removed), and continues down the identity lookup chain. The user gets Global Settings when no later source supplies a UPN: always on Okta, and on Entra ID when the user is not signed in to Company Portal, Outlook or Teams.

Cause:

Platform SSO registration data is written into the device's keychain and OS configuration state when it is first set up. Removing the ESSP profile from MDM does not automatically clean up this data. ABR still detects the device as having Platform SSO registered, but no token is available, so Platform SSO returns no UPN.

Fix:

Per Microsoft's guidance, the intended resolution is to reset the Company Portal app state and clean the relevant keychain entries. However, in practice, support teams have found this cleanup unreliable - the Platform SSO configuration is often too deeply embedded in the device state to fully remove without a wipe. The most dependable resolution is to wipe and re-enroll the device.

Symptom:

After switching from the older pair of mobileconfigs (AdminByRequest - FDA PPPC_v2.mobileconfig and AdminByRequest - System Extension.mobileconfig) to the new combined Admin By Request - EPM.mobileconfig, devices show unpredictable behaviour: Full Disk Access may not register, the System Extension may show as not approved, or both states may flap. ABR cannot reliably read the Platform SSO token, and Sub-Settings stop applying.

Cause:

The new combined Admin By Request - EPM.mobileconfig consolidates what the two older profiles did. When it is pushed to a device that still has the old profiles installed, macOS sees overlapping PPPC and System Extension payloads from different profiles and the resulting state is not deterministic.

Fix:

1. In your MDM, remove the assignments for AdminByRequest - FDA PPPC_v2.mobileconfig and AdminByRequest - System Extension.mobileconfig from the target Mac group and confirm both have been uninstalled from devices.

2. Once the old profiles are gone, push Admin By Request - EPM.mobileconfig to the group.

3. Verify FDA in System Settings > Privacy and Security > Full Disk Access and the System Extension approval in Login Items and Extensions on a sample device.

Do not deploy the new combined profile on top of the old ones - delete the old ones first.

Symptom:

After upgrading Mac agents from v5.1.x to v5.2.0 or v5.2.1 in an Okta environment with Platform SSO active, device-group-based policies stop applying. The Groups tab in Inventory shows "No data to display" on upgraded devices. The same devices showed groups correctly on v5.1.x. Windows devices on the same tenant are not affected.

Cause:

A bug in ABR Mac v5.2.0 and v5.2.1 caused device group resolution to fail when the device's HostName and NetBIOS name did not match exactly. This affected environments that used computer groups in Global Scope or Sub-Settings with Platform SSO active.

Fix:

Upgrade the Mac ABR agent to v5.2.2 or later. The fix checks both HostName and NetBIOS name formats when resolving device group membership.

When investigating Platform SSO issues, ABR's diagnostic logs are the fastest way to identify which part of the configuration chain has failed. Log entries from the AppSSO layer will tell you whether the ESSP profile is absent, misconfigured, or present-but-unauthenticated.

Two ways to access the logs:

1. macOS Console app: Open the Console app on the affected Mac and navigate to Log Reports > adminbyrequest.log.

2. In-app diagnostics submission: Click "About Admin By Request" in the ABR menu bar icon and select Diagnostics > Submit. This sends the logs directly to the ABR support team, which is useful when a customer is submitting a support ticket.

Key log patterns: