How To Configure Apple Platform SSO using Omnissa Workspace ONE UEM

   March 8, 2025  Leave a Comment on How To Configure Apple Platform SSO using Omnissa Workspace ONE UEM  Posted in Workspace ONE 0 Likes 187 Views

What is Apple Platform SSO?

The Apple Platform SSO (PSSO) Framework extends the macOS login window to allow users to synchronize local account credentials with an identity provider (IdP). Management of the macOS local account credential includes support for multiple authentication methods and replaces the need for binding macOS to Microsoft Active Directory. PSSO replaces previous Apple technologies that have attempted this in the past including Apple Enterprise SSO, Apple Kerberos SSO, and Apple LDAP Bind. In some cases it even replaces Jamf Connect and Xcreds. In short:

MDM + SSO Extension + IdP Plugin + Apple macOS 13.x or higher and PSSO is enabled.

While Apple considers the feature generally available and functional, they continue to fix bugs with it with each macOS release. The IdP’s are still in active development as are the MDM’s. The point here is that despite being available from Apple for a few years now, this technology is all still a work in progress.

Okta is the only IdP that has a shipping/generally-available/not-beta/not-tech preview version of this technology. Microsoft and Omnissa are still working on their versions, with the Microsoft version available in Tech Preview and so far is the one that I see being asked about the most. I’ll cover each of these vendor methods below, but I am going to skip a lot of the background. If you want to understand PSSO in more technical detail I recommend the following one-hour introduction by Michael Epping and Mark Morowczynski:

If you want an even more in-depth understanding than this second one-hour video by Joel Rennich https://youtu.be/mkro_6BzOiY?si=ZOf5mXKMkZ8GHvqm is well worth your time.

A third one-hour deep-dive on the technology is https://youtu.be/xwgBofPoZJU?si=R1yLFU-mtMUO1suo.

PSSO is available for use as part of the macOS Login window and then used by applications for SSO. The framework supports user creation at the login window, tokens at the login window, and authorization database integration.

PSSO is NOT passwordless authentication for FileVault or macOS. Existing FIDO2 / Yubikey / Feititian / Titan users will not be replacing these methods with PSSO.

Configuration Details

The first task for the I.T. Admin is to pick one of the four IdP based user authentication options supported by PSSO:

  1. Password and encrypted password.
    In this mode the IdP uses the local account password and keeps it in sync, including password updates from the login window and screensaver unlock
  2. User Secure Enclave Key.
    In this mode the Secure Enclave-backed key is used to authenticate with the IdP without a password and without changing the local account password. Key point: There is NO password sync between the macOS local account password and the IdP password.
  3. SmartCard.
    In this mode the SmartCard is used to authenticate with the IdP
  4. Password with WS-Trust.
    A federated IdP, meaning an IdP that facilities federated authentication across multiple security domains, can use the local account password for authentication.

There are some important caveats to be aware of when choosing which to implement:

  • If User Secure Enclave Key is used, let me repeat this: there is no password synchronization between the local macOS Account password and the IdP password
  • If User Secure Enclave Key is used, MFA is not available at the macOS login screen
  • MFA for FileVault is not supported with any authentication option
  • When using Password, the IdP can NOT push password changes to the device. All password changes must be initiated from macOS and password changes are synced at 4-hour intervals when the user is logged in

Another configuration option for PSSO is the able to create a new user at the macOS Login window. This includes the ability to add or remove users from Groups as part of the creation step. I had hoped this would allow the MDM to understand multi-user logins and adjust device registration according to who just logged in, but this is not the case so if you do enable new user creation and allow multiple users to login to the same macOS device do keep in mind MDM registration remains with the original user and MDM has no understanding of whatever new user logged into the device.

Finally the most important detail that gets overlooked about PSSO:

PSSO DOES NOT enable zero-touch onboarding.

That’s right, folks! PSSO is NOT part of Apple Business Manager Automated Enrollment (aka DEP). PSSO is turned on AFTER Setup Assistant is complete and after MDM Enrollment has finished. While PSSO is not zero-touch, there are a few tweaks to the DEP Profile I’ll show you to make the process a bit easier on your end users.

If you are ready to dig into the configuration and some tips on making it work keep reading.

PSSO Configuration consists of the following steps:

  1. Modify Primary User in DEP Profile to include @ symbol (optional, but highly recommended)
  2. Add IdP-Plugin to UEM as an app
  3. Add IdP-Plugin to UEM as a bootstrap package
  4. Configure SSO Extension Payload
  5. Configure Login and Background Item Payload
  6. Configure UEM Freestyle Orchestrator Workflow to deploy (in sequenced order) the IdP-Plugin, the Background Item Payload and the SSO Extension Payload (optional, but highly recommended)

Note: I am not covering the Identity Provider SAML configuration steps, which are a pre-requisite. 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 in this blog.

PSSO Apple macOS Device Registration Process

Here is the high level summary of what happens on the macOS device in order to configure PSSO:

As you can see from the steps above, there are a lot of moving parts and end user prompts and a lot that can break so I wanted to share a few tips to improve your chance of success when rolling this out.

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 DEP profile to make the Primary User Account Username be the email address. This will save your end user from four of the steps outlined above because it will complete the macOS Setup Assistant with a local user account that already contains the @ symbol.

