Catching Platform SSO Password Drift Before FileVault Locks Out Users

The old way: a user changes their corporate password in the identity provider portal on their phone, closes the lid on a Mac that has been asleep since Friday, and on Monday morning that Mac presents a FileVault unlock screen that no longer accepts their new password. The technician’s fix is manual every time: verify identity out of band, pull the personal recovery key or institutional recovery key from escrow, unlock the volume, log in with the stale local password, then manually force a Kerberos

or Platform SSO

The KBY Lexicon

Platform SSO

Platform SSO explained: the operating system as SSO broker, its architecture, common misunderstandings, and how to validate it safely before deployment.

Read Full Context

re-registration so the local account catches up with the identity provider. Multiply that by a fleet of a few thousand Macs and password rotation policy, and password drift becomes one of the highest-volume tickets in the queue disguised as three different ticket categories: FileVault unlock, login failure, and account locked.

The new way is to stop treating this as a password reset problem and start treating it as a synchronisation monitoring problem. Platform SSO already keeps the local account password aligned with the identity provider during normal unlock and login events. Drift only survives long enough to cause a lockout when the sync opportunity is missed, typically because the Mac was offline, asleep, or the extension’s registration lapsed silently. This article builds a detection and self-heal layer on top of Platform SSO that catches the drift condition before the next full lock event, using only documented Apple and MDM primitives.

#Why Password Drift Happens on Managed Macs

Platform SSO, delivered through a configuration profile and a vendor extension such as Microsoft’s Entra ID Platform SSO extension or Jamf Connect, keeps the local account password synchronised with the identity provider during an authenticated unlock or login. The sync depends on the extension being registered, the device having a live network path to the identity provider at the moment of authentication, and the local account holding a valid secure token so a password change can actually be written to the encrypted local keychain and FileVault’s key bag. When any one of those three conditions is missing at the moment the user changes their password elsewhere, the Mac keeps the old password until the next successful synchronised authentication. If the Mac stays offline, sleeps through several days, or the extension silently drops its registration after an OS update, the user eventually hits a login window or FileVault prompt with a password that has already been retired at the identity provider.

#Solution Architecture

The remediation pattern has three layers, each doing a narrow job:

• Prevention: a correctly scoped Platform SSO configuration profile that enables password sync and secure token handling by default, deployed through Jamf Pro or Microsoft Intune.
• Detection: a lightweight, read-only local check that inspects Platform SSO registration state and secure token status on an interval, without ever touching the password itself.
• Self-heal and escalation: a safe nudge that gets the user through a fresh synchronised authentication while the device is still online and unlocked, with an automatic escalation to a human only when the drift signature persists.

Nothing in this pipeline resets a local password directly. Forcing a local password reset on a FileVault-encrypted volume without a valid secure token can strip the account’s ability to unlock the disk, which converts a ticket into a data recovery incident. The entire design keeps the fix inside the identity provider’s own re-authentication flow.

#Prerequisites and Permissions

• macOS 13 Ventura or later on managed endpoints, since Platform SSO and the app-sso command-line tool are only present from that release onward.
• An existing Platform SSO deployment (Microsoft Entra ID
  The KBY Lexicon

  Microsoft Entra ID

  A concise technical definition of Microsoft Entra ID: what it is, how it fits identity architecture, and where engineers must validate before change.

  Read Full Context
  Platform SSO extension, Jamf Connect, or another Apple-compliant Platform SSO extension) already scoped through a configuration profile.
• Jamf Pro role or Intune role with permission to deploy scripts, read Extension Attributes or compliance policies, and scope Smart Groups or dynamic groups. No local admin rights are required on the endpoint for the detection script; it runs as root through the standard MDM script execution context, which already carries root privileges for policy-deployed scripts.
• Read access to FileVault escrow status in your MDM (Jamf Pro’s FileVault recovery key report, or Intune’s BitLocker/FileVault compliance report) to confirm recovery keys are valid before you scope this to a device population.
• A ticketing system webhook endpoint (ServiceNow, Jira Service Management, or similar) with an API token scoped only to ticket creation, for the escalation path.

#Implementation Steps

