How to Configure Apple Platform SSO with Microsoft EntraID

Updated 11/07/2025

Introduction

This is Part 3 of a 6 Part blog series on How to Configure Apple Platform SSO using Workspace ONE UEM. This part focuses on how to configure PSSO with Microsoft EntraID. Omnissa has published a reference document for this configuration on Omnissa Techzone, which can be found here: https://techzone.omnissa.com/resource/configuring-macos-platform-sso-using-microsoft-entra-id-and-workspace-one-uem.

Part 1 – What is Apple Platform SSO

Part 2 – How to configure Apple Platform SSO for Kerberos with Microsoft AD or Microsoft Entra

Part 3 – How to configure Apple Platform SSO with Microsoft EntraID

Part 4 – How to configure Apple Platform SSO with Okta Desktop Password Sync

Part 5 – How to configure Apple Platform SSO with Omnissa Access

Part 6 – Troubleshooting

Pre-Requisites for Microsoft EntraID

As of August 13, 2025 Microsoft officially went General Availability with this feature. https://techcommunity.microsoft.com/blog/microsoft-entra-blog/now-generally-available-platform-sso-for-macos-with-microsoft-entra-id/4437424 but only for macOS 13, 14, and 15. The Microsoft page speaks to future updates for macOS 26 but as of November 2025 I’m not finding any additional documentation from Microsoft suggesting they are officially supporting macOS 26. Unofficially I think this just means Simplified Setup has not been completed and the existing methods work just fine.

The Workspace ONE UEM Console needs to be running 2506 Patch 6 and higher to use the built-in UEM Profiles for PSSO due to bugs that existed in all previously console versions. Any UEM console version lower 2506 Patch 6 will result in broken payloads due to bugs. That being said, to avoid existing bugs or possible future bugs I recommend not using the UEM Console’s GUI based profile builder. I recommend building the entire profile outside of UEM and then deploying it via UEM Custom Settings. More details on that down below.

In case you are not following this blog in order, a reminder that if your organization will continue to have Active Directory and EntraID, be sure to go back to Part 2 and implement the Kerberos configuration.

Configuration Summary

Modify the macOS Primary User in DEP Profile to include @ symbol
Add the Microsoft Company Portal app to Workspace ONE UEM as an app and as a bootstrap package then deploy to your devices.
Configure the SSO Extension Payload (Custom Settings recommended)
Configure a Login and Background Item Payload
Configure a Data Collection Policy
Optional: Configure Google Chrome’s Microsoft PSSO Add On
Optional: Configure UEM Freestyle Orchestrator Workflow to deploy all of the required components
Optional: Deploy a UEM Sensor to track progress

Step 1 of 8: Modify the Primary User in the Automated Device Enrollment configuration to include the @ symbol

This step is optional but recommended.

When a macOS device is at the login window, the only way for PSSO to be triggered is for the username to contain the @ symbol. During Setup Assistant you can set the Primary User Account to include the @ symbol. I suggest changing the Automated Device Enrollment profile to make the Primary User Account Username be the email address. Doing this will eliminate four for the steps from the workflow illustrated above.

In Workspace ONE UEM Console, to change the Primary User Account Username to be the email address, navigate to
Groups & Settings > All Settings > Devices & Users > Apple > Apple Business Manager > and edit your existing Profile then scroll all the way to the bottom to the Primary User account section.

Step 2 of 8: Add the Microsoft Company Portal app to UEM

The Microsoft Company Portal App must be installed on macOS to enable PSSO. There are two methods to install it: as a bootstrap package for net new devices, or as a UEM app, or both. In Part 1 we discussed macOS 26 Simplified Setup which allows PSSO setup During Setup Assistant. Simplified Setup will require the Company Portal to be deployed via Bootstrap, but if you remember UEM does not support Simplified Setup. What I am recommending here is that you deploy the company portal app as a bootstrap package for all of your new macOS devices to ensure it’s immediately available after Setup Assistant Completes so that PSSO device registration happens as soon as possible. You will not be using Simplified Setup with the bootstrap at this time, you’re just ensuring the app is available to use as soon as the device completes setup assistant. For existing devices, I also recommend adding Company Portal as a UEM app.

Download the latest version of the Microsoft Company Portal App from https://go.microsoft.com/fwlink/?linkid=853070
Run the app through the Workspace ONE UEM Admin Assistant Tool.
Add the Microsoft Company Portal app to Workspace ONE UEM as a Bootstrap package. Assign the app to a Smart Group targeting all macOS devices and set it to Auto Deploy.
Add the Microsoft Company Portal app to Workspace ONE UEM as a fully managed app. Assign this app to a Smart Group that targets all macOS device but change the assignment from Auto to Manual. This version of the app should not be auto deployed, but should be added to a Freestyle Workflow that will be covered later in this blog.

Step 3 of 8: Configure the SSO Extension Payload

