Re issue file vault key High Sierra

[MikeF]

So I am testing re issuing filevault keys. We have a few macs encrypted but no key. I have found that I did need a new configuration profile for High Sierra and after setting that up I am able to start encryption and get the key escrowed toy the server. But if I try to re issue this key I keep failing after regenerating the new key.

I get this error
Successfully prompted for Mac password.<br/>Issuing new recovery key...<br/>[WARNING] FileVault key was generated, but escrow did not occur. Please verify that the redirection profile is installed and the Mac is connected to the internet.<br/>

As the key gets there for a new install doesn't that mean the re direction profile is installed properly. Same setup works properly in Sierra.

Any one got this working ?

[remyb]

Have you updated your re-issue script to the High Sierra compatible version?

Judging from the error message you are using this one:
https://github.com/homebysix/jss-filevault-reissue

[MikeF]

I had a issue with the scope was not correct. It is working properly now

[brunerd]

That's nice, considering this: 10.13 fdesetup changerecovery -personal with wrong password deletes recovery key

[eylonk]

I am using the mentioned script in the self service where it's working perfectly, yet I wish to know whether there is a way to automate the process?
Is there a way to populate an admin pass to re-issue the recovery key same as we did for older OS's:

expect -c " log_user 0 spawn fdesetup changerecovery -personal expect "Enter a password for '/', or the recovery key:" send "AdminPass" send log_user 1 expect eof " >> /dev/null

[teknikal35]

I am also after an automated version rather than users having to enter their passwords, can we not use the admin details, and enter it in the script parameter setting 4 as administrator 5 as admin password

[jelockwood]

@teknikal35 @eylonk

I am currently having problems with a few Macs being listed as having bad i.e. unknown FileVault recovery keys, they were originally successfully escrowed. Presumably the FileVault key rotation script I have went wrong somewhere for these machines.

Anyway here are some hopefully helpful comments.

As I suspect most/all people here are aware with High Sierra, user accounts need a Secure Token in order to both be a FileVault enabled login account and to consequently do FileVault tasks e.g. with fdesetup. The way the jamfmanager account is created results in it initially not having a Secure Token - hence it cannot do FileVault key rotation. JAMF helped me out with this by pointing me toward - https://github.com/kc9wwh/FileVaultEnableAdminAccount

This script is being used to create a Secure Token for our jamfmanager account. As it is currently written it does require a user to type in a local admin password, however as far I can see it could in theory be modified to either use a known standard password or it could be modified to accept a parameter detailing a unique password taken from a JSS extension attribute - which leads on to the following.

I also have LAPS set up in JAMF. See https://github.com/unl/LAPSforMac with this I have Macs initially imaged with a standard local admin password and then this script later randomises this and stores it as an extension attribute for the computer record.

Since there seems to be no way to write a script which can 'insert' the jamfmanager account password, you would perhaps instead need to use the local admin password stored by LAPS.

Note: My imaging process which creates this initial local admin account and password does result in an account which has a Secure Token and the LAPS script does not break this. So this account is valid for then later creating a Secure Token for the JAMF Manager account.

I have LAPS working, I have the script for creating a Secure Token for the jamfmanager account working - although as mentioned it currently requires the user to manually type in the local admin password.

What I have found is that the standard JAMF policy to replace an unknown FileVault key is not working - even though the jamfmanager account does have a Secure Token thanks to the above script. I just get the following messages for the Policy that is supposed to replace unknown keys.

Executing Policy Replace unknown recovery key
Error: Internal error.

JSS error messages have proven to be a big disappointment.

This policy is using the Disk Encryption issue new Recovery Key option and not using a script.

[thefaded]

@remyb Do you happen to have a link to the HS compatible version? I've been screwing with this old one as well.

[remyb]

@ashley.smith The link in my first post links to the github page, which has the newest version!

[Br3ck]

Can confirm that this worked great for me on our 10.13 Macs: https://github.com/homebysix/jss-filevault-reissue

[elliotjordan]

Hi folks! I'm the maintainer of the jss-filevault-reissue workflow referenced above, and I've got a quick update that may be of interest to you.

My team has published a new tool called Escrow Buddy, which regenerates FileVault keys at the loginwindow, thus avoiding the need to prompt users for their password later. It should be suitable as a drop-in replacement for my previous jss-filevault-reissue workflow at most organizations.

You can read more in this announcement on the Netflix Tech Blog, and this post on my site specifically covers migrating from my old workflow to Escrow Buddy. Escrow Buddy's source code and installer are available on GitHub.

Thanks!