Recurring Check-in vs. sudo jamf policy

[bmarks]

I have a policy that calls a script. It is a script JAMF provided that prompts the user for their password, generates a new individual FileVault key and uploads it to the JSS. I have this policy set to "recurring check-in."

However, users (who are all admins on their Macs) are never shown the popup asking for their passwords when their Macs check in on their own and the logs for the policy indicate that the script failed because the users never entered their passwords.

But, here's the odd thing. If, on one of these same Macs, I type "sudo jamf policy" which calls all the policies set to recurring check-in, then the user IS prompted for their password and, when entered, the script completes successfully.

This is on a JSS running 9.81 and a Mac running El Capitan. But, I'm pretty sure the behavior is identical on a Yosemite Mac too.

Thoughts?

[jrippy]

How are you running

sudo jamf policy

?

You may have looked at this already, but I would guess it has something to do with the recurring check-in running as the root user and not the logged in user. If that's the case, the script would need to somehow get the current user (lots of ways to do this) and then run the script in the user context. You can do that with

sudo -u $user script.sh

or some other method for AppleScripts, etc.

[Simmo]

I'd recommend trying it on a Yosemite machine, just to be sure. Could be a SIP thing.

Could you link the script?

[Look]

Agreed link the script. User interactions are quite different went called by root vs when called by the user with sudo. Things like osascript calls to the Finder can be used to ask the current user for information pretty easily when running as root.

[bmarks]

Lemme resubmit that...

[bmarks]

#!/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
#
#   The purpose of this script is to allow a new individual recovery key to be issued
#   if the current key is invalid and the management account is not enabled for FV2,
#   or if the machine was encrypted outside of the JSS.
#
#   First put a configuration profile for FV2 recovery key redirection in place.
#   Ensure keys are being redirected to your JSS.
#
#   This script will prompt the user for their password so a new FV2 individual
#   recovery key can be issued and redirected to the JSS.
#
####################################################################################################
# 
# HISTORY
#
#   -Created by Sam Fortuna on Sept. 5, 2014
#   -Updated by Sam Fortuna on Nov. 18, 2014
#       -Added support for 10.10
#       -Updated by Sam Fortuna on June 23, 2015
#           -Properly escapes special characters in user passwords
#
####################################################################################################
#
## Get the logged in user's name
userName=$(/usr/bin/stat -f%Su /dev/console)

## Get the OS version
OS=`/usr/bin/sw_vers -productVersion | awk -F. {'print $2'}`

## 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 not a FileVault 2 enabled user."
    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."
    echo "${encryptCheck}"
    exit 4
fi

## Get the logged in user's password via a prompt
echo "Prompting ${userName} for their login password."
userPass="$(/usr/bin/osascript -e 'Tell application "System Events" to display dialog "Please enter your login password so that your FileVault keys can be transferred to a new server. No restart is required." default answer "" with title "IT" with text buttons {"Ok"} default button 1 with hidden answer' -e 'text returned of result')"

echo "Issuing new recovery key"

if [[ $OS -ge 9  ]]; then
    ## 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 changerecovery -personal
    expect "Enter a password for '/', or the recovery key:"
    send "{${userPass}}"
    send 
    log_user 1
    expect eof
    "
else
    echo "OS version not 10.9+ or OS version unrecognized"
    echo "$(/usr/bin/sw_vers -productVersion)"
    exit 5
fi

exit 0

[Look]

First thing I can see there is it fails if the icon file is not available to the osascript command as is the case on my machine, you can simply remove that part and the prompt part works okay (at least on my machine).
Was there any other packages expected to be installed with it?

[bmarks]

To describe our entire process...

When we decided to put our JSS in our DMZ, we had to change the URL. What happens is we deploy a QuickAdd package that moves each Mac and at the same another package runs that installs the logo mentioned in the script. Then, this policy runs on any Mac that subsequently has an unknown or invalid FV individual key. So, everything should be in place by the time this policy/script run. And, I've made sure to test it on Macs that have the logo and other pieces in place.

