FileVault User Add script Help

Treger
Contributor

Hi Everyone,

I have been given a script by JAMF to help with adding users to the FileVault list at login via a policy, we have a epic amount of Freelancers and they are not always the type to bring the machine back to have themselves enabled, they will then go on a shoot/leave the building and cannot access the machine.

Here is what I got from JAMF:

#!/bin/bash

####################################################################################################
#
# Copyright (c) 2013, JAMF Software, LLC. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
# Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
#
Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# * Neither the name of the JAMF Software, LLC nor the
# names of its contributors may be used to endorse or promote products
# derived from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY JAMF SOFTWARE, LLC "AS IS" AND ANY
# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL JAMF SOFTWARE, LLC BE LIABLE FOR ANY
# DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
####################################################################################################
#
# Description
# This script was designed to enable the currently logged in user's account the ability to unlock
# a drive that was originally encrypted with the management account using a policy from the JSS.
# The script will prompt the user for their credentials.
# # This script was designed to be run via policy at login or via Self Service. The encryption
# process must be fully completed before this script can be successfully executed. #
####################################################################################################
# # HISTORY
#
# -Created by Bryson Tyrrell on November 5th, 2012
# -Updated by Sam Fortuna on July 31, 2013
# -Improved Error Handling
#
####################################################################################################
#
## Self Service policy to add the logged in user to the enabled list
## of FileVault 2 users.

## Pass the credentials for an admin account that is authorized with FileVault 2
adminName=$4
adminPass=$5

if [ "${adminName}" == "" ]; then echo "Username undefined. Please pass the management account username in parameter 4" exit 1
fi

if [ "${adminPass}" == "" ]; then echo "Password undefined. Please pass the management account password in parameter 5" exit 2
fi

## Get the logged in user's name
userName=logname

## This first user check sees if the logged in account is already authorized with FileVault 2
userCheck=fdesetup list | awk -v usrN="$userName" -F, 'index($0, usrN) {print $1}'
if [ "${userCheck}" == "${userName}" ]; then echo "This user is already added to the FileVault 2 list." exit 3
fi

## Check to see if the encryption process is complete
encryptCheck=fdesetup status
statusCheck=$(echo "${encryptCheck}" | grep "FileVault is On.")
expectedStatus="FileVault is On."
if [ "${statusCheck}" != "${expectedStatus}" ]; then echo "The encryption process has not completed, unable to add user at this time." echo "${encryptCheck}" exit 4
fi

## Get the logged in user's password via a prompt
echo "Prompting ${userName} for their login password."
userPass="$(osascript -e 'Tell application "System Events" to display dialog "Please enter your login password:" default answer "" with title "Login Password" with text buttons {"Ok"} default button 1 with hidden answer' -e 'text returned of result')"

echo "Adding user to FileVault 2 list."

## This "expect" block will populate answers for the fdesetup prompts that normally occur while hiding them from output
expect -c "
log_user 0
spawn fdesetup add -usertoadd $userName
expect "Enter the primary user name:"
send ${adminName}
expect "Enter the password for the user '$adminName':"
send ${adminPass}
expect "Enter the password for the added user '$userName':"
send ${userPass}
log_user 1
expect eof
"
## This second user check sees if the logged in account was successfully added to the FileVault 2 list
userCheck=fdesetup list | awk -v usrN="$userName" -F, 'index($0, usrN) {print $1}'
if [ "${userCheck}" != "${userName}" ]; then echo "Failed to add user to FileVault 2 list." exit 5
fi

echo "${userName} has been added to the FileVault 2 list."

exit 0

And this is what I am getting from the logs when it runs:

Executing Policy FVUserEnable...
Mounting ldnlwwjss01.emea.corp.ipgnetwork.com to /Volumes/CasperShare...
Running script addCurrentUser.sh...
Script exit code: 5
Script result: Prompting room.one for their login password.
Adding user to FileVault 2 list.

Error: Authentication of FileVault failed.
Failed to add user to FileVault 2 list.

It seems to be failing when trying to return the user password saying that authentication failed, I have added the admin username and password into the JAMF policy on parameter 4/5 which is where I am assuming that adminName and adminPass are getting their info from.

Any help would be awesome! Thanks!

1 ACCEPTED SOLUTION

stevewood
Honored Contributor II
Honored Contributor II

Okay, rather than mess around with expect, you can try doing it the way I've done it, and that is with a plist file instead. Try this script and see if it works for you:

#!/bin/bash

