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.

[isradame]

I have a ticket open on the same issue. I think I just figure it out. The problem resides on the device certificate and the Certificate Authority that are pulled when enrolling. It could be a bug on the server or on OS X client, either way the solution was... (These steps even work on 10.9 beta 7).

Step 1. Reset the Login Keychain
Step 2. Remove any instances of the JSS CA in the keychain
Step 3. Open terminal and ran "sudo jamf removeFramework"
Step 4. Remove all related JSS preferences in /Library/Preferences and /Users/username/Library/Preferences
Step 5. Reboot
Step 6. Re-enroll by downloading the QuickAdd.pkg from the JSS and installing the pkg.
Step 7. Open keychain Access and checked that the device CA and JSS CA were installed.

[jeremy_spolande]

Getting same error on building, re-enrolling does fix but shouldnt be needed on all new builds.

[rderewianko]

I haven't even setup buildings.. I know i'm seeing it on clients that were fine before upgrade..

[bog]

Same issue here.

[jeremy_spolande]

thanks, truncated here but on email comes through as:

--------------------------------

Same issue here. Running this with ARD fixes most but not all computers.

rm -rf /Library/Application Support/JAMF/Downloads/.*
---------------------------------------------------

Anyone know if this contains a cert or anything else to give a clue here, is empty on my test machine here.

[jeremy_spolande]

Doesnt work here in any case.

[isradame]

I know I posted a possible solution, but apparently was only temporarily. So out of frustration I renewed the MDM Push Certificate in JSS, even when it still showed active till 2014.
So far its working since today in the morning. Then I re-enrolled the Macs using the sudo jamf enroll -prompt.

[jeremy_spolande]

In imaging (i meant this when i said building earlier) we have been advised to try using a quick add package as a delayed at boot install within a configuration rather than the built-in management settings. Seems better so far.

[calum_carey]

try removing the apsd.keychain from /Library/Keychains then re-enroll the device or reinstall the quick add

[Hobbs155]

we are also getting this issue, as well as our homeShare mounting is broken.

[cbustamante]

Hi guys, same issue here, any easy fix for massive number of computers?

[cbustamante]

Sorry, got confused by the -prompt feature, working fine now.

[Chris_Hafner]

Hrm... ditto here. Most computers imaging, recon(ing) and running properly. However, a number of them will function properly . It certainly looks like it's an issue with the device CA. However, I'm having a heck of a time trying to figure out why, after some random IT problem solving it will start to function again almost magically and then stop after 12 or so hours. Actually, once it stops working (the ability to enroll machines) then anything we try to re-enroll gets a corrupted CA. Man, does it feel like the JSS is corrupting the CA's it issues. Unfortunately, I'm not quite sure where to start checking that.

[Chris_Hafner]

currently the 'temporary' solution involves running

sudo update_dyld_shared_cache -force

... and then we can run the enroll or quickadd. Unfortunately we still have no idea why properly reporting systems are falling back this way.

[jeremy_spolande]

Re-enrolling works for me but its badly killing the build process as i have a set of policies set to run after imaging and the process dies half way. Please everyone log with JAMF if you are experiencing this. They are looking into this.

[lpnicholas]

The dyld shared cache command ran, but I cannot re-enroll via OTA or manual quick-add. I also tried removing the apsd.keychain and tried to re-enroll... still no dice. The QuickAdd package fails.

The only thing that works for me is remote enrollment from the Recon app. I don't know if it will keep its enrollment. I will have to watch it. I have a webex scheduled for Monday to see if we can correct this.

[Chris_Hafner]

to make an addition here. Our problem ended up being the result of a mixture of things.

1) The probable beginning on a HDD failure on the drive that hosted the JSSs MySQL database (though no failure could be detected of course!). A swap out to an SSD for the Tomcat and MySQL services solved all of our performance issues

2) There was a bug in 9.01 that caused some enrollment issues. We're still waiting to see if re-enrollment of those devices stick. JAMF just had the 9.1 and 9.11 patches and we're holding hope that it solves any lingering issues from that!

3) We did have some network ARP caching issues contributing the DNS timeouts during early recon processes that have been resolved.

4) We used this as an excuse to improve the network topography surrounding the various services related to the Casper suite.

As for a mass-re-enrollment I have the following suggestions.

-Using packages (or any other packaging tool... though composer might have issues with this)

Create a package with the following

