Upcoming Change Device Compliance Integration for MacOS (SSO extension required)

[ben_whitis]

Microsoft has announced plans to move storage of the Workplace Join Key out of the user’s Login Keychain and into Apple’s Secure Enclave:   

Microsoft Enterprise SSO plug-in for Apple devices - Microsoft identity platform 

Announced in March 2024, Microsoft Entra ID will be moving away from Apple’s Keychain for storing device identity keys. Starting in Q3 2025, all new device registrations will use Apple’s Secure Enclave. There will be no opt-out of this storage location. 

Applications and MDM integrations that have a dependency on accessing Workplace Join keys via Keychain will need to start using MSAL and the Enterprise SSO plug-in to ensure compatibility with the Microsoft identity platform. 

In the same document, Microsoft provides guidance on how to test the Secure Enclave today to ensure the change will be compatible with your environment when the change goes live:  

If you would like to enable Secure Enclave based storage of device identity keys before it becomes mandatory, you can add the following Extension Data attribute to your Apple devices’ MDM configuration profile. 

Action Item: SSO extension is required for new registrations 

With this change, it will no longer be possible to register computers without using the Microsoft SSO extension or PlatformSSO. Many environments already use the SSOe/PSSO, but if you don’t, now is the time to build, test, and deploy the SSO extension:  

Configure macOS Enterprise SSO app extension with MDMs   

Recommended testing: Secure Enclave 

In order to ensure full support across all apps in your environment, we recommend testing Secure Enclave scenarios today on test devices and/or pilot groups. There are a few ways to test moving the WPJ key to the Secure Enclave. 

• If registering via Microsoft’s PlatformSSO, the Secure Enclave is used by default. If your organization already uses or is testing PlatformSSO, you are already using the Secure Enclave. 

• If using the Microsoft SSO extension without PlatformSSO, there is an optional key that can be added to the Extension Configuration data to enable Secure Enclave for WPJ storage.  

• use_most_secure_storage  

• Boolean 

• True 

Here is an example PLIST including the typical recommended settings for macOS SSO extension plus the new optional key:  

<?xml version="1.0" encoding="UTF-8"?> 

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> 

<plist version="1.0"> 

<dict> 

    <key>AppPrefixAllowList</key> 

    <string>com.microsoft.,com.apple.,com.jamf.management.</string> 

    <key>browser_sso_interaction_enabled</key> 

    <integer>1</integer> 

    <key>disable_explicit_app_prompt</key> 

    <integer>1</integer> 

    <key>use_most_secure_storage</key> 

    <true/> 

</dict> 

</plist> 

Note: We would recommend building a new SSO extension configuration to hold this additional key, and ensure it is first scoped to test machines and/or pilot users until all use cases in your environment are tested. 

How to test Secure Enclave Storage 

After pushing out either PlatformSSO or the SSO extension plus the optional key, there are a few steps to take to ensure the Workplace Join Key is moved to the Secure Enclave. 

New registrations 

New registrations with either Platform SSO or the SSO extension with the optional key will store the WPJ key in the Secure Enclave upon registration 

Existing registrations 

NOTE: To reiterate, it is not required to migrate existing registrations to secure enclave storage. The instructions below are intended solely to provide a means of testing secure enclave storage on a computer that is already registered. 

If testing with a computer that currently has a Workplace Join Key in the login keychain, the following steps should be taken to move the WPJ key to the Secure Enclave (depending on SSOe/PSSO): 

• PlatformSSO: Follow the notification prompts to register the device with PlatformSSO. This will remove the Workplace Join key from the login keychain and add a new one to the Secure Enclave 

• SSO extension: Open Keychain Access.app → Login Keychain → My Certificates tab. Delete the Workplace Join Key (the name of the keychain item will match the Entra ID GUID of the computer). Upon re-registration, the SSO extension should add the Workplace Join Key to the Secure Enclave instead of the login keychain. 

• Note: At this time we don’t seem to have a way to inspect the WPJ key in the Secure Enclave. For that reason, PlatformSSO may be the recommended approach moving forward due to the reporting capabilities discussed below. 

Checking registration state:  

