Apple Platform SSO & Kerberos

Here is a visual of where you might be with Apple macOS and Microsoft Active Directory (AD) integration:

In a perfect world your organization is either AD or Microsoft EntraID, or none of the above. In reality most of us are still running AD, and thanks to Microsoft 365 <cough> Office </cough> we have a handful of use cases involving EntraID, but are not able to cut-over completely. If you find yourself in this situation you still don’t want to bind your macOS to AD, but you will need to use multiple Platform SSO profiles to allow employees to access both AD and EntraID resources.

If you have not dug into Apple Platform SSO I recommend reading my other blog before you continue here. If you have already implemented the Platform SSO configuration with EntraID from that blog, let’s dig into some additional configuration options.

PSSO Kerberos with Microsoft Active Directory (AD)

In the previous blog, Apple Platform SSO was configured to use Secure Enclave with EntraID. This takes care of authentication to sites like Microsoft 365, but AD Kerberos resources will be excluded from the SSO. To fix this create a new Workspace ONE UEM SSO Extension Payload and configure it as follows:

A few important details about the configuration above:

These have been tested using macOS Sequoia 15.4 and Beta 2 of macOS Sequoia 15.5 with Workspace ONE UEM 2410 Patch 5 with Modstack.

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 your Active Directory Forest. 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 Domains to achieve this. In theory *.lab.aftersixcomputers.com is supposed to be the same as .lab.aftersixcomputers.com but in testing using the * would never allow the device to retrieve the TGT. The period in front of the domain is the wildcard that worked for me.

The “Use as Default Realm” is supposed to determine the order in which macOS uses the TGT if there is more than one Realm available on the device. When using two SSO Extension payloads on the same device make sure only one of them has this value set as Enabled. The other should remain at the default of Not Configured.

Regarding the Principal Name. Prior to implementing Platform SSO and an Identity Provider the default value of {UserPrincipleName} would be ok here because Kerberos with AD is expecting domain\username to grant a TGT. In my configuration where Platform SSO is enabled, macOS is configured with the email address as the UPN. Kerberos running in AD does not understand what to do with an email address so it rejects the TGT request and this process fails. I found that using {EnrollmentUser} gave AD Kerberos the username in the correct format.

Additional Settings > Custom XML: The table is not rendering the complete values correctly. Here is what you may need to use:

But why? Well it is a little confusing. Let me explain.

In my environment EntraID is configured with a custom domain name of aftersixcomputers.com.

My on-prem AD forest is lab.aftersixcomputers.com.

My AD users are configured with a UPN suffix of aftersixcomputers.com and they all use email addresses ending in aftersixcomputers.com.

I configure macOS to use UPN for the local macOS account.

The result of all of this is that macOS attempts to use pparker@aftersixcomputers.com as the requestor for an AD Kerberos TGT and that fails because AD Kerberos doesn’t understand who pparker@aftersixcomputers.com is. To further complicate things, because I’m using both EntraID and AD SSO Extension payloads on the same device, there is a second TGT ticket on the device that does in fact correspond to pparker@aftersixcomputers.com but this is only used for Kerberos with EntraID. Without the DomainRealmMappings key macOS would not translate requests from pparker@aftersixcomputers.com to pparker@lab.aftersixcomputers.com.

Oh and one more oddity to be aware of. After you type in this custom setting and save the profile, the next time you edit the UEM profile you will see that the payload includes a leading <dict> and </dict> tag that you did not type in. UEM is adding these to the payload then displaying the addition in the payload. The oddity here is that if you started by adding your own leading and trailing tag the payload will fail to deploy as it will duplicate the tags. This is why I do not include them in the sample above.

PSSO with Kerberos & Microsoft EntraID

Similar to the previous payload, in this example macOS is being configured to use Kerberos running in Microsoft EntraID. Create a new SSO Extensions payload as follows:

A few important details about the configuration above:

These have been tested using macOS Sequoia 15.4 and Beta 2 of macOS Sequoia 15.5 with Workspace ONE UEM 2410 Patch 5 with Modstack.

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 the value defined here.

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. It just breaks everything, so make sure you are following this otherwise odd capitalization for all the Microsoft domain names here.

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. For AD it’s kerberos:/// but for EntraID it’s kkdcp://. Make sure you change the domain to your own primary EntraID domain.

Wrap Up

Workspace ONE UEM’s Profile builder lets you add more than one payload to a profile, which means in theory you could combine the two profiles above into a single SSO Extensions payload. I could never make this work, in that UEM would allow me to save the profile, UEM would deploy the profile to the device, but the AD TGT ticket would never be generated because macOS refused to use the DomainRealmMappings key. Removing UEM from the equation I tried deploying a combined profile as a mobileconfig.xml directly and that also failed. Yet every time I deploy them as separate profiles things just work…. so spare yourself the headache and just use two profiles.