How to Troubleshoot Apple Platform SSO

Last updated 10/21/2025

This is Part 6 of 6 of the blog series on How to Configure Apple Platform SSO and will cover Troubleshooting. For reference here are the previous blogs:

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

This page will be organized by sharing troubleshooting steps that apply to all of the implementations, then it will break out into specific sections unique to each vendor implementation. Expect this page to be updated frequently as we tend to learn more with every implementation of this technology.

Universal Troubleshooting Tips

DO NOT Enable PSSO During Setup Assistant if you are running UEM Console 2506 Patch 10.

The UEM Console SSO Extension Profile Builder has a new set of keys that are supposed to support PSSO during Setup Assistant, a new feature as part of macOS 26. Unfortunately the UEM Console has not been updated to support these keys, so if turn them on, you will brick your macOS device during Setup Assistant. Omnissa is currently in development to add the missing UEM Console support for these new keys.

If you followed my previous tips of not using the profile builder and went with custom settings, congrats, but you will still need to remove these from your custom settings payload.

If you work with Omnissa tech support, you can have Omnissa tech support reference Jira MACOS-6620 for updates on this development work.
Does the SSO Extension Profile exist on the device? Validate this by looking at System Settings > Privacy and Security > Profiles. Verify there is an entry for the SSO Extension. Verify that the Hosts configuration matches the correct subdomains.
Did the SSO Extension Registration succeed? Verify this from Terminal by running:

pluginkit -m | grep -I auto-service-extension
Did the device complete registration? Verify this from Terminal by running:

app-sso platform -s

If the device registration was successful you should see a line reading
Device Configuration.registrationCompleted = true
and the Login Configuration Object should not be null

Troubleshooting Microsoft Entra ID

The Microsoft Company Portal app includes additional logging capabilities. Open the Company Portal app and choose the Company Portal Menu > Settings > then enable the checkbox “Turn on advanced logging.”
Enable debug log persistence, reproduce the issue then capture the data:

sudo log config --mode "level:debug,persist:debug" --subsystem "com.apple.AppSSO" sudo sysdiagnose

When you are finished, reset debug logging back to the default settings:

sudo log config --reset --subsystem "com.apple.AppSSO"

Additional troubleshooting documentation from Microsoft is available at https://learn.microsoft.com/en-us/entra/identity/devices/troubleshoot-macos-platform-single-sign-on-extension?tabs=macOS14

Troubleshooting Okta Desktop Password Sync

Okta Vanity URLs are not supported in the PSSO Profiles. You must configure the PSSO Profiles to use the actual Okta tenant name provided by Okta. An Okta vanity URL is when Okta creates a tenant named CustomerName.okta.com but an I.T. Administrator wants their end users to use login.customername.com. While many Okta services support Vanity URLs, PSSO does not and must be pointed to the original Okta tenant name.
The Okta Verify app stores its logs in the user’s home directory. You’ll need those logs to figure out what is going wrong if this breaks. Here are some steps to help track that down:

~/Library/Group Containers/B7F62B65BN.group.okta.macverify.shared/Logs/[com.okta.mobile *date--time*.log]

Run the following in Terminal to save a copy of the Okta Verify logs with a time stamp to the current user’s Downloads folder:

cp -R ~/Library/Group\ Containers/ B7F62B65BN.group.okta.macverify.shared/Logs ~/Downloads/OktaVerifyLogs_$ (date +%Y_%m_%d-%H%M)

It is also helpful to look for logs labeled with com.okta.mobile.auth-service-extension something