Lately, every Mac that has tried to perform user-initiated enrollment in Jamf has been met with "Device Signature Error in the jamf log.
To resolve, we perform these steps:
1. Remove Jamf Framework
2. Remove Jamf CA certificate
3. Remove contents of /Library/Application Support/JAMF/Downloads/
4. Run this command: sudo update_dyld_shared_cache -force
5. Delete the mac from Jamf console
6. Run the QuickAdd package on the mac
7. Approve the Device Management Profile on the Mac
8. Assign the user to the Mac in the Jamf Pro console
This issue seems to have started with MacOS 10.14.5, but that may be coincidence. I have attached screenshots from an affected Mac. We have 3 macs that are broken right now, and 2 that were repaired using the procedure above.
Anyone else seeing encountering this?
I reproduced the 'Device Signature Error' problem via Migration Assistant in my test lab and the following command resolved that problem successfully on the DEP-enrolled test Mac: sudo profiles renew -type enrollment
I haven't tested that on actual users affected by this but I'm confident it'll work since it did on my test Mac, which is a MacBook Pro M1 on ADE in ASM with user-removal of MDM profile disallowed.
@dng2000 That works on Big Sur as they seemed to have changed the behavior of that command to allow for updates to an existing profile on the device instead of simply looking for the presence of one. This results in a full refresh of the MDM profile and is a welcome change. Running sudo jamf removeFramework followed by sudo profiles renew -type enrollment results in a fairly pain-free re-enrollment.
Running sudo profiles renew -type enrollment on a device running Mojave for example that was enrolled via DEP spits out an error of "Existing Enrollment configuration was found".
This got sort of fixed in a newer version of Jamf Pro. I can't remember which one...but one of them over the last 6 months
You have 2 certificates with Jamf. The MDM Profile certificate for MDM communication. This is separate from the jamf binary. They built in the auto-renewal of the MDM certificate maybe a year or so ago. The other is called something like the device identity certificate (the exact name escapes me). This is the certificate that the jamf binary uses for its trust relationship with the server. This certificate used to be a 5-year life span, but then changed to a 2 or 3-year life span(can't remember specifically). So if a machine never ran renewDeviceCert I believe or never got re-enrolled...it would eventually expire and you'd get a Device Certificate error. And you'd have zombie machines out there that can strangely get MDM commands sometimes but no communication through the jamf binary (this is why people have asked for self healing in feature requests). Offline policies continue to run happily also.
BUT thankfully Jamf finally implemented an auto-renewal. Now that shouldn't happen to machines that are deployed for long periods of time without a refresh. But machines that never got to that version or expired before would be in zombie mode.
This certificate is stored in the JAMF.keychain in /Library/Application Support/JAMF I believe as if you delete that file you end up with the same error. Doing something like a Time Machine or Migration Assistant move of data would result in the same issue as the certificate doesn't match up.