Items in the Secure Enclave are not accessible via script or UI, which adds some complexity when trying to report on the registration state of computers storing the Workplace Join Key in the Secure Enclave. However, PlatformSSO registration state can be validated via Terminal using app-sso platform -s. The following extension attribute can check for device compliance registration status if the computer is registered via either the Login Keychain or using PlatformSSO (but not using SSOe with Secure Enclave storage):  

#!/bin/bash 

#Original script obtained on 03/04/2025 from https://github.com/benwhitis/Jamf_Conditional_Access/blob/main/EA_registrationStatus 

#get user 

loggedInUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' ) 

#get user home directory 

userHome=$(dscl . read "/Users/$loggedInUser" NFSHomeDirectory | awk -F ' ' '{print $2}') 

#check if registered via PSSO:  

platformStatus=$( su $loggedInUser -c "app-sso platform -s" | grep 'registration' | /usr/bin/awk '{ print $3 }' | sed 's/,//' ) 

if [[ "${platformStatus}" == "true" ]]; then 

  #Check if jamfAAD registered too 

  psso_AAD_ID=$(defaults read  "$userHome/Library/Preferences/com.jamf.management.jamfAAD.plist" have_an_Azure_id 2>/dev/null) 

  if [[ $psso_AAD_ID -eq "1" ]]; then 

    #jamfAAD ID exists 

    echo "<result>Registered with Platform SSO - $userHome</result>" 

    exit 0 

  fi 

  #PSSO registered but not jamfAAD registered 

  echo "<result>Platform SSO registered but AAD ID not acquired for user home: $userHome</result>" 

  exit 0 

fi 

#check if wpj private key is present 

WPJKey=$(security dump "$userHome/Library/Keychains/login.keychain-db" | grep MS-ORGANIZATION-ACCESS) 

if [ ! -z "$WPJKey" ] 

then 

  #WPJ key is present 

  #check if jamfAAD plist exists 

  plist="$userHome/Library/Preferences/com.jamf.management.jamfAAD.plist" 

  if [ ! -f "$plist" ]; then 

    #plist doesn't exist 

      echo "<result>WPJ Key present, JamfAAD PLIST missing from user home: $userHome</result>" 

      exit 0 

  fi 

  #PLIST exists. Check if jamfAAD has acquired AAD ID 

  AAD_ID=$(defaults read  "$userHome/Library/Preferences/com.jamf.management.jamfAAD.plist" have_an_Azure_id) 

  if [[ $AAD_ID -eq "1" ]]; then 

    #jamfAAD ID exists 

    echo "<result>Registered - $userHome</result>" 

    exit 0 

  fi 

  #WPJ is present but no AAD ID acquired: 

  echo "<result>WPJ Key Present. AAD ID not acquired for user home: $userHome</result>" 

  exit 0 

fi 

#no wpj key 

echo "<result>Not Registered for user home $userHome</result>" 

Additional reporting options are in progress 

Jamf is exploring additional options to provide a way to check for the existence of a workplace join key in the Secure Enclave. We anticipate having more to share in Q2 2025. 

[Jordy-Thery]

Really good info @ben_whitis! Much appreciated. 

[mt-nw]

really lame that the `app-sso` --json flag doesn't work for 'platform'; the -s output is a json except for those last 5 lines, which breaks the ability to use jq to get the values

[mrowell]

There are some potential significant impacts associated with this change from the Workplace Join Key to using the Secure enclave.

1. You will need to ensure your apps are NOT using the Workplace Join Key directly (like Chrome used to do - but recent releases don’t). All authentication will need to be via SSO flow (either the MS Libraries or the regular Apple networking frameworks which will be redirected to SSO).
2. Any scenarios where a user authenticates with more than a single Entra identity, within the one macOS User account, will not be possible with SSO + Device Compliance. An example of this is using dedicated Entra/M365 admin accounts to manage M365 that is seperate from your everyday Entra/M365 identity.We are exploring switching to Platform SSO as work around for the multiple Entra identities scenario. With “Shared Device Keys” enabled you can have multiple Entra identities signed in with SSO - but it does break some things. eg. The core Office Apps won’t authenticate if there is multiple SSO identities.

[ThomasBosboom]

Nice write-up; thank you!

[Person]

Thanks for the script but I'd consider to find the keychain item instead of dump.

security find-generic-password -l "MS-ORGANIZATION-ACCESS"

[rastogisagar123]

Great Read-Up. Thank you so much for sharing @ben_whitis . Much Appreciated!!