[bmarks]

I had to cut some text out of the script with company-indentifying info, so that part about the logo might not be in there anymore.

[sdagley]

The script running at checkin runs as root. The script you run via sudo runs as the user. Not sure why the script running as root wouldn't show a UI to the user. How are you trying to display it?

[bmarks]

From what I understand, there's no difference. It either runs at the normal check-in interval or if I want to override the check-in interval I can force the policy to run typing "jamf policy" which, of course, then tells me I need to run that command as root. Option 1, no popup. Option 2, popup. Can there really be a difference in the way the script itself runs when it's called by the jamf binary at the normal check-in interval vs. at a manually forced call via running "jamf policy" as root? I don't see how those two things are different but that's why I'm posting here.

The popup is AppleScript within the bash script, specifically two lines under the "## Get the logged in user's password via a prompt" header in the above text.

The most troubling part for me is that this is a script JAMF gave us and they can't help us get it to work. I've given our JAMF guy exact details for how we're using it and asked if there's another way to use it, but nothing but silence.

[bmarks]

So, our JAMF guy now says set it to run at login, which is basically useless these days unless we force restarts. It only to them two weeks to give us that recommendation. He also said try using Self Service, but that failed too. I haven't tested the login trigger yet.

But, I still don't understand. In any of these scenarios, it's the jamf binary that calls the script with its level of authorization so I'm still confused why waiting for the check-in interval is different than a login trigger or manually running "jamf policy" command.

[bkramps]

@bmarks I've had similar problems with System Events not producing a dialog (even in self service). For the scripts where we were using osascript, we replaced with CocoaDialog.

CocoaDialog is not native to OSX, unfortunately, but it is easy to deploy as a package.

We have a similar script to the one you are using to re-issue the key. This actually runs from Self Service for our Techs, not a recurring check-in, so it is user-initiated. You can adapt to your check-in script environment easily. We are using smart groups to check if FV is enabled, not fdesetup. This is all assuming you have deployed CocoaDialog to /Library/Application Support/JAMF/bin/CocoaDialog.app

Since eliminating osascript for cocoadialog, we do not get instances of the dialog not appearing.

#!/bin/sh
# Get List of FV Users
users=$(fdesetup list | awk -F ',' '{ print $1 }')
passdialog=`/Library/Application Support/JAMF/bin/CocoaDialog.app/Contents/MacOS/CocoaDialog secure-inputbox --title "Enter Password" --informative-text "To re-issue the FileVault key, Enter the LOCAL password for any of the below users:
$users" --button1 "Continue" --button2 "Quit"`

# Get Button Clicked
passButtonClicked=$(echo "$passdialog" | awk 'NR==1{print}')

# Get User Selected
ADMINPASSWORD=$(echo "$passdialog" | awk 'NR>1{print}')  
echo $(echo "$passdialog" | awk 'NR==1{print}')
if [ $(echo "$passdialog" | awk 'NR==1{print}') = 2 ]
then
  echo "User Selected Quit"
  exit  
fi

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>Password</key>
<string>'$ADMINPASSWORD'</string>
</dict>
</plist>' > /Users/Shared/filevault.plist

KEY=$(fdesetup changerecovery -personal -inputplist < /Users/Shared/filevault.plist)
if [ $? == 0 ]
then
jamf displayMessage -message "$KEY"
echo $KEY | awk '{ print $NF }'
jamf recon
else
jamf displayMessage -message "Could NOT Set Recovery Key"
fi
rm /Users/Shared/filevault.plist

[bmarks]

@bkramps Thank you for this script. Do you know if this works on El Capitan? I can't seem to get it to work at all.

[bkramps]

@bmarks I seem to be getting some trouble with El Cap now too. I have no problems with Yosemite.

