FileVault Key Redirection - Don't Ask User Whether to Store Key on Server or Not Save to Server

Edit: Scratch that. You're redirecting, not applying.

I forgot to mention that the payload is the "Automatically redirect recovery keys to the JSS" option, not the manual one. I'd also like to say I have been trolling around looking for the answer I'm asking about and not having much success.

We do this and don't see that pop up ... our profile is computer level. Stock straight built with the JSS.

However we lock out the user's ability to decrypt the drive with a profile, So I am guessing that hides the pop up too.

C

Hi Gachowski,

I really appreciate your input. I am curious about your locking out the user's ability to decrypt. In your Config Profile are you using the "Create individual recovery key" checkbox in the "Require FileVault 2" area, or are you doing some sort of custom profiling? If it's custom, may I see an example?

Thanks,
-Craig

The block is custom...

Preference Domain is com.apple.MCX
Property List File is dontAllowFDEDisable=true

For the encryption we are using "Disk Encryption Configurations" in the JSS set to "Create individual recovery key" and Set to current or next user. Then a policy calls that "Configuration" and we trigger that policy in a log in script.( This is from the 1st Jamf paper on how to deploy Filevault)

Hope this helps : ) if you need more info let me know : )

C

@heiden As you know, implementing FileVault 2 can take different forms depending upon different variables, such as requirements and the admin's personal preferences and experiences. That being said, one useful tutorial that touches upon a few aspects in this thread, like the redirection, can be found at https://www.johnkitzmiller.com/blog/how-i-deploy-filevault-2/

Hi SeanA,

I did see that article before, John's set up is slick. I like it.

The problem I'm currently trying to solve is not one of that all machines (or some group of machines) will have FileVault enforced. In my environment there are users that have admin privileges on their Macs, and not all machines will be required to use FileVault. What I'm trying to get a hold of is the scenario of a local admin manually triggering FileVault encryption on their machine and then ensuring that recovery key gets sent to the JSS.

I'm beginning to truly think that what I'm trying to do is not possible, that the end user in this particular scenario will have the choice to redirect the recovery key to the campus JSS or not to do so. I know this sounds pessimistic, but I really think the majority of the faculty will choose to not redirect the recovery key. <sigh>

Of course, there are other ways to possibly handle this. For example, the machines could be divided into two groups, one that will get FileVault and the other group won't. For the won't-get-FileVault group access to the FileVault screen could be disabled, etc., so admin-level end users don't encrypt their machines. The other group, naturally, would have the enforced encryption with the recovery key redirect, which many people have implemented (John Kitzmiller, for example, and various JAMF Nation folks).

Still, it would be nice to have the key redirect just sent the recovery key to the JSS. Then we wouldn't have to worry about all the ways it is possible to begin the FileVault encryption process.

Thanks,
-Craig

Our users don't see that popup either. Are you trying to enable FileVault as well with a config profile?

The reason I mention the FV config profile is because it seems like a lot of people try to go this route, but if you look at JAMF's official white paper on administering FileVault, they don't mention using the config profile. Instead, the process involves setting up the Disk Encryption Configuration settings under Computer Management and then using a policy to apply that configuration to your Macs. The white paper can be found here:

https://www.jamfsoftware.com/resources/administering-filevault-on-os-x-el-capitan-with-casper-suite-version-9-81-or-later/

There are versions for other OS's too, but they're all basically the same.

If you are already doing it this way, great. If not, I would encourage you to modify your method. This is also covered in a couple of the JAMF classes as well.

This is how we are doing it and I wonder if this might be the variable that is leading you to see those popups.

Hi bmarks,

I appreciate your tips and I've read the white paper before. I can't really change the method as what I am trying to solve is not a "complete encryption solution" as described in the white paper, if that makes sense. The desire is that if an admin-level user, completely on their own and without the knowledge of IT, goes into the System Preferences and enables FileVault that the recovery key is only sent to the JSS. That's where the pop-up comes from.

