FileVault - enable with a 2nd account

[Taylor_Armstron]

Banging my head against this all day today, and haven't found a solution that works the way I want.

Scenario: We are required to log on with smart-cards, so we've always used FV, with a restricted non-admin account that is allowed to "login" at the FV boot screen. The users then insert their smart-cards at the normal login screen and all is good.

Now I'm trying to write a policy, or policies, to do this in Casper.

The catch: In my Encryption Configuration, I can select either the management account, or "Current or Next user". No option there to enable a different account.

So I try to do it in the policy itself. I can apply the encryption config w/out any issues. I can create a new local account, and I can check the box to enable for FV2, but it fails because "FV2 is off" - aka it can't add the user until AFTER FV2 kicks in at restart.

I then thought that perhaps I could do an authenticated restart as part of the policy, and kick off the new account creation after the reboot via a custom trigger, but the authenticated restart doesn't seem to work on the 1st reboot (although generally seems to work afterwards).

Thoughts?

TLDR version:
Need to turn FV2 on, create a local account, and enable it, all as either one policy, or two policies that trigger off of each other.

[Taylor_Armstron]

Just a quick edit - I know the clarity of the original post suffered a bit :)

Essentially what I want to do COULD be accomplished in the command line via "sudo fdesetup enable -" and listing both the management account and the "FV-Boot" account. I REALLY don't want to have to script this and put passwords into the script (a non-starter in this environment).

[Josh_S]

We have a method that we use to do this as an initial provisioning task. It's kludgy, but it works as long as you have a valid individual recovery key and know the user's password that you want to enable (which can be changed later). You can use the API to write a different user value to the 'management_username', and 'management_password' for this computer object, then kickoff a policy which enables FileVault for the management account.

After it reboots, you can do the same thing to restore the initial values. I don't know if this will work for you, as it is kludgy and a little complex. There's also security concerns that have to be mitigated somehow, writing passwords to scripts and having the password to a JSS account which has write access to computer objects. You could potentially prompt for these values.

[iJake]

The non-admin account you use to login with for FV2, is that a set password or do the users' of the machine choose the password?

Either way, you should be able to script this and either pass the password if know as a script parameter from the policy, assuming your JSS is locked down enough for this, or prompt the currently logged in user for the password of the account that will be FV enabled. You have to work with fdesetup in a script via Expect scripts since it is interactive only.

Let me know if that makes sense and I'd be happy to help with Expect if you need.

[Taylor_Armstron]

Thanks Josh and Jake - those ideas give me some direction.

We're fairly security-focused, so a PW in a script usually won't pass an audit, but I hadn't thought of the option of setting a different management account temporarily - that may be a work-around that will suffice. Given a choice between a kludgy solution that would (ideally) require an on-site admin to type in a PW, vs. having laptops in the wild unencrypted, I'll take kludgy every time. Even if I can't fully automate it, having a semi-obnoxious alert in the user's face prompting them to have their on-site support come over and enter PW's... might still get me closer to the goal of 100% compliance.

[jason_bracy]

Just thinking off the top of my head, but could you use a Configuration Profile to turn on FV instead? Are you using Institutional or individual keys?

[Taylor_Armstron]

Using both (indie + institutional) at the moment. Have some other issues to work through though - looks like we have a certificate issue or other problem blocking MDM on most machines, so I haven't looked at config profiles much until I get some time to figure that problem out.

Main issue is that no standard user accounts have passwords - all CAC/PIV auth. For new machines, no issues, but problem is enforcing it on the laptops that slipped through the cracks, and we're only finding out NOW that they're not properly encrypted. Looks like we're basically just working down that (fortunately short) list one by one, enforce it, call on-site staff and give them the recovery key, then enable the other account. Would have been nice to automate it, but it isn't the kind of thing that we SHOULD need to do on a regular basis.