10.13 - FileVault 2 and Secure Tokens

[mhrono]

I've been over the forums and found some resources relating to this issue, but nothing definitive as of yet. So, here goes!

My current enrollment workflow (working through the slow process of changing, but this is what I have to work with):

• User sets up a new Mac and creates some local account
• Enroll via $jssurl/enroll
• Enrollment script installs base sw/configs and binds to AD
• Reboot
• User is then directed to log in using their AD credentials, go to Self Service, and enable FV2.

I'm trying to make that last step automatic as part of the enrollment script. Here's what I have so far:

• Use createmobileaccount to make an account using their AD username
• Grant the account admin rights
• Prompt for current and AD credentials, then use sysadminctl to grant a secure token
• Run fdesetup with deferral to enable for the AD account at next login
• Reboot

Now, fdesetup showdeferralinfo shows that enablement is pending for the AD account. sysadminctl -secureTokenStatus $ADUser shows that there is indeed a secure token for that user. However, when $ADUser logs in, they are prompted to enable FileVault (good), but FileVault is never actually enabled (not so good). Logging out and back in results in the same prompt and no encryption. The deferred enablement seems to try to kick in every login, but never succeeds.

I'm a bit puzzled here, and would appreciate any suggestions! Happy to share more info on any of the above if required.

Thanks!

[hyprmatt]

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

[dgreening]

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

[kendalljjohnson]

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!

[jacopo_pulici]

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?

[alexjdale]

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.

[milesleacy]

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

[jconte]

@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

[alexjdale]

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.

[yan1212]

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

[jacopo_pulici]

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

[alexjdale]

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.

[dubel]

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.

[donmontalvo]

#shakesFistAtApple

[mm2270]

@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.

[jacopo_pulici]

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.

[dubel]

@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.

[Kaltsas]

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.

[HNTIT]

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 ?

[dubel]

@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.

[HNTIT]

@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 ?

[dubel]

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

[HNTIT]

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

[HNTIT]

OK

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

[rcorbin]

Has anyone tried beta 7 yet ?

[rcorbin]

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.

[jalcorn]

@rcorbin we have it doing file vault at next restart and thats working with out a problem.

[dubel]

I re-tested 10.13.4 Beta 6 and 7, I get the create Secure Token box and I enable FileVault at logout with no issues.

[rcorbin]

@jalcorn So you create an admin account and a local account during the DEP enrolment. Then you enable FileVault on the next restart ? The drive is in APFS ? Both accounts end up with a secure token ?

[jalcorn]

@rcorbin at enrollment the admin/shared account is created that is enabled for file vault. File Vault gets turned on after restart when the user logs in.

[killer23d]

@jalcorn

Which OS are you testing on? The issue @rcorbin describes is that on 10.13.3 only the first account created will show up on the boot screen (after unit has FV enabled). Any accounts added via policies or System Preference does not show up on the boot screen even they are added to the list of FileVault users in System Preference.

Since DEP creates a standard account and JAMF will create a management account, our testing indicated one of the 2 accounts will not show up on the list of FileVault user due to security tokens.

10.13.3 also breaks the built-in Guest account, the MDM doesn't seem to enable that option even it is checked. We have to manually enable in System Preferences.

At this point, we are not going to move forward to APFS as it breaks our zero-touch workflow that did not exist with 10.12; we can add script and such to issue a security token but it creates addition touch points where we are not confident in deploying.

[jalcorn]

@killer23d I haven't tried it on 10.13.3 Running a clean install to test. So can't wait to see this.

[rcorbin]

@jalcorn Are you creating the admin account via setup assistant ? I think you are doing this a bit in reverse of the way we do it. We take a machine out of the box (Currently they are 10.13.3) and when setup assistant comes up the user is logging in and creating their account and password. The admin account gets created in the background at that point via the pre-stage. With our testing both of those user accounts don't always get a secure token. Our solution at this point seems to be to reformat the machines to HFS+ . We are running Jamf Pro 10.2.2.
@killer23d

[donmontalvo]

Might want to pop your head in the 10.4 Beta forum...and while you're at it, over at the Apple Beta forum. :)

[mrbill]

@rcorbin Have you had any update on your secure token issue? We are using (as best as I can tell) the exact same setup as you. Enrolling w/ 10.13.3 and DEP, and neither the first logged in account or the admim get secure tokens. I'm going to try to format the drive with HFS+ and see if that resolves it.

[rcorbin]

@mrbill With HFS+ you are really using the old FileVault system that doesn't even have secure tokens. So it does work just fine. It's just kind of sad to have to reformat the devices. Hopefully this all starts to work correctly in the future with 10.13.5 or a future update. We have just updated to Jamf 10.3.1. We will see if that makes any difference, but I think it's an OS level thing.

[HNTIT]

I have managed to script around all my issues with this except 1.

I have a local Admin Account (inventively named Administrator) who's password differs depending on site.

When the password gets changed from the default build password, the Secure Token/FV2 password does not get changed along with it.

I have abandoned the JAMF password changing, and tried scripting it using Sysadminctl, it sort of works, but the machine needs to be rebooted, FV2 unlocked with the old Administrator password and then the passthrough login allowed to fail and the new password entered so it logs in. THEN it will sync the password change to FV2. this is useless as the account is not used often.

Anyone have any idea's on how to change a local password and have it update the secure token password immediately, without having to go to the machine and log it in.

Tried leaving it for days to see if it updates eventually, but no.

[michaelhusar]

Just to be sure: I see that 10.13.5 out of the box does not succeed to get a secure token für a new AD user at login.
Anyone having more success ? Thanx!

[Retrac]

Our workaround (using 10.13.5) is starting encryption as the account created by DEP enrolment. Then when an AD user logs in for the first time and gets the secureToken prompt IT Support enter the DEP admin account.

We then have an encrypted device with two pre-boot users, once the AD user confirms pre-boot is working we remove the DEP account from pre-boot auth users.

Complete pain with no automation.

[michaelhusar]

@Retrac Thanx for sharing!