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
@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.
!/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
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.
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...
@jacomaree Did you happen to get any additional info? We just tested this on 10.13.1 and we still see the same issues.
@bmarks
I can concur i am having the same issues and it has not been resolved on 10.13.1
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
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...
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:
- While logged in as local admin, open Terminal and call the JAMF policy for enabling FileVault.
- While still logged in as local admin, open FileVault System Preferences and enable FV for the mobile user.
- 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.
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?
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 /
@bmarks workaround is working for me!
@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
@bmarks - please see my comment above
@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.
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
@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
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.
@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.
