This script has been tested on OS X 10.11.6, 10.12.6 and macOS 10.13.3 This script will prompt the currently logged in user if they are FileVault Enabled for their macOS password, which is used to FileVault enable the orgAdmin account. Currently when accounts (including the management account) are created with Jamf Pro via a Policy, QuickAdd or DEP (Management Account) these accounts do NOT get a SecureToken. Starting with macOS High Sierra, Apple has introduced SecureToken along with the APFS filesystem.
If the script runs and doesn't find the admin account, it will create it and then FileVault enable it. This script is compatible with SecureToken on macOS 10.13 as well. This script was designed to be part of a policy within Jamf Pro to FileVault enable your local admin account on your macOS devices. In the meantime make API actions as short lived as possible and cross your fingers that only you, good and noble #MacAdmins read this blog.FileVault Enable your OrgAdmin Account FileVault enable your organizational admin account.even on macOS 10.13! Keep this in mind and we’ll see if any meaningful changes will occur in recon and/or the script running process in the future (if you open a ticket you can reference PI-006270 regarding API credentials in the process list). If you have an API account with Computer record Read rights that gets passed into a script via policy and you use LAPS, then captured API credentials could be used to harvest LAPS passwords via API. This is a good reason to be really careful with what your API accounts can do. If you are passing API credentials from policies via parameter, then ps can capture those parameters and even if you try and obscure them, if we’ve captured the script we can de-obfuscate them. Read it? OK, now consider what happens if you were to add a routine to capture the output of ps aww along with a hard-linking loop like in EAGraber.sh. Jamf admins take note: Do you have hard coded passwords in your extension attributes or scripts? If so, then all your scripts are belong to us. A script on the new JSS could then put that key on-disk into file_vault_2_recovery_key.xml file which will then import and validate, no decrypt/recrypt necessary. What you do with the key is up to you: Send it somewhere else for safe keeping or keep it on device temporarily for a migration to another Jamf console. EAGrabber.sh does exactly that (and a little bit more)ĮAGrabber.sh can be easily modified to narrow it’s focus to the FileVault 2 key only, deleting the rest.
What we can do is make hard links to these files as they come in so when the link is removed in tmp another exists elsewhere and the file remains (just in our new location). So here’s the fun part: When recon occurs there’s lots of file traffic in /Library/Application Support/JAMF/tmp all sorts of transient scripts hit this folder. Which is nice, but it’s the subsequent recon validations where we have an opportunity to get grabby. Also note, Jamf has updated the process for the better in the last two years: a jamf recon ( or two) is no longer required to send the key and validate it, instead JamfDaemon will send it immediately when both the files are detected. The takeaway from that is to realize we have a way to explicitly send keys to the JSS by placing 2 XML files in the /Library/Application Support/JAMF/run folder: file_vault_2_id.xml and file_vault_2_recovery_key.xml. I revamped the core bits a couple years ago in a (nearly 7 year old) feature request: Manually Edit FileVault 2 Recovery Key Telling the JSS Your Secrets Jamf references this method in this old script at their GitHub. There is another method and it’s what is used by the built-in “Filevault Encryption” policy payload to get the keys back to your JSS. ‘Cuz hey it’s 2020 and we’ve learned that hoarding is just silly.įirstly, it should be pointed out that neither ye olde “ Recovery Key Redirection” payload nor it’s replacement “ Recovery Key Escrow” are needed to get keys to the JSS. Well, I’ve got a few insights regarding this that I’d like to share that may help. For cases of mass migration to another JSS it sure would be nice to move those keys over rather than decrypt/re-encrypt. The pain point is this: Keys are sent back to Jamf Pro (JSS) but then can only be gotten at manually/interactively through the web interface, not via API nor another method. So there’s this old feature request at Jamf Nation (stop me if you’ve heard this one…) it’s almost 6 years old: Add ability to report on FV2 Recovery Keys (and/or access them via API) In fact, maybe you came here from there, watch out don’t loop! Continue!
0 kommentar(er)