####################################################################################################
#
# Copyright (c) 2013, JAMF Software, LLC. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
# * Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# * Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# * Neither the name of the JAMF Software, LLC nor the
# names of its contributors may be used to endorse or promote products
# derived from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY JAMF SOFTWARE, LLC "AS IS" AND ANY
# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL JAMF SOFTWARE, LLC BE LIABLE FOR ANY
# DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
####################################################################################################
#
# Description
# This script was designed to enable the currently logged in user's account the ability to unlock
# a drive that was originally encrypted with the management account using a policy from the JSS.
#   The script will prompt the user for their credentials.
#   
#   This script was designed to be run via policy at login or via Self Service. The encryption
#   process must be fully completed before this script can be successfully executed. 
#
####################################################################################################
# 
# HISTORY
#
#   -Created by Bryson Tyrrell on November 5th, 2012
#   -Updated by Sam Fortuna on July 31, 2013
#   -Improved Error Handling
#
####################################################################################################
#
## Self Service policy to add the logged in user to the enabled list
## of FileVault 2 users.

## Pass the credentials for an admin account that is authorized with FileVault 2
adminName=$4
adminPass=$5

if [ "${adminName}" == "" ]; then
echo "Username undefined. Please pass the management account username in parameter 4"
exit 1
fi

if [ "${adminPass}" == "" ]; then
echo "Password undefined. Please pass the management account password in parameter 5"
exit 2
fi

## Get the logged in user's name
userName=`logname`

## This first user check sees if the logged in account is already authorized with FileVault 2
userCheck=`fdesetup list | awk -v usrN="$userName" -F, 'index($0, usrN) {print $1}'`
if [ "${userCheck}" == "${userName}" ]; then
echo "This user is already added to the FileVault 2 list."
exit 3
fi

## Check to see if the encryption process is complete
encryptCheck=`fdesetup status`
statusCheck=$(echo "${encryptCheck}" | grep "FileVault is On.")
expectedStatus="FileVault is On."
if [ "${statusCheck}" != "${expectedStatus}" ]; then
echo "The encryption process has not completed, unable to add user at this time."
echo "${encryptCheck}"
exit 4
fi

## Get the logged in user's password via a prompt
echo "Prompting ${userName} for their login password."
userPass="$(osascript -e 'Tell application "System Events" to display dialog "Please enter your login password:" default answer "" with title "Login Password" with text buttons {"Ok"} default button 1 with hidden answer' -e 'text returned of result')"

echo "Adding user to FileVault 2 list."

# create the plist file:
echo '<?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>'$4'</string>
<key>Password</key>
<string>'$5'</string>
<key>AdditionalUsers</key>
<array>
    <dict>
        <key>Username</key>
        <string>'$userName'</string>
        <key>Password</key>
        <string>'$userPass'</string>
    </dict>
</array>
</dict>
</plist>' > /tmp/fvenable.plist

# now enable FileVault
fdesetup add -i < /tmp/fvenable.plist

## This second user check sees if the logged in account was successfully added to the FileVault 2 list
userCheck=`fdesetup list | awk -v usrN="$userName" -F, 'index($0, usrN) {print $1}'`
if [ "${userCheck}" != "${userName}" ]; then
echo "Failed to add user to FileVault 2 list."
exit 5
fi

echo "${userName} has been added to the FileVault 2 list."

## clean up
if [[ -e /tmp/fvenable.plist ]]; then
    srm /tmp/fvenable.plist
fi
exit 0

View solution in original post

39 REPLIES 39

Treger
Contributor

I forgot to say that we are using Active Directory accounts to log in with....

emily
Valued Contributor III
Valued Contributor III

Is there any reason you don't have the FileVault2 initialization use the Current or Next User for the FV2 user? You can always push a local admin account as another enable user via policy afterwards…

Treger
Contributor

The current and next user is already enabled but that only runs on the next current user and not on a rolling setup. We have so many freelancers that it is a huge manual procedure for us to keep following up with them to have their account enabled before they leave the building, we would be getting calls 24/7 for this issue....

Treger
Contributor

Sorry just to clarify that this script is run on an already encrypted machine with public keys and institutional keys already pre-defined it is literally to add the user account to the Filevault enabled users list...

stevewood
Honored Contributor II
Honored Contributor II

@Treger you said you're using AD for your users, are the users mobile accounts or not? If the user account does not exist on the local machine, FV will not add them. You can check to see if the users are there by simply using dscl to list the users:

dscl . list /Users

I would also verify on one system that the admin user/pass that you are using is in fact working. The error you are receiving, "Authentication of FileVault Failed" sounds more like an admin user/pass issue than an issue with the user.

Treger
Contributor

