High Sierra (10.13) Encrypted Users not showing at FileVault login Screen

[jacomaree]

hi everyone. been testing High Sierra imaging (not DEP thin deployment), full imaging using the latest 17A405 installer. deploying the same applications as per our 10.12 imaging. imaging converting to APFS, encryption and AD bind works fine to the point i can login with my AD account.
problem is, once the Mac has been encrypted (takes a day to complete on a 2015 MacBook Air with 256GB SSD) and you enable the main admin account and other accounts, mix of AD and local accounts - the encrypted users do NOT show in the FileVault login screen.
as suggested in other discussions - i have tried unbinding the Mac from AD and rebinding it, logging back into the accounts and then restarting - still doesn't work.
have removed the existing user (deleting accounts via System Preferences - Users & Groups) and then recreating the local accounts, login in and encrypting them - same for AD accounts
still doesn't show in the FileVault login window.

we are running JAMF 9.101.0-t1504998263
macOS High Sierra 17A405

[kcgarner]

We are seeing the same issue and have a case open with Apple. We cannot see AD accounts at the encryption screen, only local accounts. We have a couple workarounds to get the AD account to show at the encryption screen:

First Workaround:
If we use "sudo fdesetup list" we see the AD user accounts, we then add the AD accounts with "sudo fdesetup add -usertoadd <ADUserName>"

Second Workaround:
1. Add local account to Filevault, 2. Restart 3. We can see the local account at the encryption screen, 4. Add AD account
5. Restart, 6. We cannot see AD account at
7. Add another local account
8. Restart
9. We can now see the AD account at the encryption screen

Apple believes its an issue with the GUI when adding/enabling users through the Security & Privacy>Filevault. Because fdesetup does work

[jacomaree]

@kcgarner - thank you for the update and the info!
initially i won't see any local or AD accounts in FV login screen.
i have unbound the Mac from AD and rebound it and then logged in with my AD account and now it is showing the local account that's encrypted.
i will raise a support case with Apple directly as this will cause major issues with getting 10.13 deployed in the organisation.

[powellbc]

Co-worker sent me this:

Users created via cli tools do not receive SecureToken

[kcgarner]

we initially need to set the securetoken to our local admin account that the JSS creates.

!/bin/sh

Variables

tempAdmin="xxxx" # TempAdmin account created during setup
tempAdminPass="xxxx" # Pass for the TempAdmin account
managementAdmin="xxxx" # The management account created by the JSS
managementAdminPass="xxxx" # The password for the management account created by the JSS

sudo sysadminctl -adminUser $tempAdmin -adminPassword $tempAdminPass -secureTokenOn $managementAdmin -password $managementAdminPass

then we log in with an AD account

[bpavlov]

https://babodee.wordpress.com/2017/10/05/sysadminctl-changes-in-10-13/

That will hopefully provide insight. However, from what others have found, none of these steps will matter for AD accounts as it appears that mobile accounts do not receive a secure token even if you go through the same process as you would for local accounts.

[jacomaree]

thank you everyone for the info! i've contacted Apple Support yesterday and opened a support ticket for this issue. i have supplied them with logs, screenshots (of FileFault page in System Preferences and Users & Groups) and photos of the FV login screen showing only the main admin account.
this has been escalated to the macOS engineering department for investigation and troubleshooting.
i have a follow up call with them on Friday and will update this post with the outcome and any additional info...

[bmarks]

@jacomaree Did you happen to get any additional info? We just tested this on 10.13.1 and we still see the same issues.

[bjones]

@bmarks I can concur i am having the same issues and it has not been resolved on 10.13.1

[Xtos]

Same issue here, very annoying issue.

My fix, and unfortunate that each machine needs manual attention, is :

1. Login as Local Admin
2. Add AD User to Filevault(you will need user to input AD Password)- Skip this step if you already added and rebooted and not seeing the AD User.
3. Log the Local Admin account out (Do not restart or shut down- just logout).
4. Now you should see the AD User(or Users list if multiple had signed in)
5. Login as AD USER. Then Log out(do not restart or shur down- just logout).
6. from the Login screen now reboot.
7. AD Users should now show up as an option to login in.

Additionally, and i dont know if this had any impact, I disabled the Guest Account and the Parental Controls.

This has thus far worked on a dozen machines that were having the issue of the AD Account not showing up after enabling FileVault, as well as adding the AD User to FileVault.

Hopefully it works for some here too.

shrug

Thanks

[jelagin]

We've been battling this for the past 24 hours as we just got our first machine with High Sierra preinstalled.

