Re issuing FV 2 Key issues

Daikonran
New Contributor III

I have a policy that will reissue the FileVault 2 key and then record it in our JSS, using a script from another jamfnation post. It works perfectly well except for one point. Part of the script requires the user to input their password in order to unlock the FileVault to reissue the key, the problem though is that when the check-in trigger is "triggered" no password prompt comes up and then it "fails"

Manually calling the policy with a custom trigger, or running it from Self Service works. It also works when I go to a machine and manually run "sudo jamf policy". It just won't properly execute when using the check-in trigger when it auto checks in every 15 minutes, and I cannot figure out why.

This is what i see in the logs, post trigger.

Script result: Prompting <username> for their login password. 36:193: execution error: An error of type -10810 has occurred. (-10810) Issuing new recovery key Error: Unable to unlock FileVault.

Funny enough, it says the policy completed successfully, even though it obviously failed, which is also annoying.

Any ideas?

1 ACCEPTED SOLUTION

nortonpc
Contributor

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

View solution in original post

13 REPLIES 13

nortonpc
Contributor

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

Daikonran
New Contributor III

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.

grahamfw
New Contributor III
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...

bmarks
Contributor II

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

grahamfw
New Contributor III

@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.

grahamfw
New Contributor III

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!

glee_edin
New Contributor

@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?

grahamfw
New Contributor III
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.

dpertschi
Valued Contributor

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.

8949266931634cb19d47fa8fae5bfe0a

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?

bmarks
Contributor II

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?

dpertschi
Valued Contributor

@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.

rtrouton
Release Candidate Programs Tester

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...

bmarks
Contributor II

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.