Microsoft is advocating Secure Enclave is the way to go, but many organizations don’t want to give up password sync so they are going with the Password configuration. For both methods, there are dozens of configuration options to choose from when configuring the SSO Extension. Each setting has security implications for an environment that must be considered before deploying these payloads. Discuss these settings in detail with your security team to ensure security compliance with your specific device configuration requirements.

This blog is not going to explain or recommend which PSSO settings are needed for your organization, but it does include a known good sample configuration. The sample configuration below is based on Microsoft’s published reference guide which can be found here: https://learn.microsoft.com/en-us/intune/intune-service/configuration/platform-sso-macos.

So here’s the deal: I like a GUI and I like check boxes. Normally this is the point where you would open up the UEM console choose New Profile and start selecting check boxes. But the current UEM Profile builder is not cut out for complex Payloads like this one. Maybe one day that will change but for now just don’t do it. Instead, download and install the iMazing Profile editor from https://imazing.com/profile-editor.

Install iMazing, open the app, check for Manifest Updates to ensure you have the latest version of the payload installed and configure the “Extensible Single Sign-On” payload.

After completing the payload configuration in iMazing, save the configuration which will save as a MobileConfig File.

Now the bad news:

While it is possible to upload and deploy a mobileconfig file using UEM, doing so prevents editing the settings directly within the UEM console. I can’t stress enough that SSO payloads are the most frustrating payloads I’ve ever worked with and you will need to tweak them a lot during the initial build process. I recommend that you manually edit the MobileConfig File from iMazing, strip out the XML so that it becomes compatible with the Workspace ONE UEM Custom Settings Payload. There’s some black magic to this editing, so to help out with this, here is a sample of the code format that the Workspace ONE UEM Custom Settings Payload is looking for:

In this sample PSSO is configured to use Secure Enclave:

If you do copy and paste the example below change the PayloadUUID that is highlighted in red below. You can use https://www.uuidgenerator.net to create a new UUID :

		<dict>
			<key>AuthenticationMethod</key>
			<string>UserSecureEnclaveKey</string>
			<key>ExtensionData</key>
			<dict>
                                <key>Enable_SSO_On_All_ManagedApps</key>
				<integer>1</integer>
				<key>browser_sso_disable_mfa</key>
				<integer>1</integer>
			</dict>
			<key>ExtensionIdentifier</key>
			<string>com.microsoft.CompanyPortalMac.ssoextension</string>
			<key>PayloadDisplayName</key>
			<string>Extensible Single Sign-On #1</string>
			<key>PayloadIdentifier</key>
			<string>com.apple.extensiblesso.1D5BCE27-4838-4806-8D95-8BBB736E3E10</string>
			<key>PayloadType</key>
			<string>com.apple.extensiblesso</string>
			<key>PayloadUUID</key>
			<string>1D5BCE27-4838-4806-8D95-8BBB736E3E10</string>
			<key>PayloadVersion</key>
			<integer>1</integer>
			<key>PlatformSSO</key>
			<dict>
				<key>AuthenticationMethod</key>
				<string>UserSecureEnclaveKey</string>
				<key>EnableAuthorization</key>
				<true/>
				<key>EnableCreateUserAtLogin</key>
				<true/>
				<key>NewUserAuthorizationMode</key>
				<string>Standard</string>
				<key>TokenToUserMapping</key>
				<dict>
					<key>AccountName</key>
					<string>preferred_username</string>
					<key>FullName</key>
					<string>name</string>
				</dict>
				<key>UseSharedDeviceKeys</key>
				<true/>
				<key>UserAuthorizationMode</key>
				<string>Standard</string>
			</dict>
			<key>ScreenLockedBehavior</key>
			<string>DoNotHandle</string>
			<key>TeamIdentifier</key>
			<string>UBF8T346G9</string>
			<key>Type</key>
			<string>Redirect</string>
			<key>URLs</key>
			<array>
				<string>https://login.microsoftonline.com</string>
				<string>https://login.microsoft.com</string>
				<string>https://sts.windows.net</string>
			</array>
		</dict>

Now that you have edited the iMazing mobileConfig file to be compatible with UEM Console’s Custom Settings format, in the UEM Console Choose Add Profile > Apple macOS > Management Type Imperative, Context Device > Custom Settings > and paste in your code

If you are ignoring my advice to use the UEM Console Custom Settings Payload and are moving forward with the UEM Profile builder GUI, be aware that within the SSO Extension Profile builder at the bottom is a Custom XML section as seen in the screenshot below.

The Custom XML block is meant to include only additional XML that is part of the SSO Extension Data Dictionary. For example in Part 2 of this blog this is where the Kerberos domain substitutions are inserted. Step 5 and Step 6 of this blog include additional custom settings recommended but these are NOT to be added to the Custom XML section of the SSO Extension payload. Only use Custom XML within the SSO Extension payload if there is an Apple provided MDM key specific to SSO Extension that you do not find available in the profile builder GUI. In other words, don’t add the Microsoft Data Collection Policy or the Google Extensions to the SSO Extension Custom XML section.

