Unlocking a Mac from a browser tab, then handing it a config profile (no MDM required)

A Mac that’s locked, or just rebooted to the login window, shows up in most remote tools as a black rectangle. And if you need a setting on it, like screen lock, firewall, Wi-Fi or Office’s update channel, Apple only lets a person or an MDM install the configuration profile.

The locked Mac

RFF Remote on the Mac is a small signed helper. It captures the screen with ScreenCaptureKit and sends mouse and keyboard with CGEvent, which works fine in a signed-in, unlocked session. When the screen locked, the stream died with this error:

capture stopped: Failed to find any displays or windows to capture

I assumed macOS hides the lock screen from capture, and I even shipped an error message that said so. Then I tested it properly and the lock screen captured fine, including the clock, the user picture and the password field.

The display had gone to sleep behind the lock (displaysleep 10), and ScreenCaptureKit can’t capture a display that’s off. A locked Mac is usually also a Mac with its display asleep, so the two looked like the same problem. RFF now declares user activity before it starts capturing, which turns the display back on. It’s the Mac version of the one-pixel mouse wiggle the Windows helper does.

# What a key press does: turn the display on, briefly.
/usr/bin/caffeinate -u -t 5

Input works on the lock screen too. RFF Remote’s CGEvents reach the password field, so a tech can type the user’s password from a browser tab and unlock the Mac. I tested it on our lab Mac by typing one character, checking that a dot appeared, and deleting it. Later I unlocked the same Mac remotely and installed a profile on it, which is further down.

Nobody is at a locked Mac to click “Allow”, so this ONLY works when your organization turns on unattended access in Settings, same as on Windows. It’s off by default. Every session goes in the audit log, and macOS shows its own “Your screen is being observed” indicator in the menu bar.

After a reboot nobody is signed in, and the Mac sits at the login window. A root daemon can’t see that screen because it isn’t part of the window server session. The way in is a LaunchAgent that launchd loads into the login window’s own session:

<key>Label</key><string>com.getrff.remote.loginwindow</string>
<key>LimitLoadToSessionType</key><string>LoginWindow</string>
<key>QueueDirectories</key><array><string>/Library/Application Support/RFF/remote-queue</string></array>

When someone connects to a Mac with nobody signed in, the agent drops a session request in that queue folder, and launchd starts RFF Remote inside the login-window session to handle it. ScreenCaptureKit returns nothing there, so the helper falls back to the older CGDisplayStream, which works. You get the login window live in your browser.

Typing at the login window doesn’t work yet. I tried every public route I know of:

CGEvent through the HID tap is ignored.
CGEvent posted straight to the loginwindow process is ignored.
IOHIDPostEvent returns kIOReturnNotPermitted.
A .hidSystemState event source deadlocks inside SkyLight.

For now the login window is view only, and RFF shows a banner saying so. I think the fix is a virtual keyboard and mouse driver (DriverKit), which macOS treats as real hardware. We’ve requested the entitlement from Apple, and the login window gets full control once it’s approved.

Configuration profiles without an MDM

Since macOS 11, this command no longer installs anything:

sudo profiles install -path ./baseline.mobileconfig   # "no longer supports installs"

A profile has to be installed by a person (System Settings > Privacy & Security > Profiles) or by an MDM. Plenty of shops don’t have an MDM, have one owned by another team, or have 30 Macs and don’t want to buy one for 30 Macs. RFF works within Apple’s rule.

The macOS Profiles page has 31 settings areas, including screen lock, firewall, Wi-Fi, VPN, certificates, privacy approvals, login items, software update, Office, OneDrive and encrypted DNS, plus five templates. The security baseline follows the NIST macOS Security Compliance Project’s CIS Level 1 rules, and the settings areas are based on Apple’s profile reference and the community ProfileManifests project. You can also import any .mobileconfig you already have.

Every save that changes a profile gets a new PayloadUUID and version number but keeps the same identifier, so v2 replaces v1 on the Mac.

When you deploy, RFF hands the profile to the signed-in user, where it shows up under “Downloaded” in System Settings, and waits until macOS reports that exact PayloadUUID as installed. The job only succeeds once the profile is actually on the Mac:

Handed to rfftest: System Settings > Privacy & Security > Profiles now shows it; they click Install and enter their password. Waiting...
Installed: 'RFF smoke test (diagnostics off)' (com.getrff.profile.smoke-diagnostics-off) (rfftest approved it).

The agent reads profiles show on every inventory, so each saved profile shows per Mac as installed (this version), older version, or not installed. Removing a profile doesn’t need anyone at the Mac.

Testing it end to end

Our lab Mac was sitting at a locked screen. From a browser tab I typed the password through RFF Remote to unlock it, opened the downloaded profile, clicked Install and typed the password at macOS’s prompt. A few seconds later the job turned Succeeded, the Profiles page showed “1 of 1 installed”, and the device page listed the profile. Clicking Remove on the device page took it back off.

If you have an MDM

RFF isn’t an MDM. An MDM can install profiles silently, escrow FileVault keys and manage a Mac from the box. A good rule of thumb is to keep your MDM if you have one: build the profile in RFF, download it, and push it from the MDM. RFF covers the day-to-day work of seeing the Mac, fixing it, and knowing what’s on it.