Desktop Password Sync meets Platform SSO 2.0 and Microsoft Intune

April 2025: Additional app identifier required for the associated domain entry on macOS 15 Sequoia

Introduction

Support for Platform SSO 2.0 is available for macOS computers using Sonoma (14.0) and later.
Platform SSO 2.0 allows Desktop Password Sync to be used directly from the
macOS login window.
In this blog, I will briefly describe the configuration steps required to use Okta Device Access with Platform SSO 2.0 and Microsoft Intune as your MDM solution.

Prerequisites

Before you start ensure that you meet these requirements:

  • Your Okta Identity Engine org is available.
  • Okta Desktop Password Sync is configured, all configuration steps are describe in the following blog post.
  • Your computers are running macOS Sonoma (14.0) or later, so you can implement Platform SSO 2.0.
  • Okta Verify 9.19 deployed to your macOS devices
  • You have a Microsoft Intune environment ready with the necessary licenses and permissions

Set up Device Access SCEP certificates

Device Access SCEP certificates are required to use Desktop Password Sync on devices running macOS Sonoma (14.0) and later.
These certificates deploy with yourMicrosoft Intune environment.

Configure Okta as a CA with delegated SCEP challenge for Microsoft Intune

In this blog I am covering how to configure Okta as a CA with delegated SCEP for macOS.

Register the AAD app credentials for Okta in Microsoft Entra

In Microsoft Entra admin center, click App registrations, click + New registration.

On the Register an application page, enter the following:

  1. Name: Enter a name for the application.
  2. Supported account types: Select the appropriate supported account type. Okta tested with Accounts in this organizational directory only ([Your_Tenant_Name] only – Single tenant) selected.
  3. Supported account types: Select the appropriate supported account type. Okta tested with Accounts in this organizational directory only ([Your_Tenant_Name] only – Single tenant) selected.
  4. Click Register

On the app page under Essentials, copy and make a note of the Application (client) ID.

Now wee need to add a client secret, so in the left pane

  1. Click Certificates & secrets.
  2. Under Client secrets, click + New client secret
  3. Description: Optional. Enter a description for the client secret.
  4. Expires: Select an expiration time period.
  5. Click Add

The secret appears under Client secrets, copy and make a note of the Value.

Set the Intune scep_challenge_provider permissions

In the next step we need to configure the Intune scep_challenge_provider permissions.

  1. In the left pane, click API permissions.
  2. In the Request API permissions section, scroll down, and then click Intune

Under What type of permissions does your application require?, click Application permissions.
In the Select permissions search field, enter scep, and then select the scep_challenge_provider checkbox
Click Add permissions to finish teh configuration.

In the Configured permissions section, click Grant admin consent for [Your_Tenant_Name].

Click Yes in the message that appears.

You should see the following output.

Set the Microsoft Graph Application.Read.All permissions

Click + Add a permission.
In the Request API permissions section, click Microsoft Graph

Under What type of permissions does your application require? 
click Application permissions.
In the Select permissions search field, enter application, expand Application, and then select the Application.Read.All checkbox

Click Add permissions.

In the Configured permissions section, click Grant admin consent for [Your_Tenant_Name].
Click Yes in the message that appears.

The API permissions should look this like.

Generate a SCEP URL in Okta

In the Okta Admin Console, go to Security –> Device integrations

Click the Devices Access  tab and click Add SCEP configuration

SCEP URL challenge type: Select Dynamic SCEP URL, and then select Microsoft Intune (delegated SCEP).
Enter the values that you copied from Microsoft Azure into the following fields:

  1. AAD client ID: Enter the value you copied from the previous tasks.
  2. AAD tenant: Enter your AAD tenant name followed by .onMicrosoft.com.
  3. AAD secret: Enter the secret Value you copied from previous tasks.

Copy and save the Okta SCEP URL. You will paste the URL in the Microsoft Intune admin center in a later step.

Review and Save the configuration.

Download the x509 certificate from Okta

Click the Certificate authority tab and click the Download x509 certificate icon

Rename the downloaded file, so that it includes a .cer extension.

Create a Trusted Certificate profile in Microsoft Intune

In the Microsoft Intune admin center:

  1. Go to Devices
  2. Click Configuration profiles
  3. Click + Create profile
  4. Platform: Select macOS
  5. Profile type: Select Templates
  6. In the Template name section, click Trusted certificate
  7. Click Create

On the Trusted certificate page Basics tab, do the following

  1. Name: Enter a name for the certificate
  2. Description: Optional. Enter a description for the certificate.
  3. Click Next