Step 4 of 8: Configure Login Item Settings

When the Company Portal app is first installed on macOS it will prompt the user with a dialog box to allow it to run background items. This is unnecessary and can be skipped by configuring a Login and Background Item Payload. You can either create a brand new payload in UEM and only deploy the Login and Background Item Payload, or you can add the payload to the existing Custom Settings payload you built in Step 1. I prefer bundling the two.

Configure the following:

Rule Type = BundleIdentifier

Rule Value = com.microsoft.CompanyPortalMac

The result should look like:

Step 5 of 8: Configure Microsoft Data Collection Policy

Another prompt. from the Company Portal app will be displayed if you do not configure the Data Collection Policy. End users hate prompts so eliminate another one by configuring the Microsoft Company Portal App to not prompt for Data Collection.

Create a new dedicated payload in Workspace ONE UEM and add the following as a Custom Settings payload:

<dict>
	<key>AcknowledgedDataCollectionPolicy</key>
	<string>RequiredDataOnly</string>
	<key>PayloadIdentifier</key>
        <string>com.microsoft.autoupdate2.85AEB740-4739-47F8-A0FD-F98CA4F5C6B2</string>
        <key>PayloadUUID</key>
        <string>85AEB740-4739-47F8-A0FD-F98CA4F5C6B2</string>
        <key>PayloadOrganization</key>
        <string>Workspace ONE</string>
        <key>PayloadType</key>
        <string>com.microsoft.autoupdate2</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
        <key>PayloadDisplayName</key>
        <string>MSFT autoupdate</string>
        <key>PayloadDescription</key>
        <string>Settings for MSFT autoupdate</string>
</dict>

Step 6 of 8: Configure Google Chrome Browser Microsoft PSSO Extension

Apple’s PSSO plugin natively supports the macOS Safari web browser but will not work with 3rd party browsers like Google Chrome or Mozilla Firefox. To solve for this Microsoft has published a Google Chrome Browser Extension to enable PSSO within Chrome Browser. If your organization deploys Google Chrome Browser than this is a must have step:

Create a new payload in Workspace ONE UEM and configure Custom Settings:

<dict>
    <key>PayloadDisplayName</key>
    <string>Google Chrome Policies</string>
    <key>PayloadIdentifier</key>
    <string>com.google.Chrome.policy.forceinstall</string>
    <key>PayloadType</key>
    <string>com.google.Chrome</string>
    <key>PayloadUUID</key>
    <string>12345678-1234-1234-1234-1234567890ab</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
    <key>ExtensionInstallForcelist</key>
    <array>
      <string>ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx</string>
    </array>
  </dict>

Step 7 of 8: Build a UEM Freestyle Workflow

UEM delivers payloads and apps in non-sequential order. I recommend using Workspace ONE UEM Freestyle to sequence the order of operation, especially if you are deploying the Company Portal app to existing devices. By utilizing a Workflow UEM will force sequential installation order ensuring that this solution works as advertised.

I also have a second Workflow for installing Google Chrome Browser which includes the PSSO extension that is not pictured above.

Step 8 of 8: Deploy a UEM Sensor to track status

While optional, I think this is a useful step to complete.

In order to track the rollout and success of PSSO I recommend the following UEM Sensor be deployed which allows reporting back on the status of your PSSO rollout. I found this recommended out on the Internet somewhere and apologize for not remembering where I got it in order to credit the original author, but whoever wrote this I extend a thank you for sharing it:

#!/bin/bash

# Get the current logged-in user
currentUser=$(/usr/sbin/scutil <<< "show State:/Users/ConsoleUser" | /usr/bin/awk -F': ' '/[[:space:]]+Name[[:space:]]:/ { if ($2 != "loginwindow") { print $2 }}')

# Check if the user is valid
if [[ -z "$currentUser" ]]; then
    echo "<result>No user logged in</result>"
    exit 0
fi

# Check for Platform SSO status
pssoe_status=$(dscl . -read "/Users/$currentUser" dsAttrTypeStandard:AltSecurityIdentities 2>/dev/null | /usr/bin/awk -F'SSO:' '/PlatformSSO/ {print $2}')

# Error handling: If something goes wrong during the dscl or awk command
if [[ $? -ne 0 ]]; then
    echo "<result>Error retrieving PSSO registration</result>"
    exit 1
fi

# Determine the result based on the status
if [[ -z "$pssoe_status" ]]; then
    echo "<result>No PSSO registration found</result>"
else
    echo "<result>Yes, Entra ID account $pssoe_status registered to $currentUser</result>"
fi

Congratulations you are done with your Microsoft EntraID PSSO configuration!

Acknowledgments

My colleague, Simon Elberts, blogged about this topic over at https://blog.simonelberts.nl/2024/04/macos-platform-sso-with-workspace-one.html. A huge thank you to Simon for his work on this subject.