The script has worked on El Cap but seems sporadic (I didn't run it on many 10.11 installs). It seems to be hanging at the "fdesetup changerecovery -personal -inputplist < /Users/Shared/filevault.plist" line. Even if I just run the command "sudo fdesetup changerecovery -personal" from the terminal it hangs.

I just removed the Redirect Recovery Key Profile and the command worked (of course it didn't redirect to JSS). This may be an issue with the Configuration Profile

Can you try the script on a 10.10 machine and see if it works?

Also can you try on a 10.11 with just the command "sudo fdesetup changerecovery -personal" with the Configuration Profile and then without the Config? Let me know if it hangs.

Thanks, sorry I didn't test on 10.11 thoroughly.

[bmarks]

Thanks for the reply. Here is the output if I run that command manually on an El Capitan Mac:

sudo fdesetup changerecovery -personal
Password: ••••••••
Enter a password for '/', or the recovery key:
Error: Unable to add new personal recovery key.

We are imaging a Mac with Yosemite to test, but for our purposes, if it doesn't work on El Capitan, that isn't a big deal. I just wanted to verify that it wasn't just me.

All of our Macs are blocked from upgrading to El Capitan because only this new JSS is version 9.81, so everyone that would be getting this script is on Mavericks or Yosemite. So, as long as this works on those OS's, that fine. Our users will be allowed to self-upgrade, but only AFTER the JSS migration is complete.

[bentoms]

@bmarks You said:

I had to cut some text out of the script with company-indentifying info, so that part about the logo might not be in there anymore.

Can you share what you were trying?

[bmarks]

@bentoms I am completely stumped. We're trying to repair missing FileVault keys. I was using the first script above, but then I tried to use a variation located here:

https://github.com/homebysix/misc/blob/master/2015-01-27%20MacBrained%20Reissuing%20FileVault%20Keys/reissue_filevault_recovery_key.sh

In either scenario, basically the same failure occurs which is that when a policy associated with these scripts is set to recurring check-in, the popups aren't displayed. The 3rd script listed above that uses CocoaDialog works, but I'd prefer not to have to add CocoaDialog to my image... just a personal preference. But the original script I entered above or the MacBrained script to which I just linked won't display AppleScript popups. The script at the link is especially frustrating because it is supposed to display two popups. The first once which uses jamfhelper works fine, but the second one that calls /usr/bin/osascript is not displayed.

What's oddest of all if that if I type sudo jamf policy, the AppleScript popups are displayed.

Oh, and while I'm out of Yosemite Macs for testing, I'm pretty sure this is only occurring on El Capitan.

I really need the recurring check-in option to work because we have 7000 Macs that lost their keys.

In the logs for my most recent attempts, these entries are repeated and seem relevant but I'm out of ideas:

12/4/15 6:36:51.148 PM osascript[1941]: spawn_via_launchd() failed, errno=125 label=[0x0-0x56a56a].com.apple.systemevents path=/System/Library/CoreServices/System Events.app/Contents/MacOS/System Events flags=0 : LaunchApplicationClient.cp #963 LaunchApplicationWithSpawnViaLaunchD() q=com.apple.main-thread
12/4/15 6:36:51.149 PM osascript[1941]: spawn_via_launchd() failed, errno=125 label=[0x0-0x56a56a].com.apple.systemevents path=/System/Library/CoreServices/System Events.app/Contents/MacOS/System Events flags=0
12/4/15 6:56:12.063 PM com.apple.xpc.launchd[1]: (com.apple.xpc.launchd.domain.system) Could not import service from caller: caller = osascript.2283, service = com.apple.systemevents.41952, error = 134: Service cannot load in requested session
12/4/15 6:56:12.067 PM com.apple.xpc.launchd[1]: (com.apple.xpc.launchd.domain.system) Attempt to spawn app in non-GUI domain: caller = osascript.2283, label = [0x0-0x571571].com.apple.systemevents