How to Troubleshoot Apple Platform SSO

Last updated 12/13/2025

Introduction

This is part six of a six part blog series on how to configure Apple Platform SSO using Omnissa Workspace ONE Unified Endpoint Management (UEM). Each part of the blog covers the various vendor configuration options and the series wraps up with a blog dedicated to troubleshooting. As each vendor continues to change their implementation these blogs will be updated.

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 any version of UEM Console 2410/2506/2509.

The UEM Console SSO Extension Profile Builder has a new set of keys that are supposed to support PSSO during Setup Assistant. Apple refers to this new feature as Simplified Setup and it’s available in macOS 26.x. The UEM Console profile editor was updated to include the new keys, but there is additional code required on the UEM Console that prevents the keys from being functional. If you turn them on in the profile builder, you will brick your macOS 26 device device during Setup Assistant. Omnissa is currently in development to add the missing UEM Console support for these new keys.

If you followed this blog series and are using custom settings make sure you do not include either of the keys. If you are using the UEM Profile builder for the SSO Extension payload, here is a visual of the configurations I’m referring to:

If you work with Omnissa tech support, you can have Omnissa tech support reference Jira MACOS-6620 for updates on this development work.
Just because Apple includes a configuration key in their PSSO Extension does not mean the key is supported by the iDP. An example of this is that PSSO includes keys to create and configure new users on devices, including which Groups the user should be a part of. Microsoft has not written their PSSO extension to support this option. The expected behavior is that keys that are not supported by the iDP should be ignored, but sometimes it’s best to completely remove them from the profile.
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
From the macOS device launch Terminal and run su klist. This tool will show which Kerberos tickets exist and are in use for all PSSO auth requests.
How do you turn off PSSO?

The answer mostly depends on which IDP plugin is in use, and if the method of auth is Secure Enclave or Password Sync. SecureEnclave is relatively simple to remove, but Password Sync is a bit tricker. In most instance it is usually faster to wipe the device than it is to manually remove PSSO completely. It is not enough to simply remove the MDM profile to truly reset things. That said here’s one set of recommended steps to attempt manually wiping out the PSSO configuration to get the device back to a clean state.

From Terminal run app-so platform -s and make note of the current configuration.

In UEM remove the PSSO profile from the device. Back on the macOS device, confirm that the profile has been removed from Settings > General > Device Management (For older MacOS devices you may find these under Privacy & Security > Profiles.)

Ensure ALL SSO extension profiles, including credential extensions, have been removed. If any remain, macOS will NOT remove the registration.

Use MDM to uninstall the IDP plugin App. Note this is not an option for Omnissa Hub, only attempt this if you are using Okta or Microsoft as the IDP.

Restart the device.

Verify the PSSO registration has been removed by using the terminal command app-sso platform -s to compare the current state to the state you recorded back in step one. If things worked properly most of the records should be deleted from the device.

If a device record exists in the IDP now would be a good time to delete it.

If you are using Password Sync, this gets a bit dicey because the the password you have in the IDP has been applied to the MacOS user, so when you log in again, it is the IDP password that needs to be supplied, not the original MacOS user password.

After removal, in case the local password is no longer accepted on the Lock Screen it may be because the user account has been modified. Possible remediation steps for this would be to login to macOS as a different account then from Terminal run:

dscl . delete /Users/username AltSecurityIdentities "$( dscl . read /Users/username AltSecurityIdentities | grep 'PlatformSSO:' | awk '{ print $NF }' )" (make sure dscl . read /Users/username AltSecurityIdentities | grep 'PlatformSSO:' contains something first)

Next run the command

dscl . delete /Users/username dsAttrTypeNative:PlatformSSOUniqueIdentifier

The AltSecurityIdentities entry must be like that as deleting AltSecurityIdentities will break the user account.

As stated at the beginning of this tip, wiping the device and starting over is usually faster and less error prone.

Troubleshooting Microsoft Kerberos

Does it work? Here is a summary of the areas to focus troubleshooting on:

