Apple Platform SSO & Microsoft Kerberos

Last Updated 12/08/2025

Introduction

This is part two 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

Microsoft and Apple have a long history of developing frameworks to allow macOS to interact with Microsoft Active Directory. Over time the tools and methods have evolved and many organizations pay for 3rd party tools to address gaps in the Apple developed frameworks. Microsoft summed up this history as:

Apple highlights their continued evolution of these frameworks as follows:

The point of both of these illustrations is that Apple PSSO is a replacement/evolution of all of the previous methods. By implementing PSSO macOS no longer needs to be bound to Active Directory.

Microsoft customers run Kerberos as part of Microsoft Active Directory, or from Microsoft EntraID. Determine which Kerberos will be used and configure it using one of the two options below.

The configurations below have been tested and validated using Workspace ONE UEM Console 2506 Patch 14 (with Modern Architecture Enabled). They are tested on various Apple hardware running macOS Sequoia 15.7.2 through macOS Tahoe 26.1. As new releases of macOS and Workspace ONE UEM are released these blogs are updated so pay attention to the Last Updated date at the top of this blog.

Option 1: PSSO Kerberos with Microsoft Active Directory (AD)

Over the last year, Omnissa’s built-in Profile payloads for PSSO have undergone lots of changes and revisions to fix bugs, add keys, but they remain less than reliable for working with PSSO configuration. I do not recommend using the Profile builder GUI but instead use Custom Settings.

In the Workspace ONE UEM Console add a new Profile > Apple macOS > Management Type Imperative, Context Device > Choose Custom Settings and use the following example.

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>ExtensionData</key>
    <dict>
        <key>allowAutomaticLogin</key>
        <true/>
        <key>allowPasswordChange</key>
        <true/>
        <key>allowPlatformSSOAuthFallback</key>
        <true/>
        <key>performKerberosOnly</key>
        <true/>
        <key>usePlatformSSOTGT</key>
        <true/>
        <key>pwNotificationDays</key>
        <integer>14</integer>
        <key>pwReqComplexity</key>
        <true/>
        <key>syncLocalPassword</key>
        <false/>
        <key>useSiteAutoDiscovery</key>
        <true/>
    </dict>

    <key>ExtensionIdentifier</key>
    <string>com.apple.AppSSOKerberos.KerberosExtension</string>

    <key>Hosts</key>
    <array>
        <string>.lab.aftersixcomputers.com</string>
        <string>lab.aftersixcomputers.com</string>
        <string>testing.lab.aftersixcomputers.com</string>
    </array>

    <key>Realm</key>
    <string>LAB.AFTERSIXCOMPUTERS.COM</string>

    <key>PayloadDisplayName</key>
    <string>Kerberos SSO Extension (LAB)</string>

    <key>PayloadIdentifier</key>
    <string>com.apple.extensiblesso.95AE1093-B81E-4A47-9F2B-B390ECF29DFF</string>

    <key>PayloadType</key>
    <string>com.apple.extensiblesso</string>

    <key>PayloadUUID</key>
    <string>95AE1093-B81E-4A47-9F2B-B390ECF29DFF</string>

    <key>PayloadVersion</key>
    <integer>1</integer>

    <key>TeamIdentifier</key>
    <string>apple</string>

    <key>Type</key>
    <string>Credential</string>
</dict>

A few important details about the configuration above:

Apple, Omnissa, and Microsoft documentation agree that the Realm is case-sensitive and MUST be Capitalized. The Realm should be the Fully Qualified Domain Name (FQDN) of the Active Directory Forest. In the example above LAB.AFTERSIXCOMPUTERS.COM is the name of Active Directory Forest. Change this value before deploying the payload. From there you have the option to define which sub-domains Kerberos should grant TGTs for.

What none of the vendors documentation agrees on is the format for the <key>Hosts</key>. Adjust this to match the AD domains in your environment. In theory, *.lab.aftersixcomputers.com is supposed to be the same as .lab.aftersixcomputers.com but in testing attempts to use the * would never allow the device to retrieve the TGT. Use a period in front of the Hosts name instead of an asterisk to resolve this behavior.

