-
Notifications
You must be signed in to change notification settings - Fork 11
This page contains common questions relating to aspects of Escrow Buddy usage.
-
Basic usage
- How long after login should the recovery key appear in my MDM?
- What happens to the old recovery keys I have stored elsewhere?
- What if a user wants to have a copy of their own key?
- Is there any harm in leaving Escrow Buddy installed after the FileVault key has been escrowed successfully?
- Why do I need to set the
GenerateNewKeypreference? Should I bundle it with the install itself? - Can I force users to log out in order to generate a new key?
-
Advanced usage
- How do I view Escrow Buddy's logs?
- After a macOS update/upgrade, Escrow Buddy is no longer in the authorization database. Why?
- Why doesn't Escrow Buddy include a launchdaemon that fixes the authdb automatically after macOS upgrades?
- Will Escrow Buddy automatically update on my managed Macs when new versions are available?
- Can I use Escrow Buddy to change from institutional to personal recovery keys?
- Does Escrow Buddy call back to my MDM to determine which Macs need a key?
-
MDMs and other tools
- Does Escrow Buddy work with any MDM?
- Does Escrow Buddy support escrowing keys to a Crypt Server or non-MDM location?
- Can I use the standalone Crypt agent in place of Escrow Buddy?
- Does Escrow Buddy work with other authorization plugins like Jamf Connect?
- What if my MDM cannot run scripts or install packages?
- Security
After login, the key will be stored locally until the next SecurityInfo MDM command. The response to this command will store the recovery key in MDM. The timing of this command/response varies by MDM vendor. See the Troubleshooting section below for details.
The method outlined in this blog post may be of interest to those who wish to minimize the time between FileVault key generation and escrow.
Once a new key is generated, the old key is no longer valid. You can discard them.
Power users can use the fdesetup binary to generate a new key visible to them, which will also be escrowed to MDM.
sudo fdesetup changerecovery -personal
Is there any harm in leaving Escrow Buddy installed after the FileVault key has been escrowed successfully?
No, although you may want to be proactive about testing new releases of macOS to ensure Escrow Buddy (and any other authorization plugins you use) continues working as expected.
MDM administrators may want to deploy Escrow Buddy to managed Macs that already have valid FileVault keys escrowed. In this situation, it would be undesirable and unnecessary to generate and escrow a new key.
Additionally, some Macs may need a FileVault key generated and escrowed at multiple times in its lifecycle. Installing Escrow Buddy each time would be unnecessary, if it was already previously installed and working.
Therefore, we recommend keeping the Escrow Buddy install logic separate from (but parallel to) the GenerateNewKey configuration action. See the Examples section for tips on doing this in specific MDMs.
Escrow Buddy does not include any user interface or notifications, and we don't recommend wrapping it in one. If you already have other enforcement active that requires a logout or restart (for example, timely installation of macOS updates), you probably don't need to do anything extra to get users to log out.
However, a few reminder and enforcement options are outlined in this blog post.
Escrow Buddy logs useful information to the macOS unified log during the login process. To view this in real time (typically while connected via SSH from another device), use this command:
log stream --level debug --predicate 'subsystem == "com.netflix.Escrow-Buddy"'
Or to view the logs retroactively, use this command:
log show --predicate 'subsystem == "com.netflix.Escrow-Buddy"' --style syslog --debug --info --last 24h
(Adjust 24h to the desired timeframe.)
If failures are happening at installation/deployment time rather that at login time, check for clues in /var/log/install.log as you would with any macOS installer.
Some macOS updates and upgrades reset the authorization database to its default state, which will deactivate Escrow Buddy and prevent FileVault key generation upon next login.
Although this behavior adds friction to administering Escrow Buddy on your Macs, it's actually a great opportunity to test new macOS versions and ensure Escrow Buddy (or any authorization plugin) works as expected before reflexively re-enabling.
Once you've tested and are confident that Escrow Buddy works with the versions of macOS your company Macs are running, you can run this command (in root context) to re-enable Escrow Buddy in the authorization database:
/Library/Security/SecurityAgentPlugins/Escrow\ Buddy.bundle/Contents/Resources/AuthDBSetup.sh
Tips for configuring this on various MDMs can be found in the Examples wiki page.
Also see this related blog post: Managing login mechanisms in the macOS authorization database
Why doesn't Escrow Buddy include a launchdaemon that fixes the authdb automatically after macOS upgrades?
As of macOS Ventura, installation of background items like launchdaemons cause a user-visible notification to appear. Properly managing this notification depends on things well outside of Escrow Buddy's core focus, so we opted to keep things simple and focused.
However, if you're interested in building your own daemon for authdb maintenance, executing the above-referenced AuthDBSetup.sh script from your daemon might be worth trying.
No. You'll need to download, test, and deploy new versions. Consider using these AutoPkg recipes to streamline this process.
Yes! Since Apple no longer recommends institutional recovery keys (IRK), administrators can use Escrow Buddy as a means to switch those Macs to use personal recovery keys (PRK) instead. Follow the Deployment steps and set GenerateNewKey to true on Macs with IRKs, and a new PRK will be generated and escrowed at next login.
No, Escrow Buddy doesn't communicate to your MDM at all.
For input, Escrow Buddy relies on (among other things) the value of the GenerateNewKey preference: if that preference is True upon login, Escrow Buddy generates a new key. If that preference is False or unset, Escrow Buddy takes no action. For MDMs that support criteria-based dynamic scripting, you can set the GenerateNewKey preference based on the escrow status of each Mac in the MDM, and Escrow Buddy will act accordingly.
For output, Escrow Buddy simply provides the needed credentials in-memory to fdesetup. The work of actually generating the new personal recovery key and escrowing to the MDM is handled entirely by macOS first-party mechanisms, not by Escrow Buddy directly.
Yes, as long as your MDM meets these requirements:
- supports FileVault recovery key escrow
- can deploy a configuration profile with the FDERecoveryKeyEscrow payload
- has the ability to install packages and run shell scripts
No. If you're using Crypt, you're already benefitting from automatic key remediation at the login window, and you don't need to use Escrow Buddy. Escrow Buddy is specifically for organizations who escrow their FileVault recovery keys in MDM.
Yes! If you're considering implementing Crypt in the future and want to get a head start on its deployment, the Crypt agent includes Escrow Buddy's key remediation feature, along with numerous other features like FileVault enablement and key rotation after usage.
Escrow Buddy is meant for organizations who only want the basic feature of remediating missing recovery keys at the login window, without the codebase and documentation associated with other features of Crypt.
Yes! Escrow Buddy should be able to coexist with most other authorization plugins, as long as those plugins don't also generate/rotate FileVault recovery keys (which as of version 2.24.0, Jamf Connect does not).
If your MDM doesn't have a local agent that it uses for running scripts and installing packages, you may want to look into using the InstallEnterpriseApplication command to install a tool like Munki during your Mac provisioning process. Munki can be used in tandem with an MDM to deploy software and scripts. See specific details here.
No, Escrow Buddy does not need or seek access to the recovery key itself; that key is stored by fdesetup and retrieved during the response to the MDM SecurityInfo command, as mentioned here.
Escrow Buddy sends the username and password provided at macOS login directly (and only) to the fdesetup command for purposes of generating a new personal recovery key. Escrow Buddy does not store these credentials or use them for anything other than authorizing that task.
Importantly, all macOS authorization plugins including Escrow Buddy have the capability to access certain data within the authorization "environment." Some of these are documented in Apple's Authorization Name Tags documentation, including kAuthorizationEnvironmentUsername and kAuthorizationEnvironmentPassword. To fully validate the behavior of Escrow Buddy or any open source authorization plugin, you or your company should audit the source code. (Hint: search for the constants listed in Apple's Authorization Name Tags documentation, then follow the variables they're assigned to.)
Yes, the installer package published on the GitHub releases page is signed and notarized by the Mac Admins Open Source (T4SK8ZXCXG) development team.