Skip to main content

We have a policy in Jamf that applies a disk encryption configuration defined in Jamf Pro's settings. (Settings \\ Disk encryption configurations)

We also have a device that needs to run the built-in guest user, but not in Safari-only mode that is enforced when FileVault is on. FIleVault has already been enabled via that policy on this particular device.

Based on a test, it seems that if we disable FileVault, it will just turn it back on per that policy that previously ran & applied the disk encryption configuration.

Short of wiping the device and not applying that policy, is there a way to clear out that configuration as-is, to prevent FileVault from turning back on?

 

@ajc196 You can exclude that specific computer from your policy (under Scope->Exclusions) that enforces FileVault

@ajc196 You can exclude that specific computer from your policy (under Scope->Exclusions) that enforces FileVault


Correct, but the policy has already run on this device at least once. Even if it never runs again, the settings are already enforced.. FileVault automatically enables all over again once disabled.

Correct, but the policy has already run on this device at least once. Even if it never runs again, the settings are already enforced.. FileVault automatically enables all over again once disabled.


@ajc196 Did you enable FileVault via a Policy, or via a Configuration Profile? You can also exclude a Configuration Profile via Scope->Exclusions, and once the profile is removed you'll be able to disable FileVault (you may need to restart before disabling works though)

@ajc196 Did you enable FileVault via a Policy, or via a Configuration Profile? You can also exclude a Configuration Profile via Scope->Exclusions, and once the profile is removed you'll be able to disable FileVault (you may need to restart before disabling works though)


It's a policy that applies a disk encryption configuration, not a configuration profile.

I understand I can exclude devices from either so they don't run in the first place, but the device in question has already run the policy and applied the disk encryption configuration to the device. An exclusion after-the-fact won't stop FileVault from enabling itself again in this scenario.

It's a policy that applies a disk encryption configuration, not a configuration profile.

I understand I can exclude devices from either so they don't run in the first place, but the device in question has already run the policy and applied the disk encryption configuration to the device. An exclusion after-the-fact won't stop FileVault from enabling itself again in this scenario.


@ajc196 If FileVault was enabled via a Policy, and that Mac is no longer in scope for that policy, you _should_ be able to manually disable FileVault and it will stay turned off.

@ajc196 If FileVault was enabled via a Policy, and that Mac is no longer in scope for that policy, you _should_ be able to manually disable FileVault and it will stay turned off.


That's what I had assumed as well, but it is not the case. FileVault re-enables itself at the next trigger defined in that policy's disk encryption configuration. (which is "at next login" for us)  I just disabled FileVault and rebooted on a spare device in my office, and this is still true -- At next login it required FileVault to be turned back on.

So once the policy applies the disk encryption config, it's set & enforced on the device whether the policy does or doesn't run again, is or isn't in scope, etc. Obviously wiping the device and excluding the policy from running is a "fix", but I wanted to see where under the hood in macOS could I keep FileVault from turning back on without starting the device over from scratch.

 

That's what I had assumed as well, but it is not the case. FileVault re-enables itself at the next trigger defined in that policy's disk encryption configuration. (which is "at next login" for us)  I just disabled FileVault and rebooted on a spare device in my office, and this is still true -- At next login it required FileVault to be turned back on.

So once the policy applies the disk encryption config, it's set & enforced on the device whether the policy does or doesn't run again, is or isn't in scope, etc. Obviously wiping the device and excluding the policy from running is a "fix", but I wanted to see where under the hood in macOS could I keep FileVault from turning back on without starting the device over from scratch.

 


@ajc196 I think you'll need to open a case with Jamf Support on this one as there is nothing in the Jamf Pro docs for FileVault configuration via policy docs that covers removing it, and Google isn't turning up anything useful either (this thread is one of the top hits)

I came across the very same issue this week.  Found that I can revert the Policy changes by pushing a Configuration Profile -> Security & Privacy -> FileVault -> User adjustment of FileVault options = "Prevent end user from enabling or disabling FileVault"

It reverted the majority, but I had another coinciding issue being that auto-login was also set.

Running 'sudo fdesetup disable' in terminal as an admin user assisted with this and cleaned the remainder up. Note: even though Terminal cmd replies with 'FileVault is already disabled', it still actually does something to remove the recurring trigger from Jamf.

I came across the very same issue this week.  Found that I can revert the Policy changes by pushing a Configuration Profile -> Security & Privacy -> FileVault -> User adjustment of FileVault options = "Prevent end user from enabling or disabling FileVault"

It reverted the majority, but I had another coinciding issue being that auto-login was also set.

Running 'sudo fdesetup disable' in terminal as an admin user assisted with this and cleaned the remainder up. Note: even though Terminal cmd replies with 'FileVault is already disabled', it still actually does something to remove the recurring trigger from Jamf.


Kudos for your post here @jamph , Was just dealing with this reprompting for FV2 after excluding from policy, and running the 'sudo fdesetup disable' turned it off for good.

Terms & ConditionsCookie settings