Kerberos Realm selection can be confusing. Apple macOS selects the default Kerberos realm based on the first SSO extension that establishes an authenticated identity during login. For organizations leveraging Microsoft 365 the recommendation here is to let Apple macOS pick the default Kerberos realm based which is achieved by NOT using <key>isDefaultRealm</key><true/>. This key has been left out of the configuration above on purpose in order to allow macOS to choose the correct realm.

For Microsoft 365 customers, it will be necessary to deploy a second SSO Extension Payload, detailed in Part 3 of this blog series. When using two SSO Extension payloads on the same device, only one of the two would include isDefaultRealm or it can be left out of the payload entirely which is the recommended approach.

Option 2: PSSO with Microsoft EntraID Kerberos

This configuration is only used when Microsoft Active Directory does not exist and there is a Kerberos resource in Microsoft EntraID that needs to be used. I have not found anyone in this state so the following is more theory than actual recommendation. If this is your configuration reach out so we can community source a working config for this. The approach below was tested and confirmed to install successfully, it was just not fully vetted beyond “did it install.”

Name	Set Value To
Extension Type	Kerberos
Realm	AFTERSIX.ONMICROSOFT.COM
Use as default realm	Not Configured
Domains	aftersixcomputers.com windows.net .windows.net KERBEROS.MICROSOFTONLINE.COM MICROSOFTONLINE.COM .MICROSOFTONLINE.COM
Use Site Auto-Discovery	Enable
Allow Automatic Login	Enable
Use Platform SSO TGT	Enable
Allow Authentication Fallback	Enable
Perform Kerberos Only	Disable
Identity Issuer Auto Select Filter	Leave Blank
Allow SmartCard	Disabled
Allow Password	Enable
Start In Smart Card Mode	Disable
Require Biometric Authentication	Not Configured
Delay User Setup	Disable or Not Configured
Credential Use Mode	Always
Monitor Credential Cache	Enable
Require TLS	Not Configured
Principal Name	{UserPrincipalName}
Custom Username Label	Leave Blank
Help Text	Leave Blank
Site Code	Leave Blank
Certificate	None
Allowed Bundle IDs	Leave Blank
Preferred KDCs	kkdcp://login.microsoftonline.com/aftersix.onmicrosoft.com/kerberos
Allow Kerberos to use credentail	Enable
Require Managed Applications	Not Configured
Allow Password Change	Enable
Sync Local Password	Enable
Match AD Password Complexity	Enable
Password Change Message	Your choice
pwReqRTFData	Leave Blank
Minimum Password Length (in characters)	4
Password History Count (number of passwords)	0
Password Minium Age (in days)	0
Password Expiration Notification (in Days)	365
Password Change URL	Leave Blank
Additional Settings > Custom XML	Leave Blank

A few important details about the configuration above:

Realm: To find the correct value for your environment login to https://entra.microsoft.com select the Identity Blade and select Overview. The primary domain is listed there.

Domains: You’ll notice that I am using aftersixcomputers.com not .aftersixcomputers.com (missing the leading wildcard period) and for that matter not aftersix.onmicrosoft.com. This is because in my environment lab.aftersixcomputers.com is the name of the AD Forest. aftersixcomputers.com is an EntraID Custom domain name. I am making sure that macOS understands the distinction by leaving off the wildcard entry for the domain.

Another oddity is that I do not understand why windows.net is not capitalized, but the other Microsoft sites are. I tried changing these and well, don’t do it. It just breaks everything. So make sure you are following this otherwise odd capitalization for all the Microsoft domain names.

Principal Name. Notice that I’ve left this at the default because in my environment UPN is the email address which is the format EntraID is expecting.

Preferred KDCs. Notice the format is different than the other payload. For AD it’s kerberos:// but for EntraID it’s kkdcp://. Make sure you change the domain to your own primary EntraID domain.