FileVault 2 - lockout nightmare

[GregE]

Hi all,

Apart from giving up on FileVault 2 for High Sierra, I've been testing it in Sierra 10.12.6 with success.

Unfortunately I deployed it via Policy to a local Lab (24 iMac's) which students use (mobile AD accounts).

4 of them have logged in, kicked off the disk encryption when prompted, then either forgotten to log off, or restarted the iMac's and walked away.

This boots the iMac to their login screen (with their username), however the iMac is waiting for the reboot to complete before:
1. Checking in with the JSS (so the JSS Recovery Key doesn't work).
2. Checking in with LDAP (so resetting the students password also doesn't work).

As the device isn't checking in with anything, recovery key and password changes aren't working, there aren't any other FileVault enabled users who's password I can use (apart from the student who is now in another city), and I can't run any commands in terminal (I assume it's locked down with FV2 as well?).

I've been plugging along with Jamf Support without success, but was wondering if anyone else had any suggestions for a scenario like this?

Cheers!

[nvandam]

Could you have the students log back on?

[sdagley]

@GregE Unless you have some absolute requirement to enable FileVault on lab machines you probably do NOT want to do it. When you have FV2 enabled you will have NO access to a machine without a user logged in (with FV enabled you're essentially booting into the recovery partition waiting for FV2 credentials to be entered to unlock the drive and boot into the normal OS partition, and nothing is going talk to the Mac remotely until then).

By all means use an EFI/firmware password on those machines.

[GregE]

Unfortunately I can't have all the students log back in. Some will make their way on campus, others were here for exams and have gone off to another city.

So pretty much the short answer is - unless the person who initiated FV comes back on campus - there's no possible way to get back in to the Mac?

It's a bit frustrating that the Recovery Key in the JSS doesn't work, as the point of that was to avoid situations like this.

[sam_g]

@GregE I think the real question though is figuring out why you want to do this. Even in Sierra, you have to manually add new users to have permissions to unlock with FileVault. Assuming you're able to encrypt them all correctly without any issues, in the future do you really want to work 1 on 1 with each student who sits down at a different iMac and add them to the list of FileVault users?

You're creating a ton of work and issues for yourself for no real benefit, unless you are concerned that 1) the iMacs might walk away and 2) there is sensitive data on the iMac that needs to be preserved. If those two concerns are real, then you should be approaching this with another tool instead of FileVault.

[AVmcclint]

I have to agree with the others on this one. FileVault should never be used in a lab or classroom setting. If you ABSOLUTELY MUST have FileVault in the classroom or lab, then the local admin account should be enabled to unlock the drive. You're still asking for a world of hurt when it comes time to do mass updates in the after-hours or during breaks between semesters. My suggestion is to just cut your losses and remove the FileVault policy then re-image the Macs that you can't get into. If it's only 4 computers, consider yourself lucky.

[GregE]

Thanks for the input all. I'm definitely only encrypting staff Mac's (not shared) and not student labs. The above happened as I have a student lab on my campus and deployed FileVault to it as Part B of my testing. Long story we'll be encrypting Mac's and Windows drives University wide for theft/data security reasons as you mentioned above @float0n.

So in short - lab deployment definitely won't be happening!

I have made some progress though. Retrieving the FileVaultMaster.keychain that was set up on the server and copying to a USB, I've managed to follow this "If a user can't log in to their iMac" guide to get the drive unlocked.

The current roadblock is what to do then. I can't re-image it as it says "FileVault Conversion in Progress", and I can't run any commands (like sudo fdesetup disable) in terminal as everything I've tried retrieves a "command not found". Restarting re-locks the drive, so I'm now trying to work out how to get around a non-completed FV encryption but with an unlocked drive.

[sdagley]

@GregE You didn't mention if you're going to use EFI/firmware passwords on your student Macs. You definitely want to as it's trivial for them to get admin access to the Mac (now that you're not using FV2) if you don't.

[GregE]

Thanks for the suggestion @sdagley I'll get on to that.

Issue has pretty much been resolved now. Copy the FileVaultMaster.keychain from the server to a USB, then use the above linked guide to unlock the drive, then Disk Utility to format it and re-install the OS.

Should probably look in to blocking clients from encrypting their own drives, as without the master keychain we'd be left with replacing hard drives.

[sdagley]

@GregE Even if a drive is encrypted with FV2 you can still reformat it. If you use an EFI/Firmware password you can prevent that (short of pulling the drive out of the Mac)

[GregE]

Yeah it wouldn't allow a format as 'un-mounting' the drive required authentication.
And it wouldn't install over the top either. I believe it was just bad circumstance where it was still 'mid encryption' pending that final restart. I would have assumed the JSS would sync the Recovery Key as soon as it's kicked off, but I guess if they restart prior to the 15 minute check-in - it gets missed.