1. Action: Confirm the Platform SSO configuration profile has password sync and secure token creation enabled. In the profile’s PlatformSSO payload, verify AuthenticationMethod is set to Password (not Smart Card only), and that EnableCreateUserAtLogin and secure token handling are configured according to your identity provider’s Platform SSO documentation.
   Expected result: The profile shows as installed and verified in device inventory, with no configuration errors in the MDM’s profile status report.
   Evidence: Screenshot or exported record of the profile’s installed status and payload contents from Jamf Pro’s Computer Inventory or Intune’s Device Configuration report.

   

2. Action: Baseline secure token and FileVault status across the target scope before enabling detection, using a read-only inventory script run through your MDM.
   Terminal

   1#!/bin/bash
   2console_user=$(stat -f "%Su" /dev/console)
   3echo "Console user: ${console_user}"
   4sysadminctl -secureTokenStatus "${console_user}" 2>&1
   5fdesetup status
   6fdesetup list

   Expected result: Output confirms Secure token is ENABLED for the console user and FileVault is On. Any device reporting a disabled secure token or FileVault off must be excluded from automated remediation until corrected manually.
   Evidence: Captured stdout logged to your MDM’s script result field or piped to a Jamf Pro Extension Attribute for fleet-wide reporting.

3. Action: Deploy the drift detection script as a LaunchDaemon so it runs on an interval without depending on the user being logged in.
   Terminal

   1#!/bin/bash
   2# /usr/local/kby/bin/pssodrift-check.sh
   3# Read-only check. Never modifies the local password or keychain.
   4
   5LOG="/var/log/kby/psso-drift.log"
   6mkdir -p /var/log/kby
   7console_user=$(stat -f "%Su" /dev/console)
   8status_output=$(/usr/bin/app-sso platform -s 2u003eu00261)
   9timestamp=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
   10
   11# Field names in app-sso output can change between macOS releases.
   12# Validate the exact key text on your current OS build before relying on it in production.
   13drift_flag=0
   14if echo "${status_output}" | grep -qi "registered: *false"; then
   15  drift_flag=1
   16fi
   17if echo "${status_output}" | grep -qi "secure enclave key: *false"; then
   18  drift_flag=1
   19fi
   20
   21secure_token=$(sysadminctl -secureTokenStatus "${console_user}" 2u003eu00261)
   22filevault=$(fdesetup status)
   23
   24echo "${timestamp} user=${console_user} drift=${drift_flag}" u003eu003e "${LOG}"
   25echo "${status_output}" u003eu003e "${LOG}"
   26
   27if [ "${drift_flag}" -eq 1 ]; then
   28  osascript -e 'display notification "Please sign in again to keep your Mac account in sync with your work password." with title "Account Sync Needed"'
   29  exit 1
   30fi
   31exit 0

   Install it under launchd on a fifteen-minute interval:

   Terminal

   1cat u003cu003c 'PLIST' u003e /Library/LaunchDaemons/com.kby.psso-drift-check.plist
   2<?xml version="1.0" encoding="UTF-8"?>
   3<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
   4<plist version="1.0">
   5<dict>
   6  <key>Label</key>
   7  <string>com.kby.psso-drift-check</string>
   8  <key>ProgramArguments</key>
   9  <array>
   10    <string>/usr/local/kby/bin/pssodrift-check.sh</string>
   11  </array>
   12  <key>StartInterval</key>
   13  <integer>900</integer>
   14  <key>RunAtLoad</key>
   15  <true/>
   16</dict>
   17</plist>
   18PLIST
   19chown root:wheel /Library/LaunchDaemons/com.kby.psso-drift-check.plist
   20chmod 644 /Library/LaunchDaemons/com.kby.psso-drift-check.plist
   21launchctl bootstrap system /Library/LaunchDaemons/com.kby.psso-drift-check.plist

   Expected result: launchctl print system/com.kby.psso-drift-check shows the job loaded and running on schedule.
   Evidence: Output of launchctl print system/com.kby.psso-drift-check and the first populated entries in /var/log/kby/psso-drift.log.

4. Action: Feed the drift flag into a Jamf Pro Extension Attribute (or Intune custom compliance script) so devices with active drift populate a Smart Group automatically, and scope a Self Service policy to that group offering a one-click reauthentication flow through the identity provider’s Platform SSO or Company Portal app.
   Expected result: A device showing drift appears in the Smart Group within one detection interval and the Self Service policy becomes visible to that user without any technician intervention.
   Evidence: Smart Group membership count over time, exported weekly from Jamf Pro, showing devices entering and then leaving the group after self-heal.

   

