Hi Community,
This time a post about Kerberos with macOS.
Mac users can now easily connect their new devices to Microsoft Entra ID during the initial out-of-box experience (OOBE). The macOS Platform Single Sign-on (PSSO) feature, powered by the Microsoft Enterprise Single Sign-on Extension, enables users to log into their Mac devices using a hardware-bound key, smart card, or their Microsoft Entra ID password.
This guide explains how to configure Platform SSO to support Kerberos-based SSO for both on-premises and cloud resources, alongside SSO to Microsoft Entra ID. While Kerberos SSO is an optional feature, it is recommended for users who need access to on-premises Active Directory resources that rely on Kerberos authentication.
To configure your on-prem stuff for this check out my article on kerberos here.
Prerequisites
- A minimum version of macOS 14.6 Sonoma.
- Microsoft Intune Company Portal version 5.2408.0 or later
- A Mac device enrolled in mobile device management (MDM).
- A configured SSO extension MDM payload with Platform SSO settings by an administrator, already deployed to the device. This setup is covered in my macOS article here.
- Deploy Microsoft Entra Kerberos, which is required for some Kerberos capabilities in on-premises Active Directory. Check out this article. If you have already deployed Windows Hello for Business with Cloud Kerberos trust or passwordless security key sign-in for Windows, then this step has already been completed.
Kerberos SSO Intune Configuration
You must configure a Kerberos SSO MDM profile. Use the following settings, ensuring that you replace all references to the domains proper values for your environment:
You can download the needed mobileconfig file here.
In the Intune portal go to Devices – macOS – Configuration – Create – New Policy – Platform: macOS – Policy Type: custom – Create
Name your policy, set the Custom configuration profile name and add the mobileconfig file here.
Assign this policy to a user group and create it. Platform SSO policies are user-based policies. Don’t assign the platform SSO policy to devices.
Testing Kerberos SSO
After the profile has been assigned to your device, you can verify that your device has Kerberos tickets by running the following command in the Terminal app:
app-sso platform -s
You should have two Kerberos tickets, one for your on-premises AD with the ticketKeyPath value of tgt_ad and one for your Microsoft Entra ID tenant with the ticketKeyPath value of tgt_cloud. The output should resemble the following:
To verify that your configuration is working, test with relevant Kerberos-enabled resources:
- Test on-premises Active Directory functionality by accessing an AD-integrated file server through Finder or a web application using Safari. The user should be able to access the file share without being prompted for credentials.
- Test Microsoft Entra ID Kerberos functionality by accessing an Azure Files share that is enabled for Microsoft Entra ID cloud Kerberos. The user should be able to access the file share without being prompted for credentials.
See all Microsoft articles here:
This concludes this step by step guide on Kerberos SSO to Active Directory and Microsoft Entra ID Kerberos resources in Platform SSO for macOS. And as always if you feel there is something in error or you want to add some stuff from your own experience don’t hesitate to contact me!
Has anyone actually got this to work?
Sure. Running it as we speak and not just me.
Does Secure Enclave need to be enabled for this to work?
Hi, yes there must be a configured SSO extension MDM payload with Platform SSO settings by an administrator, already deployed to the device.
We have created two SSO config via MS Enterprise SSO plug-in
Single Sign-On App Extension: Created via Device Feature Template and assigned to all users with a device filter.
PSSO: Created with the Settings Catalogue and assigned to all users with a device filter as well.
The filter is based on the Enrollment Profile Name. Filter query is based on the Enrollment Profile Name like this: (device.enrollmentProfileName -eq “xxxxxxxxxxxx”)
The problem is that users from Scenario 1 cannot register their devices through the Company Portal. This worked fine before we adopted PSSO. Users from Scenario 2 can register their devices via PSSO without any issues; it works as expected.
Do you know if there are any limitations regarding this? We do not want to use PSSO for Scenario 1, because they get cloud kerberos partial TGT (Microsoft Entra ID tenant with the ticketKeyPath value of tgt_cloud)
Kerberos management through PSSO has been a big issue for me. We use Intune and Entra ID and a sync to our on-prem AD. After getting a fresh Kerberos ticket that works for all on-prem SSO sessions, the ticket is renewed exactly two hours later and is unusable since things like internal sites and network file shares either prompt for username/password or just simply fail to auth.
The temporary fix has been to `kdestroy` both tgt_ad and tgt_cloud identities/tickets and click the “Authenticate” button under the PSSO section for the user under Users & Groups. The issue will return two hours later…
Entra SSO works great though.
I am pre-rollout and we are beginning to see a similar issue. All of a sudden our on-prem BlueCoat proxy begins prompting for interactive login. klist -A shows both cloud and on-prem TGT but I have to do a manual kdestroy and kinit in order for it to begin working again. Did anyone open a ticket with Microsoft about this?
Not to my knowledge.
We are looking to deploy this shortly in order to provide our macOS users access to on-prem file shares, did anyone figure out the issue with the above and 2hour limit?
Hi Ryan, not that i know off sorry.
I have active cases open with Apple and Microsoft on the Kerberos issue. Will post useful info as I receive it.
Awesome, I was also going to log a case with both once we had implemented. Hopefully they can provide a fix or workaround soon.
i also have active cases with Apple and Microsoft. This is a huge issue. Are you all pulling cross-domain Kerberos tickets like me in a 2 way trust?
Here’s what we found in a network trace:
KRB Error: KRB5KRB_AP_ERR_BAD_INTEGRITY
Which usually liked to a configuration issue between trusted domains, accoding to a techcommunity page from Microsoft:
https://techcommunity.microsoft.com/blog/askds/krb-ap-err-bad-integrity/4022504
This is the finding that got Apple and Microsoft support engineers to begin collaborating. Using `kswitch -i` to switch credentials between tgt_ad and tgt_cloud hasn’t worked for us, but someone claimed it worked for them in a post on the Mac Admins Slack.
Interesting, are Apple and MS still investigating the issues? We have rolled it out to around 30 users and have had a few reports of it but not all users get the issue which is odd.
Would you be able to share your ticket references so that I can also log a case?
Microsoft case #: 2410250010000376
My Apple case #: 102488989842
Thank you! have they made any progress on your case at all?
Microsoft case #: 2502250040012587
My Apple case #: 102541184421