Skip to main content

We are having a terrible time with filevault and want to find out if there was some kind of definitive guide to its implementation.  Right now we are binding and using AD accounts (Implementing Connect in 2024.  Would love to hear if this would help our situation) to login.  When a user changes their password it seems like we need to disable filevault, to reset the password and then reenable filevault otherwise the changing the password through system prefs doesn’t work.  And end users can’t disable filevault this because they aren’t local administrators.

 

Questions and issues I have:

Are we supposed to use a policy or a configuration profile in Jamf Pro to enable it?  Pros and cons?

We have shared Macbooks that we need to be able to logged into by new users on a regular basis.  How do we enable that new user to automatically get access to a filevault encrypted drive? Based on this should we be using an institutional key or a personal key, or does that not even matter? 

What is the impact if any if we turn on filevault from system preferences while we are delivering a new device to a new user.  Will Jamf Pro still try to escrow the key?  If not, is there a script to force that to happen?

How are we supposed to update filevault when a user changes their password?  Is there any difference if you are using AD accounts on a bound device vs using local accounts with Jamf Connect?

Yeah, the problem comes down to your use of those cached AD mobile accounts. When the password for those accounts happens outside of the operating system, like thru a company password change portal or someone updating it directly in AD, FileVault has no way of knowing the password was changed, and when it gets synced down over AD, it doesn't trigger the background FV2 sync process to sync the new password into the FileVault space. And you end up with a mismatch.


So to answer one of your questions, yes, there is a big difference when using AD accounts on a bound device versus using local accounts, whether you use Jamf Connect or the built in Apple SSO Kerberos plug-in. In the latter situations, when the password is changed from the Jamf Connect menu or from the Apple Kerberos menu, it triggers a sync back to FileVault, so it knows what the new password is right away.


As far as escrowing the Recovery key, you need to ensure you have a profile pushed to those Macs that has the key escrow option enabled. This will ensure that even if someone, like a tech, manually turns on FileVault, that the recovery key will be sent back to Jamf. If that profile option is not in place, Jamf won't be able to escrow the recovery key. You'll find that option under the Security & Privacy payload in a Configuration Profile.


Lastly, regarding your shared MacBooks, I'm gonna be honest, FileVault is not a good choice for such a scenario, and you will have more trouble trying to have that in place on those devices than it's worth dealing with. There's no simple or easy way to auto add in new users who might sit down at an encrypted Mac and be allowed to log in. Because of how FileVault works, it's really best in a 1:1 scenario and not a shared device one. So I don't have any good advice for how to achieve what you're after there.

Yeah, the problem comes down to your use of those cached AD mobile accounts. When the password for those accounts happens outside of the operating system, like thru a company password change portal or someone updating it directly in AD, FileVault has no way of knowing the password was changed, and when it gets synced down over AD, it doesn't trigger the background FV2 sync process to sync the new password into the FileVault space. And you end up with a mismatch.


So to answer one of your questions, yes, there is a big difference when using AD accounts on a bound device versus using local accounts, whether you use Jamf Connect or the built in Apple SSO Kerberos plug-in. In the latter situations, when the password is changed from the Jamf Connect menu or from the Apple Kerberos menu, it triggers a sync back to FileVault, so it knows what the new password is right away.


As far as escrowing the Recovery key, you need to ensure you have a profile pushed to those Macs that has the key escrow option enabled. This will ensure that even if someone, like a tech, manually turns on FileVault, that the recovery key will be sent back to Jamf. If that profile option is not in place, Jamf won't be able to escrow the recovery key. You'll find that option under the Security & Privacy payload in a Configuration Profile.


Lastly, regarding your shared MacBooks, I'm gonna be honest, FileVault is not a good choice for such a scenario, and you will have more trouble trying to have that in place on those devices than it's worth dealing with. There's no simple or easy way to auto add in new users who might sit down at an encrypted Mac and be allowed to log in. Because of how FileVault works, it's really best in a 1:1 scenario and not a shared device one. So I don't have any good advice for how to achieve what you're after there.


Thanks for the feedback.  It used to be that we would instruct the users to go to system prefs to change their password.  This had been working just fine.  But now it seems to only work if we disable FV2, change the password and then reenable it.

That is a shame about the shared devices.  Does anyone know of any 3rd party disk encryption tools for MacOS?

Thanks for the feedback.  It used to be that we would instruct the users to go to system prefs to change their password.  This had been working just fine.  But now it seems to only work if we disable FV2, change the password and then reenable it.

That is a shame about the shared devices.  Does anyone know of any 3rd party disk encryption tools for MacOS?


There is no 3rd party disk encryption tool that supports booting a Mac with an encrypted user partition.


Is your use case that requires AD mobile accounts that you want multiple users on a Mac? Or just that you want your Mac users to be using AD based accounts? If the latter, and you are using on-prem AD then the Kerberos SSO tool will provide that capability (as well as generating Kerberos tickets for the user)

Reply


Terms & ConditionsCookie settings