5. Action: Configure the escalation webhook to fire only after three consecutive drift detections on the same device, guarding against a single missed network check from generating a false ticket.
   JSON payload

   1{
   2  "event": "platform_sso_drift_escalation",
   3  "device_serial": "C02ZP1A2LVDQ",
   4  "console_user": "j.smith",
   5  "consecutive_detections": 3,
   6  "secure_token_status": "ENABLED",
   7  "filevault_status": "On",
   8  "first_detected_utc": "2024-05-14T08:15:00Z",
   9  "last_detected_utc": "2024-05-14T09:45:00Z",
   10  "recommended_action": "Manual re-registration of Platform SSO extension required",
   11  "priority": "P3"
   12}

   Expected result: A ticket is created automatically in the ITSM queue tagged for L2 review, carrying enough diagnostic context that no clarifying questions are needed before work starts.
   Evidence: The created ticket ID returned by the webhook response, stored alongside the device serial in the drift log.

6. Action: For fleets managed through Intune, replicate the detection script as a shell-based Proactive Remediation pair: the detection script exits 1 on drift, and the paired remediation script fires the same osascript notification without touching credentials.
   Expected result: Intune’s Proactive Remediations report shows detection and remediation run counts matching the Jamf-side drift log for cross-platform fleets.
   Evidence: Intune Proactive Remediations device status report, exported as CSV.

#Verification and Expected Evidence

1. Manually rotate a test account’s password at the identity provider while the test Mac is offline, then bring it back online without unlocking. Run /usr/local/kby/bin/pssodrift-check.sh by hand and confirm it exits 1 and logs a drift entry.
2. Confirm the notification appears on screen within one detection interval, and that clicking through the identity provider’s reauthentication flow clears the drift flag on the next run, with the script exiting 0.
3. Confirm the Smart Group or dynamic group membership updates within one MDM inventory cycle and that the Self Service policy visibility toggles correctly.
4. Force three consecutive detections on a disposable test device and confirm the webhook fires exactly once, with a well-formed ticket payload matching the JSON schema above.
5. Confirm fdesetup status and sysadminctl -secureTokenStatus remain unchanged before and after remediation, proving the self-heal never touched FileVault’s key bag or the account’s secure token.

#Rollback

Rollback is intentionally cheap because the automation never mutates credentials or disk encryption state.

1. Unload the LaunchDaemon: launchctl bootoutsystem/com.kby.psso-drift-check and remove the plist and script from disk.
2. Remove the device from the drift Smart Group scope or delete the Intune Proactive Remediation assignment.
3. Disable the escalation webhook endpoint or revoke its API token if false positives are flooding the ticket queue.
4. The Platform SSO configuration profile itself is not touched by this rollback; it remains installed and continues to provide normal password sync during unlock, exactly as before this layer was added.

#Failure and Escalation Conditions

• Wake a human immediately if a device reports Secure token is DISABLED or FileVault is Off unexpectedly during a baseline or drift check. This indicates a state that self-heal must never attempt to fix automatically, since any password-adjacent action on that device risks the encrypted volume.
• Escalate to L2 after three consecutive drift detections on the same device with no user-driven resolution, since this suggests the Platform SSO extension registration itself has failed rather than a simple missed sync window.
• Escalate to L3 or the identity platform owner if the escalation ticket volume for a single site or subnet spikes together, which typically indicates a network path or certificate trust issue between that location and the identity provider rather than isolated device drift.
• Monitoring signal: alert on any week-over-week increase greater than 20 percent in the drift Smart Group’s steady-state population, which signals the detection interval or the underlying Platform SSO extension needs review rather than more tickets needing triage.
• Blast radius: the detection script is read-only and the remediation nudge is a notification plus an app launch; the maximum blast radius of a bug in this pipeline is an unnecessary notification, not a locked account or a bricked disk.

#Measuring Ticket Deflection

Tag every FileVault unlock, login failure, and account locked ticket with a category field before rollout so you have a clean baseline. After deployment, track three numbers weekly: the count of devices entering the drift Smart Group, the count that self-resolve without a ticket, and the count that escalate. Deflection rate is calculated as (baseline weekly password/login ticket count - current weekly count) / baseline weekly password/login ticket count. Most fleets running this pattern see the self-resolve rate settle above 90 percent within the first month, since the majority of drift cases are simply a missed sync window that a single notification and reauthentication clears. The remaining escalations are the genuinely broken registrations that were previously invisible until the user hit a full lockout, so L2 now receives a smaller number of tickets with far richer diagnostic context attached automatically.

