How to Configure Apple Platform SSO with Microsoft EntraID

   September 29, 2025  2 Comments on How to Configure Apple Platform SSO with Microsoft EntraID  Posted in Workspace ONE 0 Likes 32 Views

Updated 09/29/2025

Introduction

This is Part 2 of a 5 Part blog series on How to Configure Apple Platform SSO using Workspace ONE UEM.

Part 1 – What is Apple Platform SSO

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

Part 3 – How to configure Apple Platform SSO with Okta Verify

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

Part 5 – 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. macOS 26 has been released by Apple but Microsoft has not updated their app to support this new OS.

I am not covering the Identity Provider configuration steps, which are also a pre-requisite to be in place BEFORE attempting to deploy these profiles. You should consult your current IdP vendor documentation for the specific server side configurations required to enable SAML based authentication with your IdP. SAML based authentication with an IdP is a pre-requisite to everything being described below.

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. To avoid existing bugs or possible future bugs I recommend not using the GUI profiles provided by Omnissa but instead using Custom Settings to deploy the payloads.

If your organization needs support for Kerberos via Active Directory, or Kerberos via Microsoft EntraID this will still be possible. Checkout my blog on this additional configuration you will need to achieve this:

https://www.aftersixcomputers.com/apple-platform-sso-kerberos/

Configuration Summary

  1. Modify the macOS Primary User in DEP Profile to include @ symbol
  2. Add the Microsoft Company Portal app to Workspace ONE UEM as app and as a bootstrap package then deploy to your devices.
  3. Configure the SSO Extension Payload (Custom Settings recommended)
  4. Configure a Login and Background Item Payload
  5. Configure a Data Collection Policy
  6. Optional: Configure Google Chrome’s Microsoft PSSO Add On
  7. Optional: Configure UEM Freestyle Orchestrator Workflow to deploy all of the required components
  8. 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

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

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 both a fully managed app and also as a Bootstrap package. The Bootstrap package should be used for all new deployments, and the fully managed app should be triggered as part of a Freestyle Workflow for existing devices.

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 settings are needed for your organization, but it does include known good sample configurations. 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, and 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, 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 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. What you need to do next is manually edit the MobileConfig File, strip out the XML so that it becomes compatible with the Workspace ONE UEMCustom Settings Payload. Then in the UEM console create a new Profile, Choose custom Settings, and copy and paste the Payload. There is some black magic associated with editing these things so if you’ve never done it before, here’s a working sample for you to reference:

Secure Based Enclave profile:

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>

Step 4 of 8: Configure Login Item Settings

To hide what I would consider an unnecessary prompt from the end user, add a Login and Background Item Payload. Note that you can either create a brand new payload in UEM, or you can add this to the existing Custom Settings payload you built in Step 1.

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

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>

Congratulations you are done with your Microsoft PSSO configuration!

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. By utilizing a Workflow UEM will force sequential installation order ensuring that this solution works as advertised.

Note that I also have a second Workflow for installing Google Chrome Browser which includes the PSSO extension.

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

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

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.

Next Steps

With the configuration out of the way the next step would be to review Part 5 for some tips on troubleshooting.:

Part 1 – What is Apple Platform SSO

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

Part 3 – How to configure Apple Platform SSO with Okta Verify

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

Part 5 – Troubleshooting