Skip to main content

Hey all,



I'm running into some issues with how Casper handles FileVault 2 encryption, and I'm hoping the community can provide some suggestions. I'll list them in order of which I'd like to get resolved first:




  1. Macs enrolled (either via Imaging or QuickAdd) do not seem to reliably report their inventory information back to the JSS. Hardware, OS info, Applications and the such all appear to be reported accurately, but a Smart Computer Group with the criteria "FileVault 2 Partition Encryption State is Encrypted or FileVault 2 Partition Encryption State is Encrypting" is always empty as the partition encryption state always becomes "Unknown" once encryption has finished. However, I can still see the recovery key under the management tab for systems that have successfully encrypted via the JSS. The goal here is to have an ongoing policy to enable FV2, unless the computer is a part of the "already encrypted" smart group.


  2. In our environment, when we enable FV2 for users, we enable both our management account and the user's account. Casper only gives the option for one or the other. The users should definitely be able to unlock their own drives or they have very expensive paperweights upon restart. The management account should also be able to do this in a pinch, though if we have the key, this is less important. Still, convention dictates that we should be able to do both and I haven't been able to find an easy way to do so.


  3. We have a number of Macs out in the wild that are already encrypted, and I suspect that simply enrolling the computer and getting its inventory information will not give us the recovery key associated with it. We have an Excel spreadsheet (yay) containing a list of the Macs we have encrypted along with their recovery keys. Is there an easy way to import this information into the JSS? If not, what's the best way of going about getting all recovery keys stored in the JSS?




The second two may be large enough to warrant their own threads, but I'll see what happens.



Thanks in advance!

As far as I know...



1) I have something similar to what you are asking, and it is working. I have a smart group that list all machines that are not encrypted and only offer FV2 to this group. Here's the logic:



FileVault 2 Status "IS" No Partitions Encrypted
AND FileVault 2 Partition Encryption State "IS NOT" Encrypting.



2) You can create a script that will do this, but you'll need to reset the password before to a known password in order to accomplish this.



3) No.


  1. Use a custom Extension Attribute to capture FV2 status, as many of us do, rather than the built-in criteria. You may get better results. I built my own that reports items like "Encrypting, Decrypting, Encrypted, Not Encrypted, or N/A" (in the case of 10.6 and under)


  2. Not certain about this since we only enable the user, not our management account, but I would have to think this is possible to do. It might be the order that you need to switch up. Check out Rich Trouton's blog for information as he may already have a solution in place. http://derflounder.wordpress.com


  3. You assume correct. The Recovery Key is only captured when its initiated from Casper. Although 10.9 added some ability in fdesetup to regenerate a Recovery Key, I don't think it would be possible to programmatically regenerate a key if you don't already manage FV2 from Casper on those Macs. Your only option may be to decrypt and re-encrypt them with your Disk Encryption policy.


You may need to talk with JAMF's support folks about your third question, but I may be able to help with questions 1 and 2.



For 1 - One of the available criteria available for smart groups is FileVault 2 Status. It can show the following results:



All Partitions Encrypted
Boot Partitions Encrypted
N/A
No Partitions Encrypted



If you want an "already encrypted" smart group, I'd recommend using the FileVault 2 Status group and set it to look for machines reporting Boot Partitions Encrypted.



For 2 - Casper is using Apple's fdesetup tool for its encryption management, so Casper's capabilities are governed by what fdesetup supports. In all cases but one, fdesetup requires that the account being enabled have its password supplied as part of the enablement process.



The one exception is fdesetup's deferred enablement , which allows a user account to be selected for enablement before FileVault 2 is actually turned on for the drive being encrypted. An important thing to keep in mind about the –defer option is that it enables one single user account at the time of turning on FileVault 2 encryption. The –defer option does not enable multiple user accounts and cannot be used to enable accounts once FileVault 2 encryption has been turned on.



For more details on fdesetup and Mavericks, please see the link below:



http://derflounder.wordpress.com/2013/10/22/managing-mavericks-filevault-2-with-fdesetup/



If you have 10.8 Macs, please see the link below for how fdesetup works on Mountain Lion:



http://derflounder.wordpress.com/2012/07/25/using-fdesetup-with-mountain-lions-filevault-2/



In Casper 9.x, there's two options available for when setting up Disk Encryption Configurations.




  1. Management user - this uses fdesetup's enablement options to turn on FileVault 2 and enable one user account, the management account. The reason it can do this is that the JSS knows the password for the management account.


  2. Current or next user - this uses fdesetup's deferred enablement options to enable FileVault 2 for either the currently logged-in user or the next one who logs in. The reason that it only does that one account is because fdesetup's –defer option only works to enable one account when you're turning FileVault 2 on.




