Sorry, this post won't be an answer but more technical clarification as far as I understand what's happening.

As far as I can tell any user accounts created from the command line (by the jamf binary for example) or via other "not normal" means (AKA System Preferences GUI) are barred from ever getting a SecureToken issued to them.
Currently there is not much we can do besides manually provision and open duplicates in bugreport.apple.com about this.

More detail: https://openradar.appspot.com/34874069

I would try using sysadminctl to accomplish this in 10.13. I am using this command to successfully create local users with admin rights and secureToken enabled:

sysadminctl -adminUser tempAdmin -adminPassword tempPassword -addUser managedAdmin -password managedPassword -admin

I have a workflow that is getting inconsistent results, similar to yours. During DEP setup we have our team create a common username and then have a script in Self Service that adds the mobile AD user to have Secure Token. My initial test worked but have others get the same issue of not enabling FileVault for that user, despite their name and key appearing under "fdesetup list".

Here's the script I've used so far, so that passwords don't have to be put on display for the sysadminctl command:

#!/bin/bash



loggedInUser=$(stat -f%Su /dev/console)

loggedInUID=$(id -u "$loggedInUser")



adminPassword=$(/bin/launchctl asuser "$loggedInUID" sudo -iu "$loggedInUser" /usr/bin/osascript -e 'Tell application "System Events" to display dialog "Admin user Password:" default answer "" with title "Admin Password" with text buttons {"Ok"} default button 1 with hidden answer' -e 'text returned of result')



userPassword=$(/bin/launchctl asuser "$loggedInUID" sudo -iu "$loggedInUser" /usr/bin/osascript -e 'Tell application "System Events" to display dialog "New User Password:" default answer "" with title "New User Password" with text buttons {"Ok"} default button 1 with hidden answer' -e 'text returned of result')



sysadminctl -adminUser admin -adminPassword $adminPassword -secureTokenOn $loggedInUser -password $userPassword



/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType utility -title "FileVault Ready" -description "The current user is ready to have FileVault enabled. Please refresh Self Service and run the standard Disk Encryption process." -button1 "Ok"

Would love to know if you figure out why it won't enable for a user who has a token!

Hi guys,
facing the very same issue as @mhrono
I need to fully deploy the Mac (basic stuff like Office), then send it over to the end user.
The end user should have just to log-in and start using the Mac.
Any idea on how to automate Filevault for the AD mobile account? Without Self Service.

Was thinking to scope them in some way and drop on them a config profile with FV payload in order to skip all the scripts.

Any advice?

One warning: the sysadminctl command to enable a user with a secure token requires their password, but it will accept any password. The user will be flagged as "secure token enabled" but the user will not be able to initiate FV encryption because of the password mismatch.

If you use a scripted solution, check the user password prior to assigning a secure token. It's another unacceptably poor implementation on Apple's part.

@alexjdale Do you have a ticket number with Apple? I’d be happy to ask them to link the two.

@alexjdale

If not using the Sys Prefs option for enabling users you can use these commands to work around issue:

sudo sysadminctl interactive -secureTokenStatus username

sudo sysadminctl interactive -secureTokenOn username -password -

sudo diskutil apfs updatePreboot /

If using the Sys Prefs option you should just have to use the last command. We have been using this reliably as we eagerly await Apples permanent resolution.

By using the hyphen after password it will mask the password if you are enabling at deployment like we do here.

Thanks

Sorry, I didn't submit a bug to Apple yet, but I have a scripted solution using sysadminctl that creates a "tokenholder" account to escrow a secure token, created by sysadminctl using the admin credentials of the 501 user (the technician enters it during device provisioning).

Once an AD user is logged in, a policy prompts that user for their password to pass to sysadminctl to "secure token enable" the AD user. I eventually tested the behavior if a user enters the wrong password, and found that the command was successful and the sysadminctl command listed the user's secure token status as "enabled." However, the user could not enable FV through any means.

I solved this simply by using dscl to validate the password prior to granting a secure token, re-prompting the user until it's correct. This is probably not an issue if you are using interactive mode, but if you are using "-password" in the CLI to supply the user's password, this is a risk.

Hey @alexjdale that sounds like an interesting approach. Would you mind sharing a sanitised version of your script?

Hi @alexjdale ,
I'd be interested in your solution as well. Do you mind sharing?
Thank you

Sure, I'm pulling code from a couple scripts, but here are the main components. I still need to do some cleanup work on it but it works.

This function is used to create the tokenholder account for secure token escrow. Our user 501 is always the local administrator account created by our techs at first boot, and the script prompts them for that password ($adminPassword). The function runs within a while loop that won't proceed until the password is validated along with other data collected by the Pashua form I use.

"$tokenPass" for the tokenholder password is generated for each system using select characters from a salted hash of the serial number, so it's unique and consistent. I won't share that here.

user501=$(dscl . search  /Users UniqueID 501 | cut -sf1)



captureSecureToken() {

# Create tokenholder account for FV setup. 

# Test password for user 501

passDSCLCheck=$(dscl /Local/Default authonly $user501 "$adminPassword")

if [ $? -eq 0 ]; then

    echo "Password OK for $user501"

    # Create tokenholder account to hold a secure token

    sysadminctl -addUser tokenholder -UID 449 -password $tokenPass -home /var/tokenholder -admin -adminUser $user501 -adminPassword "$adminPassword"

    # Capture token status for tokenholder

    tokenStatus=$(sysadminctl -secureTokenStatus tokenholder -adminUser $user501 -adminPassword "$adminPassword" 2>&1)

else

    echo "Password does not match"

fi

}