Our standard practice is to have users log in with their Active Directory credentials, create a mobile account, and then register their account in the FileVault control panel as authorized to decrypt. We've been ether getting an error when trying to add the user or no error, but the mobile account is not presented as an option to unlock the volume at boot

After trying every permutation of our configuration process we could think of, it appears that the missing piece of the our process was assigning an account picture (yes, like the kitty cat) to the mobile account.

Not sure why it works but it did for us. If you're banging you head against the Apple tree, worth a try.

[jacomaree]

hi @bmarks , @bjones i've recently changed jobs and have not had time to test this any further
last update i had from Apple was that the engineering team is still working on this (pre 10.13.1 release) and have not heard anything since...

one thing i did do to get this to work is using the ​ sudo fdesetup add -usertoadd username -usertoadd username -keychain and that seemed to have worked...

what i would advise, is log a support call with Apple. ask to speak to a senior advisor to get this escalated. word of warning, you do have to go through the 1st line process before they'll pass you over...

you'll have to submit logs etc for them to ponder over....

i'll start testing next week again and i'll update you guys with any updates i have...

[jalcorn]

Hey I just got this sorted for AD mobile users. I put mu solution here https://www.jamf.com/jamf-nation/discussions/26108/users-added-to-file-vault-but-don-t-show-up-to-un...

this has been driving me nuts.

[bmarks]

Our solution was different. Our Macs have a local admin created via DEP and then once logged in as the local admin, we run an AppleScript app that, among other things, creates the mobile user. To enable FileVault, our steps were as follows. These steps assume the mobile user has already been created:

1. While logged in as local admin, open Terminal and call the JAMF policy for enabling FileVault.
2. While still logged in as local admin, open FileVault System Preferences and enable FV for the mobile user.
3. Log in as mobile user and run another AppleScript app that we created that runs a script to disable FV for the local admin.*

The script that is run in step 3 is: fdesetup remove -user username

*This assumes you want to disable this functionality.

[alexkaloostian]

If I'm not mistaken... adding a mobile user to FV lets them decrypt the Mac... but this doesnt give them secureToken, so they cant DISABLE FV, nor can they ever ENABLE it again later. So if you delete the local admin that turned on FV, you've painted yourself into a corner?

Rather than logging in as the local admin and adding the mobile account to FV, I would log in as local admin and give the mobile account secureToken with

sudo sysadminctl interactive -secureTokenOn username -password -

Am I on the right track?

[MatG]

if this is the same error we have been seeing then we boot into the first account created on the Mac and run

sudo diskutil apfs updatePreboot /

[jakem]

@bmarks workaround is working for me!

[bmarks]

@alexkaloostian We don't care about those things, that's actually what we want in our environment. Our goal is to have only the mobile user be able to unlock the volume and we don't want the mobile user to be able to disable FileVault either. We also don't allow our users to add additional users to their Macs. So, as long as only the mobile user can unlock the Mac at boot and not disable FV afterwards, then we have met our environment's requirements. Consequently, we haven't tested any other scenarios. This is what finally worked for us after a ton of troubleshooting, but it may not work for every environment.

[bmarks]

The workflow I mentioned above is now broken in 10.13.2. When logged is as our local admin, we can no longer enable FV for any additional user, mobile user or not. When clicking the "enable" button, nothing happens other than a single log entry:

Unlock user (macinstaller) is not found.

(Our local admin is "macinstaller.")

[jacomaree]

@alexkaloostian try the following terminal command to enable FV2 encryption for users that's already logged in:
sudo fdesetup add -usertoadd username -usertoadd username -keychain . replacing "username" with the user's username
this worked for me on some occations
the other one you can try once all the users have been created / logged in is:
sudo diskutil apfs updatePreboot /

hope this works

[jacomaree]

@bmarks - please see my comment above

[geoffrepoli]

@jacomaree @bmarks

we're seeing the issue here as well on 10.13.2. the Enable Users button does nothing. the fdesetup command returns with an error Unable to add one or more users to FileVault. (-69594). The updatePreboot command also does not resolve the issue.

[bmarks]

This workflow still works for us but it briefly broke as of the 10.13.2 update. What we discovered is that we had to disable the "Hide account" checkbox for the initial local admin user that our DEP workflow created. It appears the 10.13.2 update will not allow a hidden local admin account to enable FV for the mobile user.

