sysadminctl changes in 10.13 affecting FileVault

Apple has changed how sysadminctl works in 10.13 and it also happens to affect fdesetup. Let’s go over what has changed below.

Changes in sysadminctl

This is what the usage says in 10.12.6:

Usage: sysadminctl
-deleteUser [-secure || -keepHome]
-newPassword -oldPassword [-passwordHint ]
-resetPasswordFor -newPassword [-passwordHint ]
-addUser [-fullName ] [-UID ] [-shell ] [-password ] [-hint ] [-home ] [-admin] [-picture ]

Pass ‘-‘ instead of password in commands above to request prompt.

Whereas in 10.13.0 (changes highlighted in bold by me):

Usage: sysadminctl [[interactive] || [-adminUser -adminPassword ]]
-deleteUser [-secure || -keepHome]
-newPassword -oldPassword [-passwordHint ]
-resetPasswordFor -newPassword [-passwordHint ]
-addUser [-fullName ] [-UID ] [-shell ] [-password ] [-hint ] [-home ] [-admin] [-picture ]
-secureTokenOn -password
-secureTokenOff -password
-filesystem status

Pass ‘-‘ instead of password in commands above to request prompt.

It might not be very obvious initially, but this is important because you need to provide a user a secure token in order for them to be able to unlock the drive in FileVault.

The command to do that is:
sysadminctl -adminUser "$GUIAdmin" -adminPassword "$GUIAdminPw" -secureTokenOn "$username" -password "$user_password"

In this context, $username (and their password $user_password) is the user you want to provide a secure token to. The $GUIAdmin is an administrator that was created either via a DEP workflow or through the GUI. As has been explained to me, in order to provide a secure token to a user, the account you’re doing this from needs to have a secure token as well.

Verify Secure Token Access

To verify if an account has a secure token you can run two commands:

First option:
sysadminctl -secureTokenStatus $username

where $username is the username of the user you’re verifying secure token access for. This command should output something like:
2017-10-05 08:22:13.548 sysadminctl[570:12407] Secure token is ENABLED for user user

The second option:
dscl . -read /Users/$username AuthenticationAuthority

where $username is the username of the user you’re verifying secure token access for. This command should output something like:
AuthenticationAuthority: ;ShadowHash;HASHLIST: ;Kerberosv5;;user@LKDC:SHA1.3FCA39B2626F043821D2D6FBF414B267BC48A5EE;LKDC:SHA1.3FCA39B2626F043821D2D6FBF414B267BC48A5EE; ;SecureToken;

Enabling FileVault

On the same topic, I discovered a rather interesting change when enabling FileVault via fdesetup. It used to be that you run the command fdesetup enable -inputplist < /path/to/plist and have multiple users in that plist as described in Rich Trouton’s blog post. However, if this is the first time you’re enabling FileVault, you can no longer enable multiple users in this fashion. You can only enable one user at the initial FileVault enablement. When you’ve given multiple users secure token access AND then you enable FileVault with one user using that plist, you can verify who can unlock the drive by simply typing fdesetup status (even while the drive is still encrypting). That’s a change from 10.12 which may be bad news if only because you will need to clean up some code potentially.

The good news is that any user you’ve provided a secure token for is automatically enabled as a FV user who can unlock the FV encrypted volume. It would appear to me, and perhaps I’m misinterpreting my findings, in macOS High Sierra enabling FileVault via fdesetup is just encrypting the drive only. Users who can unlock the FV volume is determined by the secure token which is separate from what fdesetup is handling. You can in effect give users access to unlock the FileVault volume before the volume has been encrypted. Depending on whether this change was intentional, this may or may not be a bug. If it is, it’s at least one that can be worked around.

If you try to run fdesetup enable -inputplist < /path/to/plist with either multiple users or a user who does not have a secure token, you will receive the message:

Error: A problem occurred while trying to enable FileVault. (-69594)

None of this has been documented in the man page for fdesetup or in the usage for sysadminctl. But hopefully this is helpful to you if you rely on either of these 2 command line tools and are still working out your deployment strategy for 10.13.

A shout out to Wesley and Phillip and others for their explanations which clarified quite a bit for me and others.

EDIT: 10/13/17 Other admins like Joe have noted that currently it does not seem possible to given a mobile account (AD accounts) a secure token.When a computer is upgraded from 10.12 to 10.13, those accounts that had the ability to unlock FileVault automatically get the secure token. However, on a computer starting off with 10.13 that no longer applies and the above is what you need to go through except you can’t for mobile accounts.

Another thing to note is that it also appears that accounts with UID 501 automatically get a secure token. When you take that into account, AD accounts would have UIDs over 1000 and therefore there isn’t a scenario in which it would get a secure token (at least that comes to mind for me). This is a pretty huge oversight from Apple and if you deal with AD and FileVault, you should file a bug report with Apple.

EDIT: 10/26/17 I have to make another edit as others have done a bit more testing that contradicts what was mentioned in my previous edit. Ultimately you should just test this out yourself of course, but in the interest of getting information out to other admins. It seems that the first account to log into the computer (assuming a clean install of High Sierra and not an upgrade) will always get a secure token regardless of whether it is a local or mobile account and regardless of how it was created.  That means that a workflow where you use DEP, bind during Setup Assistant, and then have the user log in would work. Upgrades to High Sierra will always give users who were FV enabled users secure tokens.

However, this  does not really work for automation purposes unless you have that specific workflow. There may be organizations where DEP is used, but the first user to log in is a local admin account used by IT to do some configuration before handing the computer off to the end user. You can also give a mobile account a secure token if you unlock the Security preference pane as the local admin (with a secure token) and add the AD user to the Enabled Users list. That’s not really automating it. The other way would be to use sysadminctl as shown earlier, but that’s got the issue of having to pass user credentials in clear text which is hardly secure and not exactly something easy to automate unless you want to throw security out of the equation. In essence, Apple is opting to enhance security in macOS, but in doing so is creating an insecure method that can’t be fully automated to begin with. It would be nice if they had a way to give a secure token without having to pass credentials in clear text (perhaps a password hash?). You should file a bug report with Apple either way to improve this situation.

Here’s a related Apple article on the matter:

Here are some references to check out on the MacAdmins Slack:

FYI – In HS, user accounts created via command line now require having “SecureToken” enabled using the `sysadminctl` command.
One important note about `sysadminctl`: guiAdmin *MUST* be a user created using the GUI instead of CLI.
If SecureToken is not enabled a for a user account, you can’t switch filevault for that user in HS.

btw, even though I am using the sysadminctl command to do the securetoken thing, it still worked if I just did `dscl . -append /Users/$username AuthenticationAuthority ‘;SecureToken;’`

5 thoughts on “sysadminctl changes in 10.13 affecting FileVault

    1. It’s completely unexpected compared to 10.12 and earlier. There’s no way to create a mobile account with a secure token in the same manner that you can for local accounts. In that regard, it seems like a bug to me that mobile accounts cannot get a secure token through the command line. Further, it’s not exactly secure when you have to put credentials in cleartext in order to give other users a secure token through the command line. I think those would qualify as bugs or enhancements.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s