Skip to main content
Question

FileVault2 with JSS

  • September 29, 2016
  • 4 replies
  • 19 views

Forum|alt.badge.img+3

I'm trying to test the use of FileVault 2 with El Capitan machines.
Created Disk encryption configuration with Individual recovery key and it works fine. I have many systems which are already FileVault 2 enabled before enrolled with JAMF. I'm looking for best way to get them FileVault 2 compliant against my JAMF policy easily. JSS version 9.82 and Enabled fileVault 2 user is "Current or Next user". I was trying to assign new recovery key to 1 of the MAC but it got failed. Already checked articles 11580 and 8996

So I was thinking, Adding Management account as Enabled fileVault 2 user (script can work) then assign new recovery key might work in this case. If somebody has gone through with this issue please let me know.

4 replies

flyboy
Forum|alt.badge.img+12
  • Valued Contributor
  • September 29, 2016

@srathore see this post. It sounds a lot like what you're trying to do. You'll have to add your JSS management account user to FileVault before you can re-issue recovery keys. Once you've re-issued the key you can remove the management account from FileVault.


Forum|alt.badge.img+3
  • Author
  • New Contributor
  • September 30, 2016

HI,

in this situation my management account password is set for "randomly generated passwords", so I can't enter management account password in the script. And I am not that experienced in Apple scripts to make them user interactive. Could you please help me out a little bit to make that script user interactive and to bypass management account password dependency or if you have any other option in this case.


flyboy
Forum|alt.badge.img+12
  • Valued Contributor
  • October 3, 2016

Due to the way FileVault 2 is architected, to make changes on an encrypted computer you have to have one of the following two things:

  1. Individual Recovery Key stored in the JSS
  2. JSS Management account has to be a FileVault 2 User

Unfortunately, the only way to get the Individual recovery key stored in the JSS is to either use a JSS policy to encrypt the device, or to use the management account to generate a new key that is then stored in the JSS.

Off the top of my head, the only way to deal with your issue would be to build a policy workflow using a script and a set of policies that have custom triggers.

For example:

  1. Create a policy that changes the management password to a known value and give it a custom trigger like "knownmgtpass"

  2. Create a policy that issues a new individual recovery key and give it a trigger like "newIndKey"

  3. Create a policy that changes the management password to an unknown value and give it a custom trigger like "unknownmgtpass"

  4. Create a policy that removes the management account from FileVault and give it a custom trigger like "FVremovemgtacct"

  5. Create a policy that runs the script that manages your workflow

Add your known management account information to lines 33 & 34, then your workflow script would look something like this:

#!/bin/bash

###  WARNING:  USE THIS CODE AT YOUR OWN RISK AND TEST IN A DEVELOPMENT ENVIRONMENT BEFORE RUNNING IN PRODUCTION!
###  YOU, AND YOU ALONE ARE RESPONSIBLE FOR CONSEQUENCES FROM IMPROPER TESTING!!!!!

### NOTE: There is no error checking in this script to see if the username entered is a valid FileVault user.


## Call policy to change the management account password to something we know
jamf policy -event knownmgtpass



TMPDIR=${TMPDIR:-/tmp}                          # defaults to /tmp if unset 

#-------------------------------------------------------------------------------
# Creates a particular temporary directory inside $TMPDIR.
#-------------------------------------------------------------------------------
TEMPORARY_DIR=$(mktemp -d "$TMPDIR/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX") || 
    { echo "ERROR creating a temporary file"; exit 1; }

    #-------------------------------------------------------------------------------
    # When the program exits, it tries to remove the temporary folder.
    # This code is executed even if the process receives a signal 1,2,3 or 15.
    #-------------------------------------------------------------------------------
    trap '[ "$TEMPORARY_DIR" ] && rm -rf "$TEMPORARY_DIR"' 0

    touch $TEMPORARY_DIR/tempfile                   # new tempfile inside folder

PLIST_TEMP=$TEMPORARY_DIR/tempfile

## Set variables for management account details
MGTUSER="" ##Enter management account username here
MGTPASS="" ##Enter management account password here

## Prompt the user for their existing FileVault credentials and use them to build the XML we need to add the management account to FileVault.

USERNAME=$(osascript -e 'set DIALOG_1 to the text returned of (display dialog "Username: " default answer "")')
USERPASS=$(osascript -e 'set DIALOG_2 to the text returned of (display dialog "Password: " default answer "" with hidden answer)')

## Build Plist 

cat <<-EOF > $PLIST_TEMP
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Username</key>
<string>$USERNAME</string>
<key>Password</key>
<string>${USERPASS}</string>
<key>AdditionalUsers</key>
<array>
    <dict>
        <key>Username</key>
        <string>$MGTUSER</string>
        <key>Password</key>
        <string>${MGTPASS}</string>
    </dict>
</array>
</dict>
</plist>
EOF

## Add Management account user to FileVault
 /usr/bin/fdesetup add -usertoadd $USERNAME < "${PLIST_TEMP}"

## Call policy to issue new Individual Recovery Key
jamf policy -event newIndKey

## Call policy that removes management account from FileVault
jamf policy -event FVremovemgtacct

## Call policy that changes management account back to an unknown value
jamf policy -event unknownmgtpass

Forum|alt.badge.img+1
  • New Contributor
  • October 4, 2016

This tool seems like it'll do exactly what you want.