As a side note, a ticket to JAMF revealed that the DEP workflow uses the "hidden" user account attribute (as opposed to setting the UID to > 500): https://developer.apple.com/library/content/documentation/Miscellaneous/Reference/MobileDeviceManagementProtocolRef/3-MDM_Protocol/MDM_Protocol.html#//apple_ref/doc/uid/TP40017387-CH3-SW105

[kratliff]

@Xtos

Thank you kindly. That worked for me. Had the user sitting right here and used your exact method to get him up and running. Can confirm this issue on 10.13.3 and can also confirm Xtos' fix worked.

Posted: 11/8/17 at 8:32 AM by Xtos Same issue here, very annoying issue. My fix, and unfortunate that each machine needs manual attention, is : Login as Local Admin Add AD User to Filevault(you will need user to input AD Password)- Skip this step if you already added and rebooted and not seeing the AD User. Log the Local Admin account out (Do not restart or shut down- just logout). Now you should see the AD User(or Users list if multiple had signed in) Login as AD USER. Then Log out(do not restart or shur down- just logout). from the Login screen now reboot. AD Users should now show up as an option to login in. Additionally, and i dont know if this had any impact, I disabled the Guest Account and the Parental Controls. This has thus far worked on a dozen machines that were having the issue of the AD Account not showing up after enabling FileVault, as well as adding the AD User to FileVault. Hopefully it works for some here too. shrug Thanks

[easyedc]

Just throwing my 2¢ into this. Seeing this for the first time as we do our initial 10.13 rollouts, and running

sudo diskutil apfs updatePreboot /

seemed to fix the issue for us. I was able to do this remotely through an SSH connection, did not have to be a) local b) using local account.

[jacomaree]

@easyedc Yes, this does resolve the issue. Easy way of doing this going forward is to create a policy that runs at logout when the user is not your local admin admin account, ie you’ve just logged a user in and enabled their account to unlock FileVault.
Works great and takes an extra step out of the rollout process.

[easyedc]

@jacomaree It does work quickly and effectively, however, this is obviously something broken on Apple's part. If you have support, I suggest getting a ticket open for them to "gauge the impact" for engineering purposes.

[jacomaree]

@easyedc I worked with Apple for nearly 6 weeks on this when High Sierra was released by supplying loads of logs and trying various config changes and this is still broken in 10.13.3...
It will seem that Apple don’t regard this as a priority, otherwise it would have been fixed in 10.13.1...

[donmontalvo]

@easyedc wrote:

Just throwing my 2¢ into this. Seeing this for the first time as we do our initial 10.13 rollouts, and running

sudo diskutil apfs updatePreboot /

seemed to fix the issue for us. I was able to do this remotely through an SSH connection, did not have to be a) local b) using local account.

∞ Likes

[easyedc]

@jacomaree I need to add a signature to my profile to always add a line “please open a ticket with Apple...” Around here if something happens and the support team in question doesn’t have a ticket then it’s like it didn’t happen and they don’t care. I’m learning to take my own advice when it comes to Apple.

[easyedc]

It will seem that Apple don’t regard this as a priority

...and hence my ticket comment to the group.

[jconte]

I reported this issue back in the betas prior to public release, finally after 10.3.2 we were able to come up with the workaround. Seems like 10.13.4 beta 3 addresses this, still need to test more.

[JCS_Blue]

Seems fusion drives aren't supported by APFS and cause the same issue without any of the fixes working, has anyone seen this before I log an Apple ticket?

[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. But sometimes one account gets it and not the other.

Works perfectly 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.

[ChrisJScott-wor]

Still no joy on this - fresh install of 10.13 on a system, updated it to 10.13.4 and then enrolled in JAMF. Once encryption completed (via JAMF policy), the policy to add a FV2-enabled support account fired off. The account is created on the system but is not FV2-enabled.

[njavier]

OSX 10.13.4 will resolve this issue. Workaround with OSX 10.13.3 and below > Change user's default profile picture to one of the included images and reboot (don't know why this works)

[djtaylor]

I've been testing in 10.13.4 and the issue does not appear to be resolved. Still unable to make our admin account FV accessible without the messy process of adding the account and then running the above commands. Would love to get a nice GUI way of achieving this without having to run these commands from terminal. Anyone else found a better process?

[rodders]

thanks @easyedc this fixed it for me!
Going into the playbook and pinned in slack!

[ErikLehnsherr]

Make sure after FileVault is enabled you follow these instructions

1. Login as admin local account
2. Open System Preferences
3. Open Security & Privacy
4. Select FileVault - There should be a tab at Bottom of the window that says "Allow Users" . Any accounts added after FileVault need to be allowed or they won't show up at the login screen