Well, it's a little more of a "buckshot" approach instead of a "tactical strike," but I modified /etc/authorization such that only users in the "wheel" group can unlock the Security & Privacy prefpane. (Only root is in the wheel group.)

'at'll do.

Jared, do you mind sharing where you made the changes?

FYI - That's not the only place where FileVault 2 can be turned off in the GUI.

If you launch Disk Utility while booted from an encrypted drive, you can select your boot drive, then select Turn Off Encryption... from the File menu. It'll prompt you for a password, but the password of any account that appears at the FileVault 2 pre-boot login screen will work here. Once the password's been accepted, it'll start decrypting.

Jared, do you mind sharing where you made the changes?

Nope:

<key>system.preferences.security</key>
        <dict>
            <key>allow-root</key>
            <true/>
            <key>class</key>
            <string>user</string>
            <key>comment</key>
            <string>Checked by the Admin framework when making changes to the Security preference pane.</string>
            <key>default-button</key>
            <dict>
                <key>ar</key>
                <string>??? ?????</string>
                <key>ca</key>
                <string>Desbloquejar</string>
                                 ......
                                 ......
                                 ......*Ooodles of localization entries.*..
                                 ......
                                 ......
                <key>zh-Hant</key>
                <string>__APPNAME__ ??????“??????”?????</string>
            </dict>
            <key>group</key>
            <string>**admin**</string>
            <key>shared</key>
            <false/>
        </dict>

Change that admin to wheel or some other group.
**

rich
Yeah, I'm realizing just like with anything else, there's more than one way to skin a cat with decryption. Perhaps this is one of those things that 10.8 will bring. I should dig into that tomorrow. It's not up to me, unfortunately. This is one of those things that keep Risk guys up at night in a financial company. There's got to be only authorized users that can decrypt a machine. I wonder if I could actually tweak /etc/authorization such that to even use diskutil you'd need to be in the wheel group...

<<dr. evil finger to lips>>

I'll report on this tinkering tomorrow.

anybody have good news about there being a policy setting to prevent this in 10.8?
i could just remove the security preference pane like i do with iCloud. and I have yet to be able to decrypt any drive through the graphical disk utility. So, I doubt many average users would figure it out.
diskutil from the command line however is a great way to undo encryption.

As of 10.8.4, Apple added the need for admin authorization in order to decrypt with diskutil:

http://derflounder.wordpress.com/2013/06/07/standard-user-accounts-in-os-x-10-8-4-now-blocked-from-decrypting-filevault-2-encrypted-macs/

That change did have one side-effect though:

http://derflounder.wordpress.com/2013/06/11/decrypting-filevault-2-on-mac-os-x-10-8-4-unlock-first-then-decrypt/

But bottom line is, there is really no effective way to prevent an admin user, especially one that is an authorized FileVault user on the system, from decrypting their drive, right?
We're struggling with this as well. We've been considering blocking the Security & Privacy pane in System Preferences, but we're reluctant to take that step just yet. I wish I could only block the FileVault tab itself from being accessed. I'd even be cool with disabling it for everyone, including IT, since we have other methods of accessing FileVault encryption information.
I know that disregards the diskutil aspect of decrypting, but it would be a good step since most users will try to decrypt from the Preference Pane.

You can force encryption with an Apple profile. Once it is encrypted, the turn off file vault button greys out.

Any way to grey out the turn off filevault button without a config profile?

Why is a config profile a showstopper? Create one, and install it using the /usr/bin/profiles command.

https://github.com/gregneagle/profiles/blob/master/cant_disable_filevault.mobileconfig

and

http://managingosx.wordpress.com/2014/05/21/preventing-users-from-disabling-filevault-2/

@gregneagle The config profile to grey out the Turn off FileVault button has a bug in it, where users cannot change their local account passwords on their Mac's, which is a show stopper for me. JAMF Support has a work around but it does not work. This is why I'm trying to disable it without that profile.

Appreciate the links that you sent, unfortunately it did not work. I uploaded it to Casper and pushed it to my computer but the Turn Off FileVault button is not greyed out. Not sure why it didn't work, Casper may have stripped it once it uploaded. I'll keep messing with it, see if I can't get it to work, even if I have to install without MDM.

Sounds like it might be Casper's fault, as the profile works as expected when installed manually (double-clicking it) or via the /usr/bin/profiles command.

@gregneagle So installing it locally without Casper, it disables the Turn Off FileVault BUT if I upload and push through Casper, it does not work. :( Not sure why but still playing, thought I would just update you on that.

@oneloveamaru I'm seeing the same with version Casper 9.31. If I upload and push through Casper 8.73 it works as expected. I sent a support request to JAMF to see what might be causing this.

@golbiga Awesome, thanks for letting me know. Let me know what you find out and i"ll hold off on sending in a ticket of my own.

@gregneagle @golbiga 9.31 is altering the setting from /true to /false when uploaded, i have no idea why and Support isn't helpful at all. I was told if I Upload a signed profile Casper wouldn't edit it but i don't have the capability or time to do that right now.

Any ideas on how to take that 1 setting of "dontAllowFDEDisable", turning it into a plist file and then uploading it to Casper to the Custom Settings part of the config profile ? I'm not sure what the plist should look like for that to work.

Any help would be GREATLY appreciated!

If it were me, I'd side-step Casper's profile support entirely, since it's just getting in the way. I'd build a package that installed the profile (perhaps using Tim Sutton's tool here: https://github.com/timsutton/make-profile-pkg), then have Casper install the package, which I'd hope it could do without too many issues.

I have a smartgroup for Macs that have FileVault enabled with email alerts. So within a couple of days of someone turning off FileVault, that person will be having a little chat with HR.

@corbin3ci I do have a smartgroup already so I know when someone turns off FileVault but I want to make it harder for that to happen.

@gregneagle @golbiga I was able to create a plist with the settings I need to grey out the "Turn off FileVault" button and push them out through Casper with the Custom Settings in the Config Profile. Works perfectly!

I'll just leave this here...

https://jamfnation.jamfsoftware.com/featureRequest.html?id=2013

The Config Profile support is pretty weak in the manual settings department. JAMF removed fully-custom settings management in one fell swoop by nerfing MCX and Manual Config Profiles simultaneously. This was one of the most powerful aspects of Casper 8 and the reason that we're still running it!

why not make your own custom config profiles and upload them?

@nessts PITA to manage. I have to keep those somewhere outside of the JSS, modify them outside the JSS and re-upload them whole-hog any time I need to make a minor modification (such as plugin policy management).

This assumes that uploading a custom config profile doesn't break it, which - as evidenced above - is not a safe assumption.

@JPDyson I voted up your feature request the other day. I do agree it's a PITA to manage custom settings. This is one of the big drawbacks to using Casper for MDM.

If you enable filevault with a profile using an institutional key, it will not only will grey out the disable profile button (once the drive is fully encrypted), but is also disables a user's ability to decrypt at the command line. Even if an admin tossed a Sudo fdesetup disable command. They will receive a message that says it has been disabled by a systems administrator.