fleetdm
Disk encryption profile is not appearing while setting is enabled
Fleet version: 4.61.0
Web browser and operating system: macOS 15.2, 15.1.1, 15.0.1, 14.5
💥 Actual behavior
Disk encryption is enabled in the OS Settings, but the disk encryption profile is not present in the host's System Settings or in the OS settings modal on the host's page. Most users also did not have the recovery key available on Fleet after restarting, while one user did. This is all occurring in No Team.
🧑💻 Steps to reproduce
- TODO
- TODO
🕯️ More info (optional)
N/A
@rebeccaui Could you add some more context? where was this seen and did the numbers ever update later? Thanks!
Linked to Unthread ticket:
Looking at the OS Query results for that host it does appear to be encrypted = Vincent’s MacBook Pro - /dev/disk3s1s1 - encrypted - /System/Volumes/Data - apfs
@rebeccaui were these devices -
- already encrypted prior to enrolling in Fleet?
- managed by a different MDM prior to enrolling in Fleet?
- manually enrolled in Fleet or via ABM?
- Did they move teams at any point after getting enrolled in Fleet?
- I'm also curious if all the other config profiles that are part of
no teamare reaching the host?
Assuming they were already encrypted prior to Fleet enrollment, I tested the following workflow -
I unenrolled/wiped my device, encrypted the disk manually, then manually enrolled to Fleet on no team with encryption enabled. My host does show the Disk Encryption Profile but it's stuck in Pending (and the banner still shows on My Device) even after several restarts and log outs so something does appear to be broken when enrolling hosts into fleet that are already encrypted. After looking at the orbit logs it shows that Escrow Buddy is failing -
2025-01-05T15:56:24-08:00 INF refreshing the update runner config with Escrow Buddy targets and hashes
2025-01-05T15:56:24-08:00 ERR running config receivers error="failed to re-enable Escrow Buddy in the authorization database, err: exit status 127: sh: /Library/Security/SecurityAgentPlugins/Escrow Buddy.bundle/Contents/Resources/AuthDBSetup.sh: No such file or directory\n"
@PezHub Agreed about the query results.
Here are the answers to your questions:
- Yes, the devices were encrypted prior to enrolling to Fleet. However, the device from the screenshots DID have the profile and recovery key for available on Fleet for a limited time. Both are now gone.
- No, the devices were not managed by another MDM prior to Fleet.
- They have both manual enrollments and automatic enrollments.
- Some devices did move teams, but some did not.
- Based on the screenshots, it appears as though the other config profiles are present.
@rebeccaui @gillespi314 I did not see anything broken when playing with macOS encryption on No Team today. I'd like to get some more details on how to reproduce this issue. I'm not looking at Gabe's experiment at the moment since that's not what the customer is experiencing.
A couple of things to note:
- macOS encryption keys may take up to 2 hours to show up, since verification involves 2 jobs that run every hour
- if MDM doesn't seem to be working, try testing it by uploading a simple config profile and see if it makes it to the device
- there was an MDM bug introduced in 4.61.0 and fixed in 4.62.1 #24816 -- is the issue seen before 4.61.0 or in 4.62.1? (Note: this bug is only relevant if replica DB is used)
This could be a symptom of the concurrent client-side API calls, which were addressed by the client here. If we're not able to reproduce locally, I'd suggest we close this issue for now and re-open if the client experiences this problem again using their updated application.
From Pinto - Checked with the customer and it hasn't resurfaced. Closing out and will reopen a new one with new info if they see it again
Encryption profile gone, Fleet's swift fix brings it back, Secure data dawn.
