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
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:
If we use "sudo fdesetup list" we see the AD user accounts, we then add the AD accounts with "sudo fdesetup add -usertoadd <ADUserName>"
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
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
@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.
we initially need to set the securetoken to our local admin account that the JSS creates.
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
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.
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...
Same issue here, very annoying issue.
My fix, and unfortunate that each machine needs manual attention, is :
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.
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.
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...
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.
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:
The script that is run in step 3 is: fdesetup remove -user username
*This assumes you want to disable this functionality.
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?
@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.
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.")
@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
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
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
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.
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.
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...
Just throwing my 2¢ into this. Seeing this for the first time as we do our initial 10.13 rollouts, and runningseemed 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.
sudo diskutil apfs updatePreboot /
@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.
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.
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?
Make sure after FileVault is enabled you follow these instructions