Because the checkin trigger is going to run things as root it will not be able to display a password prompt to the console user.

You will need to get the logged in user and then run sudo as that user to display the prompt.

I normally use something like this:
currentUser=$(ls -l /dev/console | awk '{print $3}')
sudo -u ${currentUser} /Your/Command/Here

Ah yes. I went back to where i found the script and see now that this is an open issue with this script for this very reason. thanks @nortonpc Will give your code a test run and see if this resolves the issue.

I normally use something like this:
currentUser=$(ls -l /dev/console | awk '{print $3}')
sudo -u ${currentUser} /Your/Command/Here

I'm still struggling to get this to fire. Anyone had luck with getting Casper to grab a password from the user using osascript? Still seeing the 10810 error...

You may want to look at this script. It had similar issues but they have been resolved. We now use this updated version with the check-in trigger and it works fine: https://github.com/homebysix/misc/tree/master/2015-01-27%20MacBrained%20Reissuing%20FileVault%20Keys

@bmarks What version of the JSS are you running? Also, what OSes are able to run this script? This launches the jamfAgent notification but absolutely will not allow osascript to prompt the user for information.

Ok, weird. If I try to call the policy manually (sudo jamf policy) it will not prompt for a password. If it just does a normal recurring check-in, it works fine.

A real head-scratcher! But I guess it's working!

@grahamfw I have a working example here:

https://github.com/UoE-macOS/jss/blob/master/coreconfig-filevault-add-mgmt-acct.sh

Maybe you're running into the issue I had, of needing to check that the Finder is up before trying to display a dialog?

Maybe you're running into the issue I had, of needing to check that the Finder is up before trying to display a dialog?

I'm calling System Events to prompt the user not the Finder. Who knows?? The version @bmarks posted works for me if triggered by the jamfAgent systematically, not manually through a command line trigger. Self-service works fine too.

I was reading this thread closely as I want to re-issue individual keys with frequency, but I'm finding on initial tests that using the native JSS options are working fine, as opposed to scripts and profiles.

I'm confused on the last item though, Requires FV2 At next login. I'm seeing the key rotate immedaitely. Regardless, I'm considering running this as a weekly policy to ensure that if a key is used/viewed, it will be rotated within a week.

Anyone aware of a glaring issue I'm not thinking about on scheduling this repeting indefinately?

I think this thread is primarily for situations where the keys may go missing due to DB corruption, migration to a new DB/JSS/etc. The "require" field you mention is for situations where FV may have been turned off or not activated yet.

As far as scheduling goes, I personally would say that's overkill. What might you be gaining by doing this? If your keys are being accessed, that's when it would make the most sense, right?

@bmarks yes, it does seem excessive. I'm just not convinced the desktop staff will re-issue the keys manually whenever used. Workaround for the current lack of built-in auto-reissue when used/viewed.

There's an fdesetup usingrecoverykey command for checking to see if a personal recovery key has been used, which can be leveraged to automate rotating the recovery key. @kitzy-fastly has a post on how he has used it, available via the link below:

http://www.johnkitzmiller.com/blog/automatically-re-issue-individual-filevault-2-recovery-keys-after-single-use-with-the-casper-suite/

You could even turn that into an extension attribute and then use it to scope a policy. This would then give you a log to see how often keys are being used and then not rotated by your admins.