On the Trusted certificate page Configuration settings tab, Certificate file: Select the
x509 certificate (CER file) that you downloaded from Okta.

Click Next after the certificate was uploaded.

Assign the profile to your desired groups.

Review and create the profile.

Verify if the profile was successfully created.

Create a SCEP profile in Intune

Navigate to

  1. Devices
  2. Click Configuration profiles
  3. Click + Create profile
  4. Platform: Select macOS
  5. Profile type: Select Templates
  6. In the Template name section, click SCEP certificate
  7. Click Create

On the SCEP certificate page Basics tab, do the following

  1. Name: Enter a name for the certificate
  2. Description: Optional. Enter a description for the certificate.
  3. Click Next

On the SCEP certificate page Configuration settings tab, do the following:

  1. Certificate type: Select Device
  2. Subject name format: Enter a subject name.
    For example, CN={{UserPrincipalName}} ODA {{DeviceId}}
  3. Certificate validity period: Select Years in the list, and then enter 1 in the next field.
  4. Key usage: Select Digital signature.
  5. Key size (bits): Select 2048
  6. Click + Root Certificate select the trusted certificate that you created earlier.
  7. Click OK

Continue with the setup

  1. Under Extended key usage, set Predefined values to Client Authentication
  2. SCEP Server URLs: Enter the SCEP URL you generated in Task 2.
  3. Allow all apps access to private key: Select Enable
  4. Click Next.

also assign this profile to your desired groups.

and create it.

Verify if the profile was successfully created.

Verify the certificate installation on a macOS device

On a macOS device managed by MEM, open KeychainLogin to verify that a client certificate and associated private key exists.

Update your MDM profiles

Using Platform Single Sign-On 2.0 with Okta Desktop Password Sync requires you to make some configuration changes to your existing device management profiles.

  1. com.okta.mobile-auth-service-extension profile
  2. single sign-on extension profile

Let’s start with the extension profile, open it.

Click Edit within the Configuration settings menu.

Upload the updated .plist file.

You can use this template, just replace add-your-client-ID-here with the Client ID found in the Desktop Password Sync  app > Authentication tab in your Okta Tenant.
And also replace https://your-org.oktapreview.com with your Okta tenant URL.

{{mail}} is an optional value for OktaVerify.UserPrincipalName, which automatically populates the email email add in the Sign-In Widget.
If a value isn’t specified, users need to input their username when signing in.

<key>OktaVerify.OrgUrl</key>
<string>https://your-org.oktapreview.com</string>
<key>OktaVerify.UserPrincipalName</key>
<string>{{mail}}</string>
<key>OktaVerify.PasswordSyncClientID</key>
<string>add-your-client-ID-here</string>
<key>PlatformSSO.ProtocolVersion</key>
<string>2.0</string>

You see the updated value for PlatformSSO 2.0

Review and save the profile.

Update your single sign-on extension profile

Now we need to update the single sign-on extension profile.

Click Edit within the Configuration settings menu

Select the and configure the settings as described:

  1. press Add settings
  2. type in shared
  3. select Authentication > Extensible Single Sign On (SSO)
  4. select Use Shared Device Keys
  5. select all these settings

Enable the Use Shared Device Keys option and save the profile.

After Shared Device Keys has been enabled, users receive a notification asking them to update their registration.
This will take the user through the Desktop Password Sync registration process to sync their Okta password to their macOS account.

Let’s take a look at this in the following demo:

  1. Admin updated the device management profiles in Intune
  2. Desktop Password Sync registration process starts again

And this should then also be reflected on the macOS device in the Profiles section.

Demo Password Sync on macOS lock screen

This demo shows the Password Sync functionality on macOS lock screen on a
Microsoft Intune enrolled device.

3 thoughts on “Desktop Password Sync meets Platform SSO 2.0 and Microsoft Intune

  1. I got an error with the SCEP certificate when it’s set to user. When I changed it to device, it went through fine. The error was “ErrorCode:SubjectNameMismatch,ErrorDescription:Subject Name in CSR and challenge do not match.” What’s the benefit of using “user” over “device”?

  2. hi arkaduisz … thank you very much for this brilliant blog. setup has been easy following your documentation. one quick question:

    if i try to login using safari browser, it does not detect the device and thus, not allowing me to use an “authentication policy” based on device status. doing the same in edge workes as desired.

    this changes once i change “sso type” from “redirect” to “credential”. but that breaks desktop password sync registration.

    have you come across this issue?

    regards,
    MO

  3. This is based on ODA SCEP and not ENdpoint Management SCEP, you need to have a second SCEP deployed for the Device Management Attestation.

Leave a Reply