Disabling FileVault for Users

[rquigley]

I work in education and we have roughly 750 machines across 3 campuses.

My issue is really two but on the same issue.

The first one is students are given Administrator access, this is largely fine and we have little issues with them, however, they are able to encrypt their HDD, occasionally they come in with issues and we are left with the issue of having to tell them that encrypting their HDD is slowing us down from resolving their machine and that it will need to sit overnight to decrypt.

Is there a way without removing the Recovery Partition or removing Administrator access to lock off the FileVault button, not all of Security & Privacy. It doesn't have to be completely broken, if a user wishes to use it, they probably will but most of our machines are encrypted because of our second issue.

With their update to Yosemite, they are asked to Turn On FileVault encryption. With it already ticked, they simply continue through and we are left with the same situation. Is it possible at all to remove the Setup Assistant in this instance to prevent students from encrypting their HDD without them understanding what is really the cause behind it?

Thanks.

[rderewianko]

The easiest would be to disable FileVault from the Security and Privacy Tab. (as this is where i'd expect my users to find it first). Unfortunately, there's a few other places that encryption can be turned on/off.In the os & in the recovery partition.

To disable the Security and Privacy setting on the os. Create a config profile that allows access to all preferences but that one. At the same time, just for ease of use "Enable FileVault FileVault Recovery Key Redirection". The JSS will then collect keys when your users do encyrpt.

[bentoms]

@rquigley I'd second @rderewianko's FV key redirect option.

That should give you another way to decrypt.

BUT, the rest would need to be looked at at a people policy level.

Unless you encrypted all.. Or just added the management account to FV2 on those with FV2 enabled.

Paging @rtrouton in case he has any other ideas. (He probably will, better too & with links & everything....).

[rtrouton]

If the machines you're buying are enrolled in Apple's DEP, there should be an option in DEP to remove that screen from Setup Assistant:

https://derflounder.wordpress.com/2014/10/25/new-filevault-2-enablement-option-in-yosemites-setup-as...

Who owns the machines in this particular instance? Is it the school or are these the students' personally-owned machines?

[gregneagle]

I think you should adjust your policies and configuration to make it easier/possible to work on these machines with FileVault 2 enabled, and encourage your students to enable FileVault 2. Earlier replies have laid out some of the available options.

[rquigley]

The machines are sadly not in DEP as it's something that hasn't been looked at by the school, I will be looking into that though.

As for who owns them, we own them until the student decides or doesn't, to purchase them at the end of their run.

The key redirect option does look like a possibility. Luckily we only have 4 machines with it enabled but on the occasion they pop in, I hate having to ask them for their password as it's bad policy.

[gregneagle]

I'd also consider enabling your own local admin account for FV2. This way you can do your troubleshooting/maintenance/repair using your local admin account and not need the user's password.

[roiegat]

I'll chime in as well with a suggestion. While creating a configuration profile to disable the system panel would work 99% of the time, I always like to think about that 1%. A simple google search will show you how easy it is to re-enable a disabled panel. So you could still have some users who would still encyrpt their machines. The solution we came up with is to move the panel (located in /System/Library/PrefrencePanes/Security.prefPane) to a hidden folder we created somewhere else on the drive. While removing it completely would be good as well, we wanted the ability for our tech to be able to re-enable it if needed as well. So hiding works well.

But you also have a bigger issue if you have lots of machines that are currently encrypted and you don't have the keys. I agree with the folks above by settings up the redirect just in case they do re-activate it.

Dealing with FV2 is no fun matter...I wish you much luck

[nessts]

FYI, if you go with @roiegat solution, you need to have a launchdaemon that watches the path since system updates will put it back. Also, anybody willing and able to google an answer for the preference pane, they likely can lookup how to use fdesetup or diskutil to do all of this as well.

[roiegat]

@nessts Your right, given enough time your can get around anything. But I find that if you annoy people just enough, they'll give up. So by moving the panel all together hopefully will annoy someone enough to move along.

Now if you really want to annoy them, hide the terminal app.

[rtrouton]

@rquigley,

How are these machines being set up for these students? The reason I'm asking is that, if the school owns them, my assumption is that you or a colleague are setting them up for your students' use.

If that is the case, why are the students seeing Setup Assistant at all? There are ways to suppress Setup Assistant as part of a managed setup process.

I realize that every shop has their own procedures, but I'm genuinely puzzled as to how the students are seeing the Setup Assistant unless the students are just being handed an unconfigured laptop.

[Olivier]

I don't get what you mean with "encrypting their HDD is slowing us down from resolving their machine and that it will need to sit overnight to decrypt."?

You can access and perform any troubleshooting steps without the need to decrypt any disks. Why do you have the need to decrypt disks?
Nobody from our IT staff performs decryption of any FV disks, as any IT-support task can be done by either having FV recovery key (stored in JSS in our case), or the user to type in his password when needed. Once the disk is unlocked state, you can perform as if the disk was never encrypted, no?

[rquigley]

@rtrouton

The machines are set up by staff but they were setup for 10.9. We want to be able to open the flood gates to 10.10 but we aren't able to since it auto-ticks Disk Encryption, something we want to avoid at all costs.

We want the users to be able to update without them having to come in and do it for them, a policy in Self Service being something more desirable.

If we can get a simple script that simply doesn't run SetupAssistant on the other side and simply skips it to get the user logged in as normal, we can push it ahead but we're simply having an issue doing just that.