Device Signature Error - A valid device signature is required to perform the action.

[rderewianko]

After upgrading to V9.01 I'm seeing some machines now say " Device Signature Error - A valid device signature is required to perform the action." while trying to run recon. I've re-enrolled the machine, it works for a day or so but then reverts back to this message.

[thuluyang]

Hi I am using the fastest but rude way to do it.
1:sudo jamf removeFramwork
2: re_enroll again.

[Araneta]

Any one know if this is fixed in JSS 9.5?

[Johnny_Kim]

@Araneta][/url I'm having this issue after upgrading to JSS 9.5.

Edit: If I enroll VIA "sudo jamf enroll -prompt", it enrolls without an issue.

[Araneta]

Thanks @Johnny.Kim for pointing it out.
I use the same fix(/usr/sbin/jamf createConf -url 'https://jssserver' -k
/usr/sbin/jamf enroll -invitation xxxxxxxxxxxxxxxxxxxxxxxxx) as part of my first run script to re-enroll my clients

[jescala]

Our Macs that were affected by this also had a problem with the time synchronization. Stopping and started the NTP fixed if for us.

[archspangler]

I have read through this thread and I don't really see any concrete resolution to this issue. I have tried all the suggestions in this thread and I am still unable to enroll my Mac.

I am experiencing the same issue as the name of the thread (Device Signature Error - A valid device signature is required to perform the action.) when attemping a jamf recon.

I get the following error when running the quickadd package. /var/log/jamf.log
There was an error. Error enrolling computer: Permission Error - The user specified does not have permission to perform the action.

Any help would be greatly appreciated.

Thanks,
Archie

[jescala]

@archspangler Make sure that the JSS account you used to create the quickadd package is allowed to enroll devices in your "JSS User Accounts & Groups" permissions.

[archspangler]

@jescala Verified the JSS account used has the proper permissions. Still failing with the same error.

[fabian_ulmrich]

@archspangler

We sometimes run into this as well - obviously there is not THAT fix. Last time this issue came up we updated to 9.61 (Linux manually), the Backup folder we usually create under /var/lib/tomcat/webapps was the problem. After moving this to a different location and re-writing all tomcat files it worked again.

Another time we could solve the issue by disabling /Settings/Computer Management/Security/Enable SSL certificate verification. Of course, last solution was just a part time solution - means after rebooting and re-enabling it, NO ISSUES.

Also check if the specific client which shows this issue can be found under Computers. Sometimes, for any reason I don't know yet, it might happen that the framework becomes corrupt on the devices.

Hope that helps!

[monogrant]

Still having this issue myself.

Randomly systems will "fall off" the JSS for lack of a better term. These are 10.9 MacBook Pros in our environment. A system will work for months and suddenly a user won't be able to install a new package via Self Service or we'll notice they stop reporting into the JSS.

Only known solution I've found is remove system from JSS and re-enroll. It's a hassle and requires hands-on time.

I can't yet re-produce this reliably nor have I identified a commonality among the users experiencing it.

[jmercier]

Same for me... once a while randomly some computers stops being reporting to jss... i just install on top with the same quickadd package and starts to work again

[RobertHammen]

@jmercier][/url @monogrant][/url Do the machines just check in but have "MDM Capability: No"?

script the following 2 lines, and run as a policy on affected machines (use the built-in Verify MDM Enrollment Extension Attribute to find those with: Not Enrolled as their status, and create a Smart Group with that status, then scope the policy to that Smart Group).

jamf removeMdmProfile
jamf mdm

May also want to verify that the machines have a valid serial number, and that the date & time are correct...

[jmercier]

Actually a little % of the machines stops checking in... but the biggest part of the problem machines checks in and just stops responding to policies

[GabeShack]

@RobertHammen

The jamf mdm command is no longer valid in version 9 and above. Its been put into the jamf manage command I believe...

Gabe Shackney
Princeton Public Schools

[easyedc]

@gshackney it was brought back in 9.6

[GabeShack]

Oooo,
Good to know! I was missing that one.

Never noticed it in the release notes I guess...

Gabe Shackney
Princeton Public Schools

[archspangler]

It appears that upgrading to 9.62 has resolved my issues.

[rrouleau]

This issue is very much still alive for me. I have opened a support ticket but would still love any new input others may have regarding this issue.

[Sandy]

I was having this issue recently on Macbook Airs when imaged over netboot using thunderbolt adapters. My TAM was able to provide me with a workaround, and then the issue was resolved when I updated to 9.6.2. Be sure to replace your Casper Imaging app with the newest version.

I have not seen any instances of previously enrolled OS X devices falling out of enrollment. My issues were all at re-imaging, when the timing of the enrollment was coming before the Thunderbolt ethernet was activated.

[Kennedy]

Our environment was riddled with these errors previously, but I have not seen one in several versions.

As mentioned by others, the imaging app was a critical update for us. We place higher priority on updating this on our netboot image than we previously did.

Cheers!

[gachowski]

just had this issue not 5 mins ago, not 100% sure why however a jamf enroll got they user going again... Now the Mac is in the database twice with two UUIDs and the same serial #.

[ktappe]

Bump: This just happened to us on a 2014 MacBook Pro and Casper Suite 9.63. The unit is not pre-existing in the JSS; it's a new unit. Also won't let me enroll with QuickAdd. Only way to enroll is using "sudo jamf enroll -prompt". Will advise if I find a solution.

EDIT: It seems related to downgrading a Yosemite-delivered Mac to Mavericks (as that's our standard build/workflow).

[easyedc]

I've been seeing this error again after moving to 9.6x for OS X 10.10 testing within our environment. So far the only fix has been to re-enroll to the JSS with a quickadd package. Our workflow has been using Casper Imaging to deploy equipment from one user to the next. On boot post image I'm seeing a fail on any enrollment. My FirstRun directory exists with content, and upon reboot it's gone (implying execution to me). However I don't get any enrollment to my test JSS, I can communicate to it, as verified with a```
jamf checkjssconnection
``` but any other attempts to communicate to the JSS fail with the "Device Signature" error.... Le Sigh...

[damienbarrett]

I see this error about 50% of the time, after swapping HDs between machines. Our workflow is this: 1:1 Laptop comes in for repair; I swap the SSD between it and a Loaner. Student leaves with a Loaner. Several days later, the student comes back with the Loaner, I swap SSDs back, and then this bug rears its head. The "fix" is to re-run QuickAdd or use "sudo jamf enroll -prompt" to re-enroll the machine into JSS, after which the machine shows up in JSS twice with the same serial number, same UUID. I typically end up deleting the "inactive" machine record from JSS and leave the "new" active machine record in place.

Before Casper 9, we used to swap HDs constantly and never had this problem. It seems to have been introduced with Casper 9 (or perhaps OS X 10.8). And it's frustratingly inconsistent. About 50% of the time, the SSDs can be swapped between machines and the machine doesn't lose its identity or enrollment into JSS.

[ifbell]

I just saw this on a 10.10 machine I built using Casper 9.5. We never saw this with or 10.9 boxes with 9.5. Bringing JSS to the latest and building a new quickadd fixed the issue for me. I doubt I needed to build a new quickadd but I wanted to make sure I covered all my bases. Time will tell if this becomes an issue like others have mentioned.

[dderusha]

we just had a mac that would not recon locally or remotely. The Frameworks would not remove...it would hang on "Removing JAMF Daemon Log Files" Ended up being the management admin account had some bad permissions. Reset using the restore partition - opened terminal and did resetpassword

A prompt comes up and at the bottom you can reset permissions for users. Rebooted and the frameworks removed no issue.

[loceee]

I am seeing issues with Macs that I am using Casper Imaging to enrol on 9.65.

Have had to throw a QuickAdd pkg in, install on boot volume to get a reliable enrolment, or manually enrol with jamf enrol -prompt

A workaround, but a little ugly. Not enough time to dig deeper into why the device certificates aren't right at the moment.

[easyedc]

@loceee How are you Imaging? I was using target disk imaging with an InstallESD file and getting this error. JAMF Support indicated the cloned image was the better route for imaging, though I've not made the full change to see if that solved the issue.

[jjones]

I have had this error from time to time when machines attempt to run policies, or jamf recon. I have noticed that it is intermittent with random machines being they could just need a reboot, or time checked to make sure it and the JSS are in sync. Usually I will watch the systems that have the error after I clear it to see if they fail again, I have yet to need to re-join a system to the JSS due to this error.
Although since we have updated in the past few weeks up to current 9.65, we have not seen the error come about, and our count for "Not checked in group" has went back down to before the issues started appearing.

[CasperSally]

I'm seeing what @loceee mentions above in 9.65. Not consistent enrollment when imaging unless I do quickadd at reboot.

[jcompton]

I have learned way more than I ever wanted to the past week dealing with this issue, so I thought I'd share what I learned:

Check EA's
Make sure you don't have any extension attributes that are hanging up recon. For example, we had a script that set the hostname variable with a "scutil --get HostName"

But even if hostname is present in Sharing Preference Pane, it may not be recognized by scutil - especially if hostname was created dynamically. So that command will just hang - causing recon to hang.

When you enroll, a quick computer record is created in JSS, containing very little system info - MAC addresses, Serial Number, etc. And a UUID and JSS Computer ID is generated for the record. But the MDM enrollment does NOT occur until after the recon is done with enrollment.

At any rate - the "No Name" record will appear in JSS until a full recon is done.

For testing - it may be beneficial to create a quick add, but then modify the enroll command with a "-noRecon" option. For example --

/usr/sbin/jamf enroll -invitation 123456789876543212345678976543 -noRecon -verbose

Then, run a

jamf recon -verbose

to try to determine where the hangup is

Verify JAMF Keychain
As part of your troubleshooting, make sure your system is actually receiving its device certificate. The device certificate is NOT in the System Keychain. It's in the /Library/Application Support/JAMF/JAMF.keychain

To verify

sudo security dump-keychain /Library/Application Support/JAMF/JAMF.keychain

You should see a public key, a private key, and a certificate. This of course is assuming that you are using the built-in JSS CA.

JSS CA Problems
If you have attempted to enroll the computer several times, there is a chance that the internal JSS CA is just plain mucked up and confused, and when it issues a device certificate, it can't verify it because there have been too many certs issued.

JAMF is aware of this issue. I don't think a defect is official yet.

The solution below is NOT official by any means, but it worked for me (to an extent)

1. In JSS - find the computer that is failing to enroll (should be a "No Name"). Find by MAC address, or serial number. Under Inventory / Hardware - find the UUID
2. Then navigate to Global Management - PKI - Issued Certificates
3. Search the page for the UUID you found in step 1
4. Are there more than one for that UUID
5. If yes - you may need to purge some of those via MySQL
6. Copy the DEVICE certificate name that corresponds to that UUID. Should look like "CN=C9E7JK12-GH44-63F9-8Z8B-A66777888999,OU=JAMF Device Certificate"
7. Then in MySQL - as root or user with write access --

use jamfsoftware;
SELECT * FROM certificate_authority_issued where subject_name="CN=C9E7JK12-GH44-63F9-8Z8B-A66777888999,OU=JAMF Device Certificate";

That should simply list all the corresponding certificates that are found. Better to do this before running the delete command, just in case. Make sure that all those found are actually ones you want to delete. Then run

delete  FROM certificate_authority_issued where subject_name="CN=C9E7JK12-GH44-63F9-8Z8B-A66777888999,OU=JAMF Device Certificate";

Obviously - replace the certificate from my example with the certificate you copied in step 6

Conclusion
Even after saying all that - we are STILL having trouble with clients who were in one JSS enrolling into a new, clean JSS. The steps above helped me with a few scenarios, but we still have many lingering failed enrollments.

Also - for anyone who "wishes" to recreate this issue, we have been able to recreate at will - even in a completely vanilla JSS or even in our JAMF Cloud test instance.

I strongly recommend you only do this on a dev JSS, but by simply enrolling over and over again (sometimes a dozen or so enrolls) - we can produce the same device certificate errors - at least in 9.72 (haven't tried other versions)

I would love to know how many of you are able to reproduce this.