Focus Area	Expected Behavior
Platform SSO	Auto login to Entra, Entra apps SSO works
Kerberos SSO	TGT acquired on demand, renewals automatic
Browsers	Safari/Chrome send SPNEGO to AD and EntraID apps
Apps	Microsoft Office apps installed on device auto-auth without prompting
Ticket Cache	Cloud TGT and AD TGT and Service Tickets all exist
Reliability	Does it work after reboot? Does it work if Wifi network changes? How does it handle renewals?
Failure Behavior	Predictable 401s and recoverable login paths

Most of the troubleshooting recommendations below should be handled directly on the affected macOS Device.

Confirm the UEM Profile installed. From the device reference System Settings > Device Management > Profiles. Open the profile and confirm the payloads match was is configured with no “invalid configuration” messages
Verify Platform SSO Status from Terminal by running app-so platform -s
Expected results would be a Status Signed In, the identity matches your UPN/Email address and the Authentication Method should confirm Secure Enclave or Platform Key
What does the Kerberos ticket show? Run the Terminal command klist which will show the available Kerberos tickets. Note that if your user is a standard user they might not see anything from this command. Use su to elevate the request. Look for a TGT from the online provider configured, for example krbtgt/KERBEROS.MICROSOFTONLINE.COM@KERBEROS.MICROSOFTONLINE.COM
Testing for KGT ticket retrieval involves first requesting a ticket, downloading the ticket and then have macOS register that the ticket exists to use during the next round of auth. One method to test this is to identify the URL of an internal website that requires Kerberos.

Open Safari and enable the Developer Menus by navigating to Settings > Advanced Tab > Check the box “Show features for web developers” > Close Settings page

Open the Develop Menu > Choose Web Inspector.

Type in the URL of the test website. If the page loads a TGT ticket should have been generated and you can proceed to the next step, but if you receive an error message such as a 401, examine the Web Inspector window and look at the Headers tab. You should see “Authorization: Negotiate <token> present. If it’s a webserver running Microsoft IIS a response code of 200 OK is what you should see.

After confirming a 200 OK message, back in Terminal run klist and there should now be 2 entries: a TGT for one for EntraID and a Service Ticket matching HTTP/ for the website you just visited.

If IIS is the backend webserver the IIS W3SVC logs should also contain an entry for the username that matches the format DOMAINNAME\USERNAME with no error messages.
Test TGT refresh, aka token renewal by locking the macOS screen then waiting 2 minutes. Upon unlock run su klist and the TGTs displayed should have a new auth time on them and no user prompts should have happened.
When Kerberos can not establish a connection to the Domain Controller new tickets can not be generated and internal sites should return 401 errors.
How is the Realm Preference being handled? In Terminal run su app-so configuration list
The Kerberos Extension should show up as com.apple.AppSSO.KerberosExtension
The PSSO Extension should show up as com.apple.AppSSO.PlatformSSO
Verify that Hosts and Realms must not overlap

Troubleshooting Microsoft Entra ID

In the configuration samples provided with the previous entries in this blog, PSSO is configured to be enabled for all installed apps and specific websites like https://login.microsoftonline.com. For troubleshooting it’s best to start with Safari, then the Microsoft 365 apps, then 3rd party applications to help isolate where the problems are.

Begin by answering these questions:

Did the SSO Profile apply?
Did the SSO profile apply with the settings you think it should have?
The PSSO device registration process, if successful, creates a new device record in the entra.microsoft.com Admin Portal under Devices > All Devices. For all practical purposes the computer is now bound to EntraID with a computer object now available. This is NOT the same device registration that happens with Microsoft Conditional Access. If things seem askew ask your EntraID administrator (and your Intune admin if applicable) to validate if they have anything configured in EntraID that might impact device functionality, including any conflicting configuration with Microsoft Intune.
The Microsoft Intune Company Portal app includes additional logging capabilities. Open the Microsoft Intune 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
Perform a PSSO sign-out test to validate PSSO is working correctly.
From Terminal run app-so platform -s followed by app-so platform -l
Next open Safari and browse to https://login.microsoftonline.com.
You should be prompted to authenticate.
Log out of macOS and log back in and try again and this next time PSSO should login with no prompts, if it does not see the previous steps for clues as to why.

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