macadmins / escrow-buddy Goto Github PK

Summary

PRK invalid status

does Escrow Buddy fix the invalid PRK that have the long strings of characters in the PRK field when you click on it.

Unknown do get fixed, its just the ones with the long characters

• Escrow Buddy version: 1.0.0
• macOS version: ventura or sonoma
• MDM version: jamf 10.50
  Additional Context
  

Summary

Followed the instructions, tested on a machine, but still no recovery key escrowed in Jamf.

Steps to Reproduce

Followed Wiki steps one-by-one, but not given desired result.

Expected Behavior

Recovery key should be escrowed within Jamf.

Environment

• Escrow Buddy version: [1.0.0]
• macOS version: [Sonoma 14.3.0]
• model [Apple M1 Pro]
• MDM version: [Jamf 11.1.1-t1701704198]

Additional Context

The one thing that may not be setup correctly is the [FDERecoveryKeyEscrow] payload. We have FileVault setup using a Configuration Profile, with the Security & Privacy > FileVault payload. I will include a screenshot. Is this the same as the FDERecoveryKeyEscrow payload mentioned in Step 1 of the Wiki? Also, for PKG download. Do I only need the PKG, or also the ZIP (Source Code) files?

Our Jamf Pro instance has already rolled out FV2 encryption enablement/enforcement configuration profiles and is set to escrow the PRK to Jamf Pro. How do I approach using Escrow Buddy to force encrypted endpoints with an invalid/unknown individual recovery key validation to escrow a new PRK? These endpoints with invalid/unknown recovery keys already have the existing FV2 config profile, and I'm worried that scoping an additional FV2 profile with the same settings will cause more issues.

Since this uses the authdatabase and macOS only supports one authdatabase at a time this wouldn't work with Jamf Connect.

Summary

This may be a coincidence, but just wanted to report it in case there was a bug. I deployed Escrow Buddy to a system and it showed up as "Configured" within the Jamf EA (Escrow Buddy authdb status). I restarted with no issue, but noticed when I logged back into the system, it prompted (within System Settings) to update macOS to 13.6.4 from 13.5.1. When trying to install the update, it got stuck in a bootloop. Before even getting to the login screen, it prompts to enter a password for the Disk (looks like a FileVault prompt). Upon entering the password, it restarts and back to the same prompt. I've also tried macOS Recovery, including First Aid and reinstall macOS Ventura, but upon Reinstalling macOS Ventura through Recovery, it gives an error: This operation couldn't be completed: (com.apple.BuildInfo.preflight.error error 21.) - At that point I tried SMC/NVRAM Resets, Safe Mode, and Internet Recovery. I still either get the FileVault Prompt to enter my password, which then bootloops, or the preflight error (when trying to reinstall macOS via Recovery).

Steps to Reproduce

• Install/configure Escrow buddy
• Restarted MacBook
• Ran update to latest version of Ventura
• Upon restart, boot loop occurs.

Expected Behavior

No boot loop, and only an escrowed Key.

Environment

• Escrow Buddy version: [e.g. 1.0.0]
• macOS version: [e.g. Ventura 13.5.1]
• MacBook Pro (13-inch, 2018)
• MDM version: [Jamf Version 11.1.1-t1701704198]

Additional Context

I've added some screenshots of the FileVault prompt and preflight error.

Summary
Escrow Buddy interacts during user login and appears to have access to password and maybe recovery key but it's unclear.
Please document what confidential items it is able to access.

Additional Context

Many companies consider passwords to be confidential, and the filevault recovery key a high confidentiality item due to it being able to unlock the disk of an encrypted device.

It's unclear if Escrow Buddy has access to the user's password and recovery key during the process.

Can something be added to the documentation (README? Wiki) about the items Escrow Buddy can access?
And any other security items you feel are pertinent.

p.s. I'm glad to detail out an answer and put it in the wiki if someone can just provide the basic answers of what it can access.

Summary

Our organization currently uses Jamf as our MDM provider, and we enforce key escrow by using a policy rather than a configuration profile. Is there any plan to support this method of key escrow?

Environment

• Escrow Buddy version: 1.0.0
• macOS version: Ventura 13.4

Additional Context

We tried out escrow buddy with just the disk encryption policy alongside it, and the logs said ERROR: No MDM profile for enforcing FileVault escrow is present.

Thanks!

Summary

I have only tested on a few machines in our fleet, but it does not seem to work if the account that logs in is using enforced SmartAuth login with CTK. The local admin account logs in and it works, but my account with CTK enforcement gives these errors:
"ERROR: fdesetup terminated with a non-zero exit status: 11"
"fdesetup Standard Error: Optional("Error: User could not be authenticated.\nError: Unable to unlock or authenticate to FileVault.\n"
"Caught error trying to generate a new key: The operation couldn't be completed. (Escrow.Buddy.Invoke.FileVaultError error 0.)"

Steps to Reproduce

Log out and log back in with a two-factor enabled account (so username/PIN instead of username/password) and it won't work. Log out and log back in with a local account that does not have two-factor enforced (can log in with username/password) and it works. Additionally, if I disable the enforcement of CTK and log in with the username/password on my personal account, it works, as well. I have attached the output from that machine (ran log show --predicate 'subsystem == "com.netflix.Escrow-Buddy"' --style syslog --debug --info --last 24h and ported to a ".log" file)
logCapture.log

Expected Behavior

I would expect that it would work, but it is not.

Environment

• Escrow Buddy version: [e.g. 1.0.0] - 1.0.0
• macOS version: [e.g. Ventura 13.4] - macOS 14.0 Sonoma
• MDM version: [e.g. Jamf 10.46.0] - Jamf Pro 10.50.0

Additional Context

Add any screenshots, logs, or additional details about the problem here. Include which troubleshooting steps you've already taken.