Hi Steve, yes they are mobile account enabled, however when I run that command I get <dscl_cmd> DS Error: (eDSUnknownNodeName) I will check the Admin account again, maybe I have put it in the wrong place...

stevewood
Honored Contributor II
Honored Contributor II

If you're getting an error running that dscl command, you might have bigger problems. That command lists the local users on your system and should return a bunch of users.

Treger
Contributor

Looks like it is re-imaging time... I think I have abused this teat machine a little too much.... I re-mated this morning to start fresh as I was having the same issue yesterday, let me re do it and try again....

mm2270
Legendary Contributor III

Be sure you've entered the dscl command in correctly. Make sure you have the spaces in the right locations as Steve posted.
Also, no trailing slash after /Users. Anything not exactly right can generate the DS Error.

Treger
Contributor

agh there got it put an extra / on the end.... DOH!

Treger
Contributor

Yeh still the same error, I have now set the parameters within the script on Casper Admin and it still saying authentication for FileVault failed.... and the user I am using is definitely enabled....

stevewood
Honored Contributor II
Honored Contributor II

I'm assuming you are doing this on a test machine. Have you tried manually running fdesetup to add the user as a test?

fdesetup add -usertoadd <username>

You can then remove the user with:

fdesetup remove <username>

Treger
Contributor

Ok, I have only been able to add it as root it not allowing me to remove it though, saying user not specified. I have even tried through System Prefs and its not having it....

stevewood
Honored Contributor II
Honored Contributor II

And if you do

fdesetup list

Does it show the user you just added? You should be able to remove that user using either Security pref pane or fdesetup.

Treger
Contributor

It shows up in the list... but ran the command again and it still says user not specified, I am typing fdesetup remove test.account just to confirm...

stevewood
Honored Contributor II
Honored Contributor II

My mistake, I had the syntax wrong:

fdesetup remove -user username

Try that.

Treger
Contributor

Ahh, good, shout, gone now....

Treger
Contributor

I have substituted the Admin for root now on the script and it still now having it....

Treger
Contributor

Question - when I define the Parameters in Casper do they need a " or '? Has anyone got an example for this? I have the Labels set fine but I am just concerned about they way I have defined the values...?

stevewood
Honored Contributor II
Honored Contributor II

I think I see where the problem might be. Are these machines all 10.9? I haven't verified this on a 10.8 machine, but on 10.9 your expect statement in the script would be wrong. In this block of code:

echo "Adding user to FileVault 2 list."

## This "expect" block will populate answers for the fdesetup prompts that normally occur while hiding them from output
expect -c "
log_user 0
spawn fdesetup add -usertoadd $userName
expect "Enter the primary user name:"
send ${adminName}
expect "Enter the password for the user '$adminName':"
send ${adminPass}
expect "Enter the password for the added user '$userName':"
send ${userPass}
log_user 1
expect eof

When you use the command "fdesetup add -usertoadd $userName" the response back by fdesetup is this:

Enter a password for '/', or the recovery key:

So the expect portion should be like this:

echo "Adding user to FileVault 2 list."

## This "expect" block will populate answers for the fdesetup prompts that normally occur while hiding them from output
expect -c "
log_user 0
spawn fdesetup add -usertoadd $userName
expect "*?or the recovery key:"
send ${adminPass}
expect "Enter the password for the added user '$userName':"
send ${userPass}
log_user 1
expect eof

You'll want to test that out, but I believe that is the right syntax for the expect statement. FV2 does not ask for the admin user, at least not in my environment, it simply asks for the password or recovery key for FV2.

You can test by manually running fdesetup like you did before and watch what the syntax is. When I run fdesetup I get the prompt asking for password or recovery key.

Treger
Contributor

Hi Steve, thanks for coming bad, yes they will be 10.9 machines I have tried this and it has returned on the policy log:

Executing Policy FVUserEnable...
Running script addCurrentUserEdited.sh...
Script exit code: 5
Script result: Prompting room.one for their login password.
Adding user to FileVault 2 list.
couldn't read file "the": no such file or directory
Failed to add user to FileVault 2 list.

Treger
Contributor

I am assuming that that is an issue with the expect "*?or the recovery key:" part of this, if I substitute that for Enter a password for '/', or the recovery key: Do you think that will resolve the issue?

stevewood
Honored Contributor II
Honored Contributor II

Okay, rather than mess around with expect, you can try doing it the way I've done it, and that is with a plist file instead. Try this script and see if it works for you:

#!/bin/bash

