Extension Attribute: Which Accounts Can Actually Unlock the Disk

Overview

An extension attribute that walks every local user on a Mac, checks each one’s secure token status, and reports the enabled accounts into Jamf Pro inventory. It is the verification half of the FileVault baseline profile. Encryption compliance tells you the disk is locked. This tells you who can unlock it.

Secure token is the macOS concept most likely to ruin your week

On a FileVault volume, an account can only unlock the disk if it holds a secure token. Being an admin is not enough, and neither is appearing in a FileVault users list in some console. It needs the token, and the rules for who gets one are unintuitive: the first account created usually has it, accounts created later often do not, accounts created by a script or an MDM command frequently do not, and an account can look normal in every other respect while being unable to unlock the machine.

The failure mode is brutal and delayed. Everything works. The user logs in daily, the device reports encrypted and compliant, inventory looks clean. Then the machine restarts, and at the pre-boot screen the account simply cannot unlock it. You find out at the worst possible moment, usually on someone’s laptop, usually remotely.

The related trap: the management account you would rely on to remediate may not have a token either. Discovering that during an incident is how a recoverable situation becomes a reimage.

And nothing in standard inventory reports any of this. FileVault status says the volume is encrypted. It does not say whether the person holding the laptop can decrypt it.

What it does

while read -r username; do
  if [ "$(sysadminctl -secureTokenStatus "${username}" 2>&1 \
      | awk -v user="${username}" '{if ($7=="ENABLED") print user}')" = "${username}" ]; then
    secure_token_enabled_users+=("${username}")
  fi
done < <(/usr/local/bin/jamf listUsers -showAll | xsltproc "/tmp/stylesheet.xslt" -)

Enumerate local users, test each one, collect the enabled ones, report the list.

Two implementation details do the real work.

2>&1 on sysadminctl is required. sysadminctl writes its status output to stderr, not stdout. Without the redirect the pipeline receives nothing, every user tests as not-enabled, and the attribute returns “No users have a secure token” across the entire fleet. That looks like a catastrophic finding instead of a bug, which is a bad way to spend an afternoon.

A generated XSLT stylesheet parses jamf listUsers, which returns XML. Instead of pattern-matching usernames out of markup with grep and hoping no name contains a bracket, the script writes a small stylesheet to /tmp, transforms the XML into a clean newline-delimited list, and removes the stylesheet afterward. It is more ceremony than a regex and it does not break on input the regex did not anticipate.

It also reports an explicit "No users have a secure token" instead of an empty result. That is a real and alarming state, and it deserves to be distinguishable from a device the attribute never ran on.

What it unlocks

Secure token state becomes a smart group criterion. You can find devices where the intended user lacks a token before the reboot that would strand them, catch machines whose management account cannot assist with recovery, and validate that account-provisioning workflows are producing token-holding users.

Outcome

Fleet-wide visibility into the one piece of state FileVault depends on, surfaced from a per-device command that nothing in inventory exposes, turning a class of unrecoverable-at-reboot incidents into a query you can run beforehand.

Lessons Learned

The compliance flag and the recoverability question are different things, and dashboards report the first one. A fleet can be 100% encrypted and still contain machines nobody can unlock. Any control worth enforcing is worth a second attribute that checks whether the outcome holds, because “the setting is applied” and “the thing works” diverge quietly, and only ever in the direction you find out about during an incident.