The scenarios in white papers and/or the Casper Admin Guide to not apply here. It's true that if the key redirection and the key creation/FileVault encryption are handled programmatically the end user doesn't see a pop-up, as has been described by many people. But those situations don't handle faculty triggering the encryption process on their own and then the university can't access the key (because the person didn't record the key, lost the paper used to write it down, or have it escrowed to their personal AppleID). It this situation we very likely would lose the data on the machine, which creates a business continuity issue.

The redirect is useful in the sense that it at least gives the person the option to send the key to the JSS. But it's the second choice and frankly I don't think the end users are likely to choose sending the recovery key to the JSS. That's why I simply want the recovery key sent to the JSS without any question or interaction from the end user.

As an aside, removing the administrative permissions for the end users really is not an option. Yes, I'd like that to be a viable option. But really, when that is suggested and the faculty say no, then the dean of the department defers to the faculty (as is very likely), then removing admin privileges is DOA. To possibly help explain the situation for those not in higher education, a quote from Henry Kissinger (a former Harvard faculty member) is telling: "University politics are vicious precisely because the stakes are so small." Sometimes simply getting a machine to be enrolled into Casper is like pushing string uphill, let alone the pain point of discussing admin permissions. But I digress....

Thanks,
-Craig

Hello, As has been noted the FileVault redirect configuration profile set to redirect to the JSS gives the end user the OPTION to send it to the JSS or store locally when manually encrypting via System Preferences, as seen in the screenshot above. This is intended behavior. But if the encryption or recovery key issuing is kicked off via command line with the fdesetup binary it will respect the redirect and send keys automatically to the server specified in that configuration profile. If you force encryption via the Configuration Profile or via the policy payload from the JSS you don't see this prompt, only when end users initiate it via System Preferences.

There is no way that I am aware of to force end user initiated encryption via System Preferences to automatically be sent to a specified server. This would likely have to be a request made to Apple. You can use the Restrictions payload in configuration profiles to block access pane in system preferences, essentially disabling end user initiated encryption entirely, unless they initiate via terminal, which again would respect the redirect profile and get sent to the JSS.

Although none of JAMFs current White Papers list that redirect profile as part of our FileVault workflows, it is recommended by our Support, IT, Security, Pro Services, Field Services and Education Services departments to use it in conjunction with the encryption process due to the values it adds. We plan to have it added to the white paper in its next revision. It is also required for different workflows such as re-issuing keys or enabling users for FileVault when the JSS doesnt have an individual key or the management account currently enabled for FV.

So if you are not going to enforce encryption via the JSS and you dont want to block access to that functionality via a configuration profile you may have to accept that people will encrypt their computers and may choose not to have the keys sent anywhere at the time of creation.

But just because the people didnt encrypt with the JSS doesnt mean you cant get the keys in the JSS or your management accounts fv2 enabled as long as you are alright with prompting the end user for their password.

If you use the redirect profile in conjuction with the Reissue Individual Key script scoped to computers with an Invalid Individual Key, end users are prompted for their password, it kicks off "fdesetup changerecovery -personal", the keys sent to JSS, with an update inventory the computer no longer shows invalid for the key in the JSS and you are good to go.

The list of all our FileVault Scripts can be found on our JAMF Support github.

Note: Currently in 9.93 their is a known issue with the FileVault redirect payload that also enables auto-logout after 30 minutes of inactivity. This is noted in the Release Notes

@mike.paul I was typing up that exact same workflow that you mention at the end of your post. That was the only thing I could think of as well.

I will describe what we do just in case but I don't think it is relevant. We create a tiny AppleScript app that we place on the user's Desktop and tell them to use this option if they want to enable FileVault. Because it's just calling the normal policy you'd already have in place, the only prompts the user sees are the password prompt and the logout prompt. However, the only way to enforce this workflow would be to block access to the Security & Privacy pane.

Also, has the JAMF script been updated with the changes made to the MacBrained script? I know we abandoned our use of JAMF's script because the MacBrained one resolved an issue with policy triggers and the popups being properly displayed. Our TAM was actually giving us the MacBrained script for awhile:

[https://github.com/homebysix/misc/blob/master/2015-01-27%20MacBrained%20Reissuing%20FileVault%20Keys/reissue_filevault_recovery_key.sh](MacBrained Script)