If you want to enable the management user, you can do that after the fact by setting up a script to do this and adding it to a Casper policy. That said, on Mavericks, you will need to provide either the password of a previously-enabled account or (if available), the personal recovery key in order to enable the account. For more details on this, please see the link below:



http://derflounder.wordpress.com/2013/10/24/enabling-users-for-filevault-2-with-a-non-enabled-admin-user-does-not-work-in-mavericks/



Another option is to wait until encryption has finished, then create a new user on the machine with a Casper policy and have that account enabled for FileVault 2. If you take a look at the Local Accounts options in a Casper 9.3.x policy, under the Create Account action, you'll see a checkbox for Enable user for FileVault 2.



If you haven't seen them previously, I recommend that you take a look at JAMF's white papers on FileVault 2 management as they've got a ton of good info. They're available from the link below:



http://www.jamfsoftware.com/resources/administering-filevault-2-with-the-casper-suite/

Thanks for the responses everyone.




  1. I think I'm going to have to create a custom attribute here as @mm2270 mentioned. The problem isn't so much creating the group as it is that the group doesn't have accurate information to work off of. The JSS isn't retrieving info about whether or not FV2 is enabled, even though it has the key.


  2. Given the information here, I think we'll probably just enable the user. As long as we have the recovery key, I don't see a whole lot of circumstances where it will save us a lot of time to have the management account enabled. Thanks @rtrouton for the detailed description.


  3. I'll get in contact with my JAMF rep, but as I was fearing, @ctangora may be the most accurate answer here... I'll likely have to hack some policies together to re-encrypt as @mm2270 suggested.




Cheers!

@mdealmeida - you need to be aware of one other thing. Since the FV2 status is just like any other piece of criteria that only gets captured during a full inventory collection, what you may be seeing in regards to inaccurate info could be related to the fact that inventory collection didn't happen directly after FV2 was enabled, and so Casper simply may not have received that updated info.



We combat this with a pkg that we add to our Disk Encryption policy that kicks off a full recon after reboot. Its run by a local LaunchDaemon and script. The script checks first to see if it can see the internal network or our JSS. If so, it runs a full recon, and if successful, self destructs by deleting the Daemon and the script (itself) so it won't run again. If it can't see the internal network or cannot connect to the JSS, it exits silently. The LaunchDaemon runs every 5 minutes until its successful.
We throw the LaunchDaemon and script into a Composer package and throw that package into our Disk Encryprion policy, so after it runs and the end user enables it, it installs the package. The Mac reboots and the Daemon is now active until it successfully recons the Mac, then blows itself up.



Outside of something custom like this you could also just turn on a policy that collects inventory on Startup or login, but we chose not to go that route since its only needed in certain cases, like enabling FV2.

Thanks @mm2270 - we have a policy that's running inventory collection on a daily basis (for testing, this will probably be dialed back to weekly or less), but it still doesn't seem to be working the way we'd like it to for this purpose. I'm guessing you run the package with the daemon after restart since there's no other way to ensure it runs AFTER encryption through the normal methods of executing scripts?

That's correct. It gets installed along with the Disk Encryption policy, then, assuming the user complies and enters their password and reboots to enable FV2 (not all of them do right away) after reboot it collects inventory. This has 2 effects. One, combined with the custom EA, we get reports on which Macs have FileVault enabled very soon after it begins, and two, it ensures that the Recovery key gets scooped up from the disk into the computer's record in Casper. We've had some weird cases where Macs that started encryption somehow never get the Recovery key picked up into Casper, which could cause big problems later if you need to get into the Mac.

Similar to @mm2270][/url but more experimental, I’ve set up inventory-only policies that run when a computer falls into a Smart Group. To get hourly inventory checks, my best idea so far is:



Once per day (on policy-check in intervals).



Client-side limitation: Do not run between 9 AM and 8 AM (in effect: do run between 8 AM and 9 AM). This sounds strange but in my testing, it works.



Duplicate this policy and slide the client-side limitation to the next hour.



The trick is that I think you must to do the final step to duplicate the policy for as many recon runs as you want across the desired timeframe. If you want an inventory policy to run (approximately) hourly every hour, I haven’t thought of a way to get that without multiple non-overlapping policies scoped a Smart Group. Perhaps someone else is more clever or has figured that out. (For that reason — to reduce the number of policies you create/maintain — you may not want to set up hourly recon runs. That means you won’t get the dogged determination that you can achieve with a LaunchDaemon running every 5 minutes, but you can see/change/scope the policies via JSS.)



YMMV as to whether you think this is a better or more maintainable solution compared to a LaunchDaemon.

Terms & ConditionsCookie settings