####################################################################################################
#
# Copyright (c) 2013, JAMF Software, LLC. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
# * Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# * Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# * Neither the name of the JAMF Software, LLC nor the
# names of its contributors may be used to endorse or promote products
# derived from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY JAMF SOFTWARE, LLC "AS IS" AND ANY
# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL JAMF SOFTWARE, LLC BE LIABLE FOR ANY
# DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
####################################################################################################
#
# Description
# This script was designed to enable the currently logged in user's account the ability to unlock
# a drive that was originally encrypted with the management account using a policy from the JSS.
#   The script will prompt the user for their credentials.
#   
#   This script was designed to be run via policy at login or via Self Service. The encryption
#   process must be fully completed before this script can be successfully executed. 
#
####################################################################################################
# 
# HISTORY
#
#   -Created by Bryson Tyrrell on November 5th, 2012
#   -Updated by Sam Fortuna on July 31, 2013
#   -Improved Error Handling
#
####################################################################################################
#
## Self Service policy to add the logged in user to the enabled list
## of FileVault 2 users.

## Pass the credentials for an admin account that is authorized with FileVault 2
adminName=$4
adminPass=$5

if [ "${adminName}" == "" ]; then
echo "Username undefined. Please pass the management account username in parameter 4"
exit 1
fi

if [ "${adminPass}" == "" ]; then
echo "Password undefined. Please pass the management account password in parameter 5"
exit 2
fi

## Get the logged in user's name
userName=`logname`

## This first user check sees if the logged in account is already authorized with FileVault 2
userCheck=`fdesetup list | awk -v usrN="$userName" -F, 'index($0, usrN) {print $1}'`
if [ "${userCheck}" == "${userName}" ]; then
echo "This user is already added to the FileVault 2 list."
exit 3
fi

## Check to see if the encryption process is complete
encryptCheck=`fdesetup status`
statusCheck=$(echo "${encryptCheck}" | grep "FileVault is On.")
expectedStatus="FileVault is On."
if [ "${statusCheck}" != "${expectedStatus}" ]; then
echo "The encryption process has not completed, unable to add user at this time."
echo "${encryptCheck}"
exit 4
fi

## Get the logged in user's password via a prompt
echo "Prompting ${userName} for their login password."
userPass="$(osascript -e 'Tell application "System Events" to display dialog "Please enter your login password:" default answer "" with title "Login Password" with text buttons {"Ok"} default button 1 with hidden answer' -e 'text returned of result')"

echo "Adding user to FileVault 2 list."

# create the plist file:
echo '<?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>'$4'</string>
<key>Password</key>
<string>'$5'</string>
<key>AdditionalUsers</key>
<array>
    <dict>
        <key>Username</key>
        <string>'$userName'</string>
        <key>Password</key>
        <string>'$userPass'</string>
    </dict>
</array>
</dict>
</plist>' > /tmp/fvenable.plist

# now enable FileVault
fdesetup add -i < /tmp/fvenable.plist

## This second user check sees if the logged in account was successfully added to the FileVault 2 list
userCheck=`fdesetup list | awk -v usrN="$userName" -F, 'index($0, usrN) {print $1}'`
if [ "${userCheck}" != "${userName}" ]; then
echo "Failed to add user to FileVault 2 list."
exit 5
fi

echo "${userName} has been added to the FileVault 2 list."

## clean up
if [[ -e /tmp/fvenable.plist ]]; then
    srm /tmp/fvenable.plist
fi
exit 0

Treger
Contributor

SUCESS!!! I did the plist option before but I it kept over writing my recovery keys. Thanks so much Steve!! you have saved me a world of hurt!!!

stevewood
Honored Contributor II
Honored Contributor II

Glad it worked. I should have had you try that yesterday. :-)

drew_duggan
New Contributor III
New Contributor III

Just a heads up with this script that there were changes to 10.10 and FileVault enablement, so this script won't work on 10.10 clients.

Treger
Contributor

HI there, yep it would appear that 10.10 has some differences, Derfiounder writes yup about it here https://derflounder.wordpress.com/category/filevault-2/ Hopefully Apple will sort it or it may be back to the drawing board with this... :(

mrcamuti
New Contributor II

Since I am just pretty opposed to giving up on an approach, I think the expect file works if you escapte the quotes for the expect commands, and then call the environment variables by name. In my testing, it looked something like this:

export LOCALPASSWORD
export USRNAME
expect -c "spawn sudo /usr/bin/fdesetup add -usertoadd "${USRNAME}"; expect ":"; send "Sekr3tPa$$W0Rd
" ; expect ":"; send "${LOCALPASSWORD}
"; expect eof"

edit notes: previous expect command had a dangling space after a semicolon, which was preventing matching

