Posted on 06-18-2019 06:23 AM
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?
Solved! Go to Solution.
Posted on 08-11-2022 05:26 AM
Our company also experienced device signature errors while re-enrolling Macs with DEP and UIE. We worked with Jamf Support and it turns out that one of the VPP Mac apps was preventing the device certificate from installing. We excluded the VPP app from our Mac environment scope and the issue was resolved.
Posted on 08-14-2019 12:17 PM
I am, but trying to find a more elegant solution as we usually enroll with unremovable MDM.
Posted on 06-10-2024 11:49 AM
i agree, that is way too long an unnecessarily complex. someone posted this below which i have used with success in the past. short and sweet.
sudo jamf enroll -prompt
wherein the JSS username and password is an account with enrollment privileges. And the SSH username and password is a local admin.
Posted on 11-14-2019 01:39 PM
You could always:
sudo jamf removeMdmProfile sudo jamf removeFramework then re-enroll (You may have to use a QuickAdd package)
Posted on 01-15-2020 11:27 AM
Steps above posted by rcole worked for us
Posted on 05-01-2020 02:18 PM
Another way to fix this is to type in terminal
sudo jamf enroll -prompt
wherein the JSS username and password is an account with enrolment privileges. And the SSH username and password is a local admin.
Posted on 08-25-2022 01:16 PM
Thanks. Just fixed this on one of our macs using this. Had the MDM profile set to not be allowed to remove, so couldn't just click the minus button. Device was an old Mojave device.
Posted on 05-06-2020 09:26 AM
Another way to fix this is to type in terminal sudo jamf enroll -prompt wherein the JSS username and password is an account with enrolment privileges. And the SSH username and password is a local admin.
This is our formal resolution process...happens all the time...
Posted on 09-17-2020 05:28 PM
@joecurrinkys you just saved me so many hours of headaches with this... THANK YOU!
Posted on 04-08-2021 02:44 AM
Anyone tried
sudo jamf renewDeviceCert
instead? We have only experienced this once so far, and did the 'enroll' trick, but removes the supervised status from a DEP-enrolled computer.
Posted on 09-20-2021 07:29 AM
if a DEP enrolled device you can just use "sudo profiles renew -type enrollment" to enroll back in, it will be in supervised mode
Posted on 04-19-2021 02:42 AM
I tried
sudo jamf renewDeviceCert
but it errors out with "Cannot get a certificate from Server".
Bye, Fridolin.
Posted on 06-05-2021 03:47 PM
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.
Posted on 06-17-2021 01:45 PM
@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".
Posted on 07-09-2021 02:21 AM
I just fixed a device signature error on a single machine occurrence by running jamf enroll -prompt -noPolicy. The latter switch just to save a little time I think...
Posted on 07-26-2022 07:45 AM
This worked in our environment. Thank you!
Posted on 07-09-2021 11:25 AM
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.
Posted on 12-08-2021 06:38 AM
I'm getting this on Monterey build. (They worked fine with the same workflow on Big Sur). So my fully automagic Zero-Touch builds are broken again. The devices don't get their 'Enrollment Complete' Trigger.
Posted on 03-08-2022 06:06 PM
We are seeing this on Monterey 12.2.1 as well. Anyone else? How did you fix it @FutureFacinLuke?
Posted on 06-15-2022 02:14 AM
Posted on 03-16-2022 02:22 PM
Can confirm this issue is happening on 11.6 and 11.6.2. Causing major issues for zero-touch deployment :(
Posted on 04-08-2022 04:45 AM
We have had some success with redeploy the framework thru API when we get this one.
(jamf-management-framework)
Posted on 06-09-2022 04:13 PM
Have this issue on a 12.2.1 machine. Performed sudo profiles renew -type enrollment and it did not seem to fix the issue.
This is a DEP machine also,
Posted on 06-09-2022 05:49 PM
What happened when you used that command? Try re-enrolling it again, using self-enrollment. If you're not able to do that, remove the framework, etc, and re-enroll. Everything should reset. This might fix the issue.
Posted on 06-10-2022 11:18 AM
Self-enrollment won't work in my experience if the MDM profile is configured to prevent the user from removing it. In that case, removing the framework still leaves the MDM profile installed. And since the device signature is broken (or invalid), the "Remove MDM Profile" command won't do anything.
Posted on 06-23-2022 01:07 PM
Anyone know WHY this is happening? We have several hundred machines not checking in. It will be very time consuming to touch each one to fix them. Along with fixing the machines, I'd like to change whatever needs to be changed to stop this from continuing to happen.
Posted on 06-29-2022 07:29 AM
@jconrod We have the same situation as well, multiple machines just randomly stop checking in from time to time, can't figure out why....
We also have the same issue as @dng2000 where certain machines get a device signature error when trying to run sudo jamf recon or sudo jamf policy. Then we try the sudo profiles renew -type enrollment command but nothing happens. Our profiles are set to "prevent users from removing" so performing a sudo jamf removeMdmprofile doesn't work either. Only wiping the laptop or disabling SIP > removing profiles > enabling SIP > renew command will allow correct re-enrollment again
Posted on 06-29-2022 09:36 AM
Yes. If the sudo profiles renew -type enrollment isn't working for you, I recommend filing a support case with Apple and let them know. There were a few occasions where that command failed to fix the device signature error on DEP enrollments with MDM profiles set to "prevent users from removing".
Posted on 07-21-2022 08:50 AM
We're seeing this in our environment too. I have an API script to run a mass command on the delinquent Macs so they repair the jamf framework, but it isn't working on some devices so they have to be touched manually. Still talking about 30-40 of them. I've only had it start happening in June, sometime. Does anyone know if there is a product issue for this?
Posted on 07-26-2022 04:01 PM
Do you think you could share your API script/call to fix these machines?
We have older machines in our environment exhibiting this behavior, but we have specific pre-stage enrollment groups that are also having the issue and I can't seem to figure out what could be causing it.
Like, on a recently reconfigured MB Air, it got about 13 or so MDM commands from JAMF pro before throwing up a "device busy" error on the device record . When you try to force any of the regular jamf commands (policy, recon, etc.) it gives the device signature error. If I put the same device in a different pre-stage it seems to be fine after reconfiguring. Put it back to the original pre-stage and nuke and we've got the same issue again.
I've combed through the config profiles and policies at a pretty base level and haven't found anything that seems that different.... Still looking tho...
Posted on 07-26-2022 04:20 PM
Allow me to chime in on my experience. If it's the "/v1/jamf-management-framework/redeploy/{id}" API, then that didn't work on most of the "Device Signature Error" in my environment because I suspect Apple's Migration Assistant messed up the /Library/Application Support/JAMF/JAMF.keychain by replacing it with the cert from the old machine, causing communication between JSS and the new computer to be cut off. The only method to get that API to work, as far as I discovered is to disable certificate-based authentication in Settings > Computer Management > Security. The effect of disabling that is all configuration profiles are removed from all managed computers until it is re-enabled. That causes a major security issue in my environment so there is no way my environment can resort to that. Currently, I had Apple and Jamf work on a collaborative case to figure this out.
Posted on 07-26-2022 04:37 PM
I'll attach the script the Jamf technician sent me. He said he received it from an engineer. You should see the places to insert your own info; basically you put in your instance, an admin account and then put in all the Jamf IDs of the devices not reporting in. This mostly solved our problem, but I have a few Macs that are completely hosed and will need to be touched manually to remove the framework, delete device record and re-enroll. Not optimal, but at least it's only 50 or so instead of like, 200.
#!/bin/zsh
# server connection information
URL="https://instancename.jamfcloud.com"
userName="username"
password="password"
# use base64 to encode credentials
encodedCredentials=$( printf "$userName:$password" | iconv -t ISO-8859-1 | base64 -i - )
# generate an auth token
authToken=$( /usr/bin/curl "$URL/api/v1/auth/token" \
--silent \
--request POST \
--header "Authorization: Basic $encodedCredentials" )
# parse authToken for token, omit expiration
token=$( /usr/bin/awk -F \" '/token/{ print $4 }' <<< "$authToken" | /usr/bin/xargs )
function heal() {
/usr/bin/curl $URL/api/v1/jamf-management-framework/redeploy/$1 --silent --header "Authorization: Bearer $token" --header "Accept: application/json" --request POST
}
# list of computer IDs separated by returns
computerList="30
37"
# recurse through the computer list and run the heal command for each computer
for aComputer in $computerList
do
heal "$aComputer"
echo "healing $aComputer"
done
# expire the auth token
/usr/bin/curl "$URL/api/v1/auth/invalidate-token" \
--silent \
--request POST \
--header "Authorization: Bearer $token"
exit 0
Posted on 07-28-2022 01:05 PM
Can anyone tell what permissions I need to set for an API user in order to post to the jamf-management-framework/redeploy?
Posted on 07-28-2022 01:39 PM
It's documented here: https://developer.jamf.com/jamf-pro/docs/privileges-and-deprecations
Posted on 07-28-2022 02:40 PM
Thanks! I appreciate the reference to this document.
I made the changes accordingly but still got the return code with the HTTP status 401. Even try with admin credentials to test and still got 401.
I wonder if there is something else to try.
Posted on 08-11-2022 05:26 AM
Our company also experienced device signature errors while re-enrolling Macs with DEP and UIE. We worked with Jamf Support and it turns out that one of the VPP Mac apps was preventing the device certificate from installing. We excluded the VPP app from our Mac environment scope and the issue was resolved.
Posted on 08-24-2022 09:45 PM
How did you go about identifying which app was preventing the device certificate from installing?
Posted on 09-22-2022 08:54 AM
I second @Leadehh's questions. I am having an issue with the device signature, my school uses the VPP however I don't have any apps being pushed from Pre stage enrollment only in my policies.
Posted on 08-25-2022 01:48 PM
I would like to add that I recently had this problem on a DEP unit we used Migration Assistant on. We set up a temp user and then transferred data via migration assistant. For whatever reason JAMF was "stuck" in the temp user and never completed the enrolling. Logging back into the temp user and running sudo jamf policy allowed whatever needed to be done to finalize, works fine now.
Posted on 12-13-2022 02:04 PM
Anyone know why this even happens? I saw the one person above said a VPP app. I've had a sudden rash of them. Should I run...
profiles renew -type enrollment
...on a weekly policy?