To change the Primary User Account Username to be the email address, in Omnissa Workspace ONE UEM (UEM) navigate to
Groups & Settings > All Settings > Devices & Users > Apple > Device Enrollment Program (or Apple Business Manager if you have the new GUI) and edit your existing Profile then scroll all the way to the bottom to the Primary User account section.

The next step is to choose the IdP-Plugin app that will be used with PSSO. The options are:

  1. PSSO with Okta Device Access using the Okta Verify App
  2. PSSO with Omnissa Workspace ONE Access using the Intelligent Hub App
  3. PSSO with Microsoft EntraID using the Microsoft Company Portal App

I recommend uploading the IdP-Plugin in to UEM as both a Bootstrap Package AND as a fully-managed App (set to Optional deployment and published via UEM Freestyle Orchestrator). Having both available ensures that the IdP-Plugin is ready to go for new devices running through Setup Assistant and for existing devices that will be available as part of a Freestyle Workflow.

Let’s dig into the 3 current IdP-Plugins:

PSSO with Okta

For PSSO with Okta, this is the ONLY method of the three above that is considered a fully-shipping, fully supported, and fully-working configuration by each vendor involved. Okta customers will need to purchase a license to use this feature. Currently it is available through the Okta Device Access SKU which includes Okta’s Desktop MFA for macOS and Okta Desktop Password Sync. Okta has implemented Platform SSO in the Desktop Password Sync app which relies on the Okta Verify App.

The technical configuration is fully documented over on Omnissa’s Techzone so I will not be repeating it here. If this is your path forward follow my advice above for tweaking your ABM flow, then follow the instructions here: https://techzone.omnissa.com/resource/configuring-macos-platform-sso-using-okta-and-workspace-one-uem to complete the configuration. When you are done come back to this blog and scroll down to the Additional Tips section below.

PSSO with Omnissa Workspace ONE Access

For PSSO with Workspace ONE Access this is in active development so I will not be covering it for now, but I will come back and update this blog once this version hits the market. I will share that it currently works exactly like PSSO with Microsoft EntraID but uses the Intelligent Hub app, so learning how the Microsoft implementation works will be helpful.

PSSO with Microsoft EntraID

This leaves us with PSSO with Microsoft EntraID using the Microsoft Company Portal App. This method has been delayed several times from going general availability by Microsoft and is currently still in Microsoft Technical Preview. Microsoft has a lot of documentation available which I found to be confusing. I am excited that my colleague, Simon Elberts, blogged about the basic setup. His blog includes the bare minimum config, but there are a number of additional configuration options I recommend that are missing from his blog. I recommend heading over to his blog and completing those steps, then come back here for filling in some of the gaps. His blog is located here: https://blog.simonelberts.nl/2024/04/macos-platform-sso-with-workspace-one.html

For existing devices, Freestyle Orchestrator should be used to enable PSSO such that the IdP-App is installed first, followed by the SSO Extension Profile and any additional configuration options that I will be covering below.

Assuming you have followed Simon’s blog to complete the configuration here are the additional items I recommend implementing.

Add Company Portal App to UEM

The first tweak to make from Simon’s blog is to make sure you have added the Microsoft Company Portal app to 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. I’ll talk more about the Freestyle Workflow after the other items below are configured.

Configure Login Item Settings

The second tweak to make from Simon’s blog is to add a new Profile in UEM (or add this to your SSO Extensions payload) and choose the Login and Background Item Payload. Configure the following:

Rule Type = BundleIdentifier

Rule Value = com.microsoft.CompanyPortalMac

The result should look like:

Configure Microsoft Data Collection Policy

The third tweak is for configuring the Microsoft Company Portal App to eliminate a user prompt. Out of the box the Microsoft Company Portal app will trigger a Data Collection dialog box that the user will need to read and accept. You can automate accepting these terms and skip this step by adding the following Custom Settings Payload to UEM

<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>

Switch to Custom Settings Payload

Another tweak to Simon’s steps is based on the fact that the current UEM SSO Extensions Payload is missing a number of available configuration attributes. Simon’s blog covers what I would call the basic config, but if you want to introduce a few more features to your rollout, you’ll need to move to a Custom Settings payload in UEM as the current Profile builder does not include many of the options available to configure.

If you are coding impaired like me, build the profile visually in a 3rd party app named iMazing Profile editor to make sure you have everything you want to configure. This app is available for download from https://imazing.com/profile-editor. The iMazing Profile editing tool includes the complete SSO Extensions payload with all of the available options and it provides detailed documentation for each available option making it much easier to understand what each options does.

The downside to this approach is that you have to jump through a few more hoops to use the resulting configuration file in UEM. The iMazing app saves its output as a MobileConfig file. While it is possible to upload the file to UEM and deploy it as a MobileConfig file, you lose the ability to edit the payload. I find it more flexible to edit the Mobileconfig XML into a compatible Custom Settings Payload then deploy the Custom Settings Payload in UEM. The end result will look like the following, though if you do copy and paste my example change the PayloadUUID:

		<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>

Build a UEM Freestyle Workflow

UEM delivers payloads and apps in non-sequential order. By utilizing a Workflow UEM will force sequential installation order. In the example below I have combined the Login Item payload with the SSO payload (Step 4).

Additional Tips

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 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