Apple releases long-awaited SecureToken documentation

We have been waiting for SecureToken Documentation since 10.13 Beta 1 and the introduction of APFS. I go into this in my previous article 3 Undocumented macOS Mojave 10.14 Enterprise Fixes. I talk about what SecureToken is and how we need SecureToken Documentation. The sysadminctl binary still doesn’t have a man page. You will see why, once you read on how Apple recommends that you use fdesetup instead of sysadminctl.

sysadminctl documentation — sysadminctl’s only documentation.

Documentation Please!

Many MacAdmins have called on Apple to give us some information explaining how the system works. Since 10.13 Beta 1 we have been left to fumble around and figure all this out on our own. The other problem was, that from 10.13.0 to 10.14.4 the system had many bugs and has even changed many times. It was really hard to keep up much less understand what was going on.

Enter macOS Deployment Reference “Use of SecureToken”

Now that we have the document, what does it say? Does it shed any light on the situation? In a word no… but it finally puts everything into words for new MacAdmins. Most of the information posted was already known and hashed out by experienced MacAdmins who have spent hours testing SecureToken. We will be able to share this document when anyone has questions about how SecureToken works.

Any key takeaways from the document?

1. If local user account creation in the macOS Setup Assistant is skipped using MDM and a directory service with mobile accounts is used instead, the directory user won’t be granted SecureToken when logging in to the Mac.

This statement is a little confusing yet could also be true depending on your setup. For example you can use MDM/DEP with the setting “Skip Account Creation” then bind to a directory service with a policy to enable FV2 on login. In this situation the management account/admin user is not granted a SecureToken. The first directory user to login will get a SecureToken by enabling FV2 . This is the perfect scenario, as you don’t need a tech waiting around to enter in the admin username and password for the first user logging in.

Editor’s Note: for the above situation. If you do not have a policy to enable FV2 on login the mobile account will not get a SecureToken. I never tested out this scenario. Big thanks for the clarification from TravellingTechGuy who put together a really nice SecureToken flow chart. You can find that chart here.

2. “Important: In macOS 10.13.5 or later when using a directory service and mobile accounts, users won’t be prompted about SecureToken during first login if there are no SecureToken accounts already available on the Mac. See below for additional information.”

In 10.13.3-10.13.4 directory users were prompted with this message even if the first user was logging in. You had to hit bypass to get that first login SecureToken. Now as this message states, if you logged in as the first user you are not prompted. The document also goes over how you can disable this pop up.

Seeing this note reminds me of an additional change to the SecureToken Pop up message in 10.14.4. When you log in the SecureToken message will not come up if the SecureToken account already on the system is not an admin. The point of this change is that the SecureToken user has to be an admin to enable the new user logging in. If the standard SecureToken user is not an admin don’t even bother to show the message because you would be unable to add the new user to FileVault anyway.

3. ” Managing which users can unlock a FileVault encrypted volume should generally be done using the command-line tool fdesetup. However, you can use the command-line tool sysadminctl specifically to modify SecureToken status for user accounts on the Mac. This should be done with caution and only when necessary.“

It’s interesting how Apple actually recommends using fdesetup instead of sysadminctl. The reason I say that is that we all use sysadminctl to create accounts and mange SecureToken.

The problem with using fdesetup to add an additional user to FileVault is, the account does not show the securetoken as enabled. Instead you should really should use diskutil apfs listCryptoUsers / or sudo fdesetup list -extended to get a proper list of enabled CryptoUsers. I am just pointing out that we are still having non consistent results when checking the FV2 status of a user when using sysadminctl.

You can try this yourself in 10.13.6 (17G6029) & 10.14.4 (18E226)

sudo fdesetup add -user adminuser -usertoadd mrmacintosh

sudo fdesetup list

adminuser,C26BADFD-6763-093E-8U73-3K13EN938AL3

mrmacintosh,93K18AE6-H187-497C-928F-3K13EN163AL3

sysadminctl -secureTokenStatus mrmacintosh

sysadminctl Secure token is DISABLED for user mrmacintosh

You can still unlock the volume in this condition and will report properly using the above command diskutil apfs listCryptoUsers / or sudo fdesetup list -extended.

Conclusion

In this article I point out a few things that still need some work. With that said, this document is a move by Apple to give us the needed documentation that we have asked for. We are also seeing more information in beta patch notes and Enterprise Content when a combo update is released. I hope this trend continues!