cwaldrip
Valued Contributor

Any updates on this working under Yosemite?

I'm curious to see if this will work, but haven't spent very long working through the script provided by @stevewood to figure out how to apply @mrcamuti's modification.

Treger
Contributor

Yosemite has actually really messed this up for me, we are getting to the stage where we are going to need to upgrade all of the hardware soon and now we are being forced for SOX compliance on this. The amount of freelancers we have is going to make this a living hell having to manage each user and machine manually...

Anyone ever get any breakthrough with Yosemite and auto enabling AD accounts?

cwaldrip
Valued Contributor

@Treger What we're planning on doing for now, and we haven't started our AD deployment just yet, is we have a non-admin local account. This is a backup account for users in the field who may not have authenticated to the machine but still need to use it. It's a non-admin account which has FileVault access. Fora user in the field they can log in and edit video and check web mail and upload files, but that's about it. But if they're in one of our offices they can use that account to unlock FileVault and then they can log out and back in with their NT account which gives them admin permissions and they can add their account to FileVault.

We'd rather have an AppleScript that they can use to enable their FileVault access than have them to the Security Pref Pane though.

Treger
Contributor

@cwaldrip for us, what I have done is on 10.9 the script in this post works great for auto enabling the user, they require to be on the network to log into the machine so on 10.9 it negated me having to have a local account for access, plus with the forked version of ADPassMon to sync the Keychain you loose the sync issues between that and the AD user accounnt password. Now with 10.10 the script does not work to auto enable accounts, I have options now one of them is what you mentioned above, however this comes with huge amounts of paperwork to be covered by SOX to make it compliant. So now I am stuck between having the manual labour of having to make sure each machine is setup or I am going to have stacks of paperwork to go through to cover SOX. I have not made my decision yet on which path I am going to take on this aspect but if I could get this script working on Yosemite I could dodge all these bullets... I am also still considering a backup account for access to the machine remotely but again, this I now have to take into account the SOX implications...

Treger
Contributor

The one issue I will state with the Apple Script is it is reliant on the user having the savvy to actually activate it, I don't know about you but mine are not so... I thought about serving a script through Self Service but I ran into the same issue where if the user "got busy" and forgot to enable thier account before leaving the building I am still going to get the offsite phone call to say "I cannot access my machine help me!!" at which point it would take up time again trying to explain how to access the machine, I went for the solid approach of just trying to get the whole process automated so we could avoid all the anguish.

mm2270
Legendary Contributor III

I'm a little confused here. Some of you are talking about this not working in Yosemite. Are you talking about the script from JAMF?
I'm asking because I have a similar script utilized in Self Service by users to fix their FileVault password sync problems under 10.10. Its using an input plist with fdesetup and works fine, but it does require that the user know and enter their password(s) to work. (Using cocoaDialog to capture that)
So, what exactly doesn't work anymore here?

Treger
Contributor

Hi @mm2270

The part that is not working anymore is the script from JAMF that @stevewood modified to work in the AD environment, The Keychain issue is not really the end of the world, as I said with the forked version of ADPassMon this should resolve that part of it for me...

msallen
New Contributor

I came into an environment that had over 60 machines that needed the local account added to FV access and they all had different individual encryption keys. Thankfully, the keys are in the JSS. This post was a huge help in writing that script. Thanks!

mkweskin
New Contributor

A slight modification to stevewood's solution. Instead of writing the .plist to a file you can pipe to fvesetup thereby avoiding writing the passwords to a file:

echo '<?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>'$4'</string>
<key>Password</key>
<string>'$5'</string>
<key>AdditionalUsers</key>
<array>
    <dict>
        <key>Username</key>
        <string>'$userName'</string>
        <key>Password</key>
        <string>'$userPass'</string>
    </dict>
</array>
</dict>
</plist>' | fdesetup add -i

HNTIT
Contributor II

I am using the script marked as the answer in this thread but i have a problem, I can't imagine I'm the only one with this issue.

The lines that check if the user is enabled ...

userCheck=fdesetup list | awk -v usrN="$userName" -F, 'index($0, usrN) {print $1}'

Kind of falls over if there are multiple users with similar names.

The Scenario I am facing is this...... the following users are FV Enabled but the script gets confused when Fred logs in.
Fred
FredC
FredH

As it returns multiple names to the string, I am trying everything I can think of to mod this line to make it look for the exact name and the exact name only, but nothing seems to yield the exact results i need.

Anyone offer any help on this ?

HNTIT
Contributor II

as an addendum, what order the usernames appear in the userCheck string also makes a large difference as well.

HELP !!!