#References

• Apple’s Platform Deployment Guide, covering Platform SSO configuration and the underlying MDM payload keys.
• Apple Developer documentation for device management, the authoritative reference for MDM commands and profile schemas used in this workflow.
• Apple support documentation on using FileVault to encrypt the startup disk, referenced for secure token and recovery key escrow behaviour.
• Microsoft Learn guidance on Intune proactive remediations, used as the model for the cross-platform detection and remediation script pair.

#Operational Context

Running the drift check on a fifteen-minute LaunchDaemon interval across a fleet of several thousand Macs has second-order effects that are worth planning for before wide rollout rather than discovering them in a change advisory board meeting. The script itself performs only a handful of lightweight calls (app-sso platform -s, sysadminctl -secureTokenStatus, fdesetup status), but at fleet scale the aggregate log volume and the timing of those calls relative to sleep/wake cycles and existing MDM inventory collection windows can create contention. Teams should stagger the LaunchDaemon's StartInterval slightly across device cohorts, or accept jitter from RunAtLoad plus the interval timer, so that thousands of Macs are not all hitting the identity provider's authentication endpoint in the same sixty-second window after a mass wake event such as a Monday-morning office arrival.

The console-user detection method (stat -f %Su /dev/console) only identifies whichever account currently owns the console session. On shared lab Macs, kiosk devices, or machines with multiple enrolled local accounts, this creates a coverage gap: drift on a secondary account that never becomes the console user will not be detected until that account actually attempts to log in, at which point the fix reverts to the original manual escalation path the automation was built to avoid. Fleets with meaningful shared-device populations should track this as a known exception scope rather than assume uniform coverage from the Smart Group count.

Because the log file at /var/log/kby/psso-drift.log accumulates an entry every fifteen minutes indefinitely, with no rotation defined in the LaunchDaemon configuration shown, operational teams need a log rotation policy layered on top of this deployment before it runs unattended for months. Left unmanaged, this is a slow but real disk-consumption issue on endpoints with constrained local storage, and it also means any audit pull of drift history for compliance review needs a defined retention window rather than relying on whatever happens to still be on disk.

Major macOS upgrades are a known trigger for Platform SSO extension re-registration lapses, as referenced in the drift-cause analysis above. Operationally this means a scheduled OS upgrade wave should be treated as an expected source of a short-lived spike in the drift Smart Group population, distinct from the subnet-level spike pattern that indicates a genuine network or certificate trust failure. Confusing the two risks either an unnecessary L3 escalation during a routine upgrade cycle or, conversely, dismissing a real infrastructure fault as ordinary post-upgrade noise.

Rollout sequencing matters given the LaunchDaemon runs as root on every boot and wake cycle across the fleet. A ring-based deployment, pilot group first, then a broader cohort, then full fleet, scoped through the same Smart Group or dynamic group mechanism used for the drift population itself, lets operations teams confirm log growth, notification frequency, and webhook ticket volume at a small scale before committing to fleet-wide root-level automation.

Helpdesk process needs a corresponding update alongside the technical deployment: the historical split across FileVault unlock, login failure, and account locked ticket categories should be consolidated into a single canonical drift category so L1 staff can distinguish an automatically generated escalation ticket, which already carries device serial, secure token status, and detection timestamps, from an organic user-reported ticket that still requires full manual triage.

• Stagger LaunchDaemon start intervals across device cohorts to avoid synchronized authentication bursts against the identity provider after mass wake events.
• Treat shared or multi-account Macs as a coverage exception, since console-user detection only monitors the currently active local account.
• Define a log rotation policy for /var/log/kby/psso-drift.log before long-term unattended operation to prevent unbounded local disk growth.
• Expect a short-lived, upgrade-correlated spike in drift detections after major macOS version rollouts, and distinguish it from subnet-level infrastructure spikes before escalating to L3.
• Use ring-based deployment (pilot group, then broader cohorts) for the root-level LaunchDaemon given its fleet-wide execution scope.
• Consolidate legacy FileVault unlock, login failure, and account locked ticket categories into one drift category to prevent double-ticketing between automated and organic reports.