This bit performs the work as a separate policy that runs against any system that is unencrypted and has "tokenholder" as a local user account. I use a Pashua form to prompt the user for their password, validate it, and then assign the user a secure token. Once that is done, the script runs our FV policy which enables FV for the user in "login" mode with 0 deferrals, so they have to enable it at next login.

# All checks passed, check on Secure Token status for user

tokenStatus=$(sysadminctl -secureTokenStatus $currentUser -adminUser tokenholder -adminPassword $tokenPass 2>&1)

if [ ! "$(echo $tokenStatus | grep ENABLED)" ]; then

    echo "User $currentUser does not have a secure token, attempting to create one"

    while [ ! "$passwordVerified" ]; do

        getUserPassword

        passDSCLCheck=$(dscl /Local/Default authonly $currentUser $userPass)

        if [ $? -eq 0 ]; then

            echo "Password OK for $currentUser"

            passwordVerified="Yes"

        else

            echo "Password check failed, trying again"

        fi

    done

    sysadminctl -secureTokenOn $currentUser -password $userPass -adminUser tokenholder -adminPassword $tokenPass

fi

tokenStatus=$(sysadminctl -secureTokenStatus $currentUser -adminUser tokenholder -adminPassword $tokenPass 2>&1)

if [ "$(echo $tokenStatus | grep ENABLED)" ]; then

    echo "User $currentUser has a secure token"

else

    echo "Unable to assign secure token"

    exit 1

fi

After encryption, I have a policy that removes tokenholder from the FDE screen with

fdesetup remove -user tokenholder

I plan to eventually remove the user account entirely instead, once I get comfortable with this process.

I have a case with Apple and have been pressuring our TAM for a fix. 10.13.4 Beta 3 includes a new feature that enables Secure Token for Mobile AD accounts.

• Starting in 10.13.4 beta+, Mobile Accounts will receive a secure token on creation.




• If FVE is already enabled on the Mac, a local admin can add the AD user to the FV list




• If FVE is not configured, say on a newly deployed Mac, an AD user can login and get a secure token. Once logged in, you can then push a profile to enable FV and it will work. Or, an admin can add the user to the FV list.




• Accounts created using sysadminctl will now get a secure token on creation.

It’s true macOS won’t behave as it did prior to 10.13, but the additions in 10.13.4 ought to make working with FileVault easier than in the initial release.

#shakesFistAtApple

@dubel Thanks for the post. Let's hope Apple actually does what they are saying they will do and fixes this secureToken debacle. There are somewhat, erm, saltier words I could use to describe this whole mess, but someone needs to think of the kids. Here's looking forward to 10.13.4.

Just installed macOS 10.13.4 Beta (17E160g)...still issues in there with secure token.
The AD account doesn't get the secureToken.
Once I logged in the first time with the mobile account it asked me to insert credentials of a secure token enabled user. Even though I inserted the credentials of a previously created "tokenholder" user, no dice...
Therefore I skipped this request and moved forward. Checked with sysadminctl command and the AD account has not the secure token.

@jacopo.pulici If you logged in with that AD account and deleted it it won't get the Secure Token, I made this mistake on my first test. I would suggest a clean rebuild of 10.13, don't enroll or bind to AD, then install 10.13.4 Beta, then enroll / bind and re-test. I just did this and it worked as Apple said it would.

I'm running into some of these issues in testing, specifically the enter a secureToken administrators name and password dialog on test clients with FileVault off. This dialog is insane on unencrypted devices and I've sent that up the pipe. The directory is the authoritative source of authorization for an organization. Period. We have mechanisms both on the client and within AD to control access of directory accounts. Directory accounts need to get secureToken. Period. Given that Apple really disagrees with us on that there at least needs to be a mechanism to suppress this dialog.

I agree that the behavior on a an AD bound client with FileVault enabled is better but they've similtainouusly managed to make the behavior worse on an AD bound client with FileVault off.

I have tried a fresh build of 10.13.3 and then upgraded to 10.13.4 before enrolling.

Any new accounts local, local admin or AD Mobile Accounts still don't get tokens, and more importantly, neither does the JAMF account, so if the other accounts get removed for any reason the machine is unusable without a lot of hassle.

As a bare minimum the JAMF account needs to be given a token when created, so at least you have a stable and secure base to work from.

Anyone got any ideas ?

@HNTIT Thats odd, I tested it about 4 times since Beta 4 and haven't had issues. Do you have Apple Support contact? If so I would open a ticket.

@dubel What version of 10.13.4 did you test with.

I have only tested this with Beta 5, perhaps earlier versions fixed/broke other things ?

Only 4, but will be testing with 5 in the next few days.

let me know if anything that worked on 4 breaks on 5 for you

OK

Beta 6 seems to be even worse, nothing works any more, anyone else got any ideas

Has anyone tried beta 7 yet ?

Does anyone have a DEP workflow working yet with APFS and FileVault. Everything works fine for us with HFS+. But with APFS we don't get the secure tokens being added to user accounts consistently. Is it just totally broken ?

Our workflow would be something like this :
Turn on machine - boots to setup assistant.
Machine talks to DEP.
First user logs in and creates local account and password
Configuration Profiles get pushed down to machine
Prestage also creates an admin account
Filevault gets turned on.
Both of those accounts need filevault secure tokens.

Worksperfectly with an HFS+ workflow but not with APFS. We just received a lot of laptops that are all in APFS format. It seems really sad to have to burn them down and reformat to HFS+ to make it all work correctly.