Platform SSO Rollout and Enrollment Remediation

Overview

Owned the Platform SSO rollout at Ontinue across a 300+ device Mac fleet, moving users onto a single sign-in tied to their Entra ID identity. Ran the deployment through staged pilot rings rather than a fleet-wide push, then built tooling to close the enrollment gap the rollout exposed on already-enrolled machines.

Problem

Users signed in repeatedly across the day — the laptop, then each service behind it. A new hire could hit a dozen or more separate sign-in prompts on their first day alone, and every one of them was a support surface and a place to get a password wrong.

Platform SSO solves that, but the rollout carries a specific risk: on devices already enrolled in Jamf, the SCEP profile installs correctly while the registration prompt that finishes the process can go unseen. The user closes the notification, or never sees it, and the device is left in a half-configured state — the profile present, registration incomplete, device trust never established. Nothing errors. Nothing alerts. The device simply never finishes, and the user keeps getting prompted.

Approach

Deployed in rings rather than all at once. Started with the IT testing laptops group — fewer than five devices — and held there for a week or two before widening. Expanded to roughly 30 users, then 60, collecting feedback at each ring and fixing what surfaced: a username field populating incorrectly, and a dialog window sized too large to be usable. Only after those rings were clean did the profile go out to the rest of the existing fleet and into the new-hire path.

Verification ran through Jamf’s own logs at every stage — checking config profile deployment status per device rather than assuming a successful push meant a successful registration.

For the devices that installed the profile but never completed registration, I wrote a remediation script and published it publicly as ForcePlatformSSO.

Architecture

The rollout itself is a configuration profile scoped through Smart Groups, with pilot rings defined as their own groups so scope could widen incrementally without re-scoping the whole fleet.

Production ran against Microsoft Entra ID. I also stood the flow up against Okta in a developer tenant to confirm the approach wasn’t specific to one identity provider — worth knowing before committing a fleet to it, and worth knowing for the next environment, which may not be a Microsoft shop.

The remediation script runs independently of Jamf triggers, API calls, and scope changes, so it works on any device where the profile and Company Portal are already present. It reads registration state directly from app-sso platform -s, and when registrationCompleted is false, restarts AppSSOAgent to re-fire the enrollment prompt the user originally missed. A swiftDialog status card sits bottom-right — deliberately clear of the notification, the Entra window, and System Settings — while the script polls for completion and updates the card in place. swiftDialog is installed or updated from its GitHub release with the developer Team ID verified before anything executes. On success it runs jamfAAD and closes out; on timeout it surfaces a failure modal rather than exiting quietly.

Outcome

Platform SSO shipped across the 300+ device fleet through pilot rings that caught two real usability defects before they reached general users. The remediation script turned a silent, invisible failure mode into a self-recovering one — the device detects its own incomplete enrollment and walks the user through finishing it on the spot, without a helpdesk ticket or a manual re-enrollment.

Lessons Learned

A successful profile push is not a successful outcome. The gap between “the profile installed” and “the device is actually registered” was invisible in every dashboard I had, and only showed up by reading per-device state directly. Staged rings surfaced the usability problems; querying the endpoint’s own registration state surfaced the silent ones. Both were necessary, and neither would have caught what the other did.