1) A package including at least the following -Script that includes the following: -sudo update_dyld_shared_cache -force -sudo jamf removeFramework -sudo rm (-rf) (path to any JAMF resource: i.e. /Library/Preferences/com.jamf* and /Volumes/"Volume"/Users//Library/Application Support/JAMF *In some circumstances the jamf software keychain items will need to be removed. I haven't tried scripting that yet. I'm sure that someone here could come up with it quickly if I don't happen to sit down to it Monday. -(possible) restart after those scripts -install quickadd.pkg. If after reboot then as a as first run or temp launchd item.

I've run these processes on the few units I've had to deal with after the rest of the cleanup so something like what I've mentioned could run easily from ARD.

If you're having other issues then run sudo jamf enroll -verbose and post the results here. I have a funny feeling that your conference call will go over a lot of this sort of thing. I had one with JAMF late last week regarding very much the same stuff.

[Apfelpom]

The 9.1 and 9.11 patches did not solved the "Device Signature Error". Still have this error after remote recon a machine:

*Mon Sep 23 09:22:38 mbpr-ps jamf[32488]: Enforcing management framework...
Mon Sep 23 09:22:40 mbpr-ps jamf[32488]: The computer was not enrolled in MDM with the JSS. The device certificate did not install.
[...]
Mon Sep 23 09:53:44 mbpr-ps jamf[45650]: Checking for policies triggered by "recurring check-in"...
Mon Sep 23 09:53:44 mbpr-ps jamf[45650]: There was an error.

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

[jeremy_spolande]

apparently 9.11 is mostly to do with ios7, there may be a fix for this in the next update after. Turning off "certificate-based authentication" altogether in security does seem to resolve for us (but will also knock out mdm if you have that selected), have also been advised updating the cert might help.

[Matt]

update_dyld_shared_cache -force

Worked for me! Thanks.

[mbracco]

concerning Step 1. Reset the Login Keychain

how did you manage to do that. do you have a command line for that ?

[calum_carey]

mbracco - something like this:
rm /Users/myusername/Library/Keychains/login.keychain

I found that the problem with the mdm not enrolling error seemed to be a time out or something.
I created my own quickadd package and postflight script that went something like
jamf enroll -invitation 234234123412341 -noManage -noRecon
jamf recon
jamf manage
jamf manage
jamf manage

I ran the jamf manage 3x times to ensure that it would enroll the device, so far this has been 100% successful. YMMV

[easyedc]

I am now seeing this on a workstation that WAS enrolled but lost all management/communication abilities from JAMF and I'm getting it on my attempts to re-enroll it. So far tried a few of these steps and nothing seems to work.

[Matt]

Any one have a fix for this?

[tkimpton]

i have this on 29 machines.

On my machine i

1. remove jamfFramework
2. deleted /Library/Keychains/apsd.keychain
3. Rebooted
4. Downloaded a fresh QuickAdd pkg and installed it

cant do this on 29 machines

[Chris_Hafner]

I've changed it up a bit for mine... but you can always ssh directly into those machines. Worse case scenario it takes about an hour to grab those units. Personally I've now moved to reenrolling all together instead of the quick add as that's been giving me some issues as well.

[tkimpton]

Hi Chris

What's your workflow to fix this your end?

I'm curious because I don't want to ssh in to 29 machines if I can help it.

Also I'm getting this after new builds and it would be good to have some kind of hot fix.

Do you know if there is a way to put enroll credentials in a script rather than doing just the jam enroll -prompt

[Chris_Hafner]

Well, I suppose you could script it with the 'sleep' command. You'll also have to define and 'echo' your
JSS admin
JSS password
SSH admin
SSH password

as defined within your script. Personally I still think that manually attaching to these 29 units will be quicker than writing and testing a script to do it. Then again, you know your environment and you're the one that has to deal with it. I wish you the very best of luck!

[Chris_Hafner]

... AND the reason why that's kind of a pain is because there seem to be issues with the standard jamf enroll command at the moment.

[tkimpton]

Thanks Chris but I meant how exactly do that?

As far as I'm aware the jamf binary only enables me to jamf enroll -prompt

Is their a jamf enroll -u "username" -p "password"

Etc

Thanks

[tkimpton]

@calum

Thanks very much, this seems to work.

Ive created an extension attribute with

ConfigProfiles=`sudo Profiles -L`

echo "<result>$ConfigProfiles</result>"

i then create a smart to scope for the error There are no configuration profiles installed in the system domain

Then i create a policy to install my custom quickadd package and all sorted :)

[tkimpton]

why manually when we have the suite? Thats why we got it right?

[Chris_Hafner]

Yep, nice solution. My issue was slightly different. And, unfortunately I was having enough issues that I just instructed our help desk to sort those few users out who had the Device Signature issue. If I find any more I'll be writing a script and will be happy to share. I'm also glad that you're quick add package is working. Ours wasn't last I checked. Fortunately I've resolved more of our major issues and can move back to these things!

[tkimpton]

i spoke too soon... machines are still showing There are no configuration profiles installed in the system domain

and is pointing towards the JSS throwing out a corrupt certificate to the machine!

[tkimpton]

They key was to

1. delete /Library/Keychains/apsd.keychain 2.reboot 3.then install my custom quickadd package and all worked.

still thinking how i can do this for all the machine hmmmmm

if its possible to delete apsd.keychain and then run a command to recreate it without rebooting then this is useful

[jwojda]

I ran into this yesterday on a machine as well. I just did a remote recon on it and it seemed to resolve the issue...

[tkimpton]

I'm having constant issues with this and my config profiles in my Extension attribute profiles -L show an error. When I look at the machine the MDM enrollment profile is invalid.

Doing another recon doesn't fix it for me and I can see when I do a jamf manage the previous entries do not get removed.

[bountyman]

We are using 9.2 on our test JSS and have the same situation here.
As a work around, go to:

Computer Management / Security

Uncheck Enable certificate-based authentication

[chris_kemp]

Seeing this here too, on my test JSS. :( Hope there's a fix in the works...