Activating FileVault2 at imaging time (with a pre-created user)

Andreas,

I don't think there is, I think the issue is on Apple side. I think what we need is very tricky because it's really trying to "inject a user in FV2" and I am sure Apple is worried about this... I have an open ticket with Apple for a zero touch deployment method : )

Rich Trouton is the expert with FV2 stuff, check out all his posts

http://derflounder.wordpress.com

I 2nd the advice of checking out Rich's blog on all his FV2 stuff. Other than the FileVault developers at Apple, Rich is pretty much an authority on it. Lots of good stuff there to read up on and learn.

That said, the only real option when deploying FileVault 2 encryption configurations using Casper is to use the Casper Suite management account as the first and primary FileVault 2 enabled user. But this isn't a great solution since it means several things-
1- The management account will show up on the FV2 pre boot login screen. No way around that as it stands today
2- You still have the issue of adding in additional users to the authorized FileVault 2 unlock settings, unless you planned on giving out your management account password to everyone. (hopefully you aren't!)

The second issue can somewhat be solved now with 10.9 and Casper Suite 9 I believe, but I don't know enough about the new functionality (check Rich's blog). I do think you can run policies against it to add additional users in. as long as you are using the management account as the FV2 user. I may be wrong on that though.

Also, to be clear, you can't turn on FileVault while in an imaging state, It has tot be done after the Mac reboots into its new OS.

I just went through this. If you start googling, you'll end up at Rich's blog anyway, so, ya, go there. He's as famous to me as Tom Cruise (but way cooler?).

You can scope policies to an encrypted machine smart group, so that you image, encrypt, then a policy lays down the remaining can-only-live-on-encrypted-drives content. Might something like that work?

In Casper 9.2x and 9.3, the best Casper-specific resource is going to be this white paper from JAMF:

http://www.jamfsoftware.com/resources/administering-filevault-2-on-os-x-mavericks-with-the-casper-suite-version-9-2-or-later/

Page 27 - 30 discusses creating local users and enabling them for FileVault 2 as part of the account creation process, or disabling existing local users. There is not currently an option within Casper for enabling an existing user aside from the Casper management account.

I have the FileVault 2 posts on my blog assigned to their own category, so using this link may help speed up searching if someone needs something specific on FileVault 2 but doesn't know the right keywords to search on:

http://derflounder.wordpress.com/category/filevault-2/

First off, I would say that anything that would require you to know the user's password is "bad process" and should be avoided like the plague. You can't really enable FV2 for a user before they've logged in. What I do is make sure it gets enabled within a day or two of system deployment as a catch-all if our techs haven't set it up when the system is handed over, or if the user decrypts it themselves later.

I run this script on a daily basis against systems that are not encrypted. It executes a trigger policy that enables FV2 once it runs some checks, then as part of a separate policy, the user gets reminded once per day that they need to log out and enter their password.

#!/bin/bash
#

# FV2 Enable
# Runs basic checks, if FV2 is not active or deferred and current user is not admin, enables FV2

log() {
if [ "$1" ]; then
    echo "$1">>$logPath
fi
}

DATESTAMP=`date`
logPath="/var/log/Deployments/FileVault2.log"
if [ ! -d "/var/log/Deployments" ]; then
    mkdir "/var/log/Deployments"
fi

log "Running FV2 Enable - $DATESTAMP"
log "Computer name: `hostname`"

currentUser=`ls -l /dev/console | awk '{print $3}'`
isUserLoggedIn=`who | grep console | grep $currentUser`

# Quit out if administrator is logged in
if [ $currentUser = "administrator" ]; then
    log "administrator logged on, exiting"
    echo "administrator logged on, exiting"
    exit 0
fi

FVStatus=`fdesetup status`

# If FV is already on, exit
isOn=`echo $FVStatus | grep "FileVault is On"`
if [ "$isOn" ]; then
    log "FileVault is On. Exiting."
    echo "FileVault is On. Exiting."
    exit 0
fi

# If FV is in a deferred state already, exit
isDef=`fdesetup status | grep Deferred`
if [ "$isDef" ]; then
    log "$isDef"
    defUserResult=`echo $isDef | awk '{print $9}'`
    strLen=`echo ${#defUserResult}`
    defUsername=`echo "${defUserResult:1:$strLen-3}"`
    log "$defUsername is already set as the deferred FV user. Exiting."
    echo "$defUsername is already set as the deferred FV user. Exiting."
    exit 0
fi

# if FV is encrypting, exit
isEnc=`echo $FVStatus | grep "Encryption in progress"`
if [ "$isEnc" ]; then
    log "$FVStatus"
    echo "$FVStatus"
    exit 0
fi

# if FV is decrypting, exit
isDec=`echo $FVStatus | grep "Decryption in progress"`
if [ "$isDec" ]; then
    log "$FVStatus"
    echo "$FVStatus"
    exit 0
fi

# Make sure user is logged on
if [ ! "$isUserLoggedIn" ]; then
    log "Current console user is not logged on"
    echo "Current console user is not logged on"
    exit 0
fi

log "$currentUser currently logged in"

# All checks passed, enable FV2 for currently logged in user
log "Executing FV2 enable policy"
triggerResult=`jamf policy -trigger enableFV2`
sleep 5
FVStatus=`fdesetup status`
log "$FVStatus"
echo "$FVStatus"

Wow, all of this is very helpful - thanks!

I agree on the principle that requiring knowledge of the user's password is a problem. Since we set the user up at imaging time (and they enter their password then), I was hoping (apparently in vain!) that Casper Imaging could use that information to activate FV2 for them right away. Oh well.

I'll dig through your FileVault2 posts, thanks Rich! (I actually stumbled over a few while googling this very issue). (-:

Also, thanks a lot for the hint on a filevault-enabled smart group. That would be a great solution to this, even if it results in a slightly less-optimal experience for the user - get machine, log in, log out, enable filevault, download all the things. But even so, still better than leaking secrets!

Thanks again all, I'll report back what we'll end up doing.

This is possible, I've been doing this in production for about a year now. You can enable a 'mobile' user for FileVault 2 access without ever knowing their password. However, it does pretty much require you have another way in, either a recovery key or another user that is enabled, since no password will work for the enabled account until they log into the computer for the first time so you may need another way in.

Unfortunately, the method I'm using is completely unsupported and may even be considered exploiting a bug - however it is not actually a security risk so I'm hoping Apple doesn't "fix" it, without providing a supported way to accomplish the same.

A quick, supported, way to accomplish something similar is to turn on FileVault 2, enabling a different local or mobile account. Do what you need to do on the, now, encrypted hard drive. As one of the last steps of the deploy process, have the assigned user enter their password to enable their account to unlock the drive. Delete the originally enabled account, or give that account a blank password. Both of which will disable the "temporary" user from continuing to be able to unlock the encrypted drive. If you give the account a blank password (your management account?) you can reset it manually or via Casper without re-enabling it for FileVault.

Package this up, test and put on your NetBoot image to unlock :) https://github.com/jridgewell/Unlock