Device Signature Error

[msample]

Upgraded from Casper 9.62 to 9.65, but started experiencing trouble when running recon via terminal. Anyone else run into this?

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

[MAD0oM]

@msample have you tried looking at this post?

https://jamfnation.jamfsoftware.com/discussion.html?id=8225

let me know

[msample]

Thanks, Sherwin... I did see this post, but it doesn't carry a resolve...seems very sparsed with comments.

[rderewianko]

I find I only see that error now, if time is off, or if i'm running recon before casper has actually finished the enroll on imaging.
- RD

[dferrara]

I'm encountering this on a regular basis post-enroll, we just updated from 9.63 to 9.65. Not sure if it's related or not.

[jjones]

As rderewianko said, I've noticed that when the time is slightly off it will give the error. Just like a kerberos token requires time to be synced, jamf requires it as well.

I usually just restart their mac and run recon afterwards which would correct the signature error it throws.

[msample]

@dferrara ...@jjones....I found a pretty slick command line that eventually helped me get things back into sync.

Try these two commands from the mac you're trying to enroll:

sudo jamf enroll -verbose

then...

sudo jamf enroll -prompt

This should prompt you for the JSS login, and password.

Eventually I could recon the system, and I didn't get the device error message.

[dferrara · Accepted solution]

Awesome, it works! Thanks @msample!

[CasperSally]

I am starting to see this since upgrading to 9.65. Computers that were imaged fine with 9.65, randomlmy the next day they get device signature errors. Has anyone gotten anywhere with support troubleshooting the issue? Support telling me to just re-enroll isn't a good enough answer in my opinion. I have no idea what clients aren't talking to the JSS without trying to judge based on inventory times, etc.

[guzmanj]

I ran across this issue after our Certificate expired. required re-enrollment.

[yellow]

I've seen this before and could fix it, but now I'm getting this on one particular Mac and I've not seen it before. Just for posterity's sake, I'm putting it here. For the moment, I've been unable to fix it remotely via the command line with attempted re-enrolls, etc. I'm now asking the user to try and manually re-enroll.

From the jamf.log:

Fri Sep 25 12:00:03 <snip> jamf[1448]: 
There was an error.

     Unknown Error - An unknown error has occurred.

Fri Sep 25 12:08:10 <snip> jamf[1765]: 
There was an error.

     Error enrolling computer: Unknown Error - An unknown error has occurred.

[bentoms]

@yellow try resting PRAM/NVRAM.

The odd time I've tried EVERYTHING & still now joy, that worked.

[jmcconathy]

I am getting this error now after upgrading the JSS from 9.72 to 9.81. Is re-enrollment the only way to fix it? That would be a huge pain for me...

Edit - we just reverted our JSS back, had too many errors. Will do more testing before we upgrade.

[jkuo]

I've seen this in our environment occasionally when we forget to plug in a network cable after the imaging reboot. I've also had to do the sudo jamf enroll -prompt method when it happens.

[kerouak]

Can confirm that the 'Sudo jamf -enroll -prompt is successful in stopping the errors.. Just had the same issues here.

This was after upgrading from 9.65 to 9.8

[donmontalvo]

We discovered recently that the sudo jamf -enroll -prompt sets the management account to the account you entered credentials for in the SSH portion of the command. Casper Remote might have a problems.

[steveadams]

Could use CasperCheck to get the Mac clients to re-enroll themselves
https://derflounder.wordpress.com/2014/04/23/caspercheck-an-auto-repair-process-for-casper-agents/

[endor-moon]

I found if I removed jamf:

sudo jamf removeFramework

...and ran the QuickAdd installer again, it got rid of this error. Our JSS cert is self-signed which may also be a factor. I recently had to renew the cert. We are using 9.82.

[yellow]

I use a script (based heavily on something that @rtrouton created (check out his blog for more great stuff: https://derflounder.wordpress.com)), that pretty much helps me out when I have issues that really need a 'nuke-from-orbit' solution, but the Mac is not physically accessible to me or a field tech.

#!/bin/bash

qaURL="http://server.location.edu/QuickAdd.pkg.zip"


if /sbin/ping -oq anotherserver.location.edu &> /dev/null

    then

    /bin/echo "grabbing package"
    /usr/bin/curl --silent --output QuickAdd.pkg.zip "$qaURL"

    /bin/echo "unzipping package"
    sudo unzip QuickAdd.pkg.zip -d .;sudo rm -rf __MACOSX

    /bin/echo "updating time"
    sudo ntpdate -u $(systemsetup -getnetworktimeserver|awk '{print $4}')

    /bin/echo "removing jamf framework"
    sudo jamf removeFramework -verbose

    /bin/echo "installing QuickAdd package"
    sudo installer -dumplog -verbose -pkg QuickAdd.pkg -target /

    /bin/echo "running a(nother) recon"
    sudo /usr/local/bin/jamf recon -verbose

## Thanks to Rich Trouton for the following gem!    

    /bin/echo "installing CasperCheck"
    sudo /usr/local/bin/jamf policy -trigger installCasperCheck


    /bin/echo "flushing policy history"
    sudo /usr/local/bin/jamf flushPolicyHistory

    /bin/echo "running policy"
    sudo /usr/local/bin/jamf policy -verbose

else

/bin/echo "Can't reach Casper.  Quitting."

fi

exit 0

I stage this on all Macs via policy and if there's a Mac that just isn't behaving properly for whatever reason, as long as I can ssh in, I can run this script and reset the Mac's enrollment. Quite useful for "device signature" issues (which is what I intended it to be used for initially), or devices that haven't been seen in a long time, or just plain wonky stuff.

You just need to stage a QuickAdd package on an accessible web server to your network's location.

Again, all praise to @rtrouton.

Hope it helps you too!

[DanJ_LRSFC]

Does anyone know what causes this Device Signature issue? As we are starting to see this occuring when we are reimaging some of our Macs.

[mostlikelee]

@DanJ_LRSFC is the JSS SSL cert internally signed? I've seen this immediately after imaging myself, usually if autorun imaging is set:

$sudo jamf policy -verbose verbose: Error Domain=com.jamf.jamfsecurity.error Code=-25300 "The specified item could not be found in the keychain." UserInfo={NSLocalizedDescription=The specified item could not be found in the keychain.}

There was an error.

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

[dgreening]

We are seeing this sporadically when enrolling as part of the 9.96 Imaging workflow:

jamf[2720]: Error Domain=com.jamf.jamfsecurity.error Code=-25300 "The specified item could not be found in the keychain." UserInfo={NSLocalizedDescription=The specified item could not be found in the keychain.}

Running "jamf enroll -prompt" fixes us back up after installing a createusrpkg (our management account is created at enrollment) of our management account.

I have a ticket open with our TAM.

[apizz]

Just wanted to chime in on this that we have now seen this as well on 2 of our Macs. We've been running 10.10.6 since July 2016 and only just started running into this issue when reimaging machines. Never ran into this prior. We're still on JSS 9.82.

My workaround was just delete the computer record from our JSS and reimage again.

I'm going to reach out to our TAM this weekend.

[dgreening]

I would suggest that anyone who is seeing this issue reach out to their TAM. I was able to rule out any of our packages causing this by creating a new configuration with only our 10.11.6 base (AutoDMG), and the machine WILL NOT enroll as part of imaging. Having the only work-around be to pre-delete Macs before imaging them is not acceptable, as we are not going to be giving out local support folks rights to remove machines from Jamf. It is VERY strange that this just popped up out of the blue, and is looking like a defect in the product with no immediate timeline for fix.

[mostlikelee]

Not ideal, but in theory you can add a post install script to your imaging workflow calling the API to delete the computer record. Since enroll is the last step in the imaging workflow, this should work assuming the computername hasn't changed. Roughly something like this:

#!/bin/sh


machinename=`scutil --get ComputerName`
jssURL=""
apiUser=""
apiPass=""


id=`curl -sfku ${apiUser}:${apiPass} -H "Accept: application/xml" ${jssURL}/JSSResource/computers/match/${machinename} | xmllint --format - | awk -F'>|<' '/<id>/{print $3}'`


if [ -n $id ]; then
    curl -sfku ${apiUser}:${apiPass} -H "Accept: application/xml" ${jssURL}/JSSResource/computers/id/{$id} -X DELETE
    echo "$id removed"

    else
        echo "computer not removed"
fi

[dgreening]

I wonder if there is a way to purge the existing device certificate via the API without deleting the entire machine. We need to keep the historical information on enrolled Macs if at all possible.

[Dustin_Dembrosk]

Today I just ran into this same exact issue. I found that removing "Require Authentication" in the Pre-Stage Enrollment fixed it.

Without removing it, the MacBook would just be unmanaged and giving me the "The specified item could not be found in the keychain." error. Running jamf enroll -prompt fixes it.

[apizz]

Wanted to update given my back and forth with our TAM.

We were advised to run sudo jamf enroll -reenroll -archiveDeviceCertificate (these are hidden commands, which can be revealed by running sudo jamf help <jamf binary command> -hidden)

While the above does allow us to re-enroll our machine, this does not fix the issue during the imaging process, and as a result does not install our JSS management account or local users that normally get created during imaging. I've confirmed this behavior both when using one of our standard imaging configurations, as well as when just installing a vanilla base OS.

Have a few more things to try tomorrow ...

[dgreening]

@aporlebeke

Same here from our TAM. I created a new configuration with just our vanilla 10.11.6 base OS (AutoDMG), and no dice on enrollment of a machine experiencing this issue. I let them know that doing manual steps after Imaging is not acceptable with 40+ global offices. It seems that this is issue is isolated to 9.96+. I stressed that this needs to be fixed in 9.98. Imaging is not a dead process yet (its coming of course) and until its timely death, it needs to continue to function as expected.

[mostlikelee]

We're using AutoDMG as well, anyone having issues not using it?

[apizz]

@dgreening FYI, this is not isolated to just 9.96. We're still on 9.82.

[dgreening]

@aporlebeke Funny our TAM said it was 9.96+. JOY!

[apizz]

SO, at the suggestion by a JAMF engineer that was passed along to me by @dgreening (thank you thank you) we were able to reimage two of our machines just by manually removing the information under User & Location in the computer entry.

We automatically collect the last logged in user on our faculty and administrator machines as part of our daily inventory collection by doing a sudo jamf recon -endUsername $(defaults read /Library/Preferences/com.apple.loginwindow lastUserName)

Working on a script to add to our imaging workflow which removes the user & location info, which I will post once I've successfully tested it.

We are a bit further back on the JSS version train, so this might not work for you, but wanted to pass along all the same.

[dgreening]

@aporlebeke Indeed! I just confirmed that purging the User/Location data from my testers device record enabled it to re-enroll on the next run through netboot based Imaging. Nothing else had worked. It would fail enroll every single time. Relayed this back to my TAM/engineering.

[dgreening]

Looks like the product issue which we are running into on this (needing to clear the user/location data to have enrollment work at Imaging) is PI-002950.

[mostlikelee]

Good work! Guessing we can run an API call to remove those fields based on the UDID of the machine. Did clearing username alone not do the trick? @dgreening

[dgreening]

I did not try the username alone: I cleared all of the User/Location fields. I encourage those of who who are seeing this to try that and report back.

[DanJ_LRSFC]

We're now having this issue on a brand new Mac. It's never been on our JSS so it isn't in there for us to be able to delete it or clear its User or Location fields.

I've tried resetting the PRAM which has not helped.

I've tried doing

sudo jamf removeFramework

then running a QuickAdd package, which has not helped (the QuickAdd package failed).

After doing the latter I see some errors in jamf.log:

MAC010065:~ admin$ tail -n 20 /var/log/jamf.log 
Thu Feb 02 13:50:40 MAC010065 jamf[750]: The SSL certificate for (our JSS server name) does not need to be trusted.
Thu Feb 02 13:50:43 MAC010065 jamf[805]: Error Domain=NSCocoaErrorDomain Code=4 "“JAMF.keychain” couldn’t be removed." UserInfo={NSFilePath=/Library/Application Support/JAMF/JAMF.keychain, NSUserStringVariant=(
    Remove
), NSUnderlyingError=0x7fa3b1509d00 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}
Thu Feb 02 13:50:44 MAC010065 jamf[805]: Error Domain=com.jamf.jamfsecurity.error Code=-25300 "The specified item could not be found in the keychain." UserInfo={NSLocalizedDescription=The specified item could not be found in the keychain.}
Thu Feb 02 13:50:44 MAC010065 jamf[805]: Error Domain=com.jamf.jamfsecurity.error Code=-25300 "The specified item could not be found in the keychain." UserInfo={NSLocalizedDescription=The specified item could not be found in the keychain.}
Thu Feb 02 13:50:44 MAC010065 jamf[805]: 
There was an error.

     Error enrolling computer: CRUD Operation Error - An error has occurred while creating, reading, updating or deleting a device.

We are on 9.96. I opened a support case about it but the support representative seems to be suggesting that it is a problem with our base OS image, but if that was the case then would it not affect all Macs imaged with this image? We have 10 other Macs of identical model from the same batch that have not experienced this issue.

@dgreening when you say "imaging is not dead yet but it's coming" what do you mean? Are you suggesting that in future we would need to stick with the version of macOS preinstalled on the Mac? What would we do if we needed to wipe a Mac and restore it to a stable state, if imaging will not be available? It's very difficult for us to keep pace with Apple's annual OS releases, they typically release a new version not long after we've just installed the current version.

[apizz]

Per 9.100.0 release notes, can now flush User & Location categories. See the 9.100.0 release notes here.

[chrisdaggett]

Still having this same problem. Occurs but not all the time. Using JAMFCloud.

Same errors in log with regards to SSL Certificate must be trusted, item could not be found in keychain, and "connection failure the request timed out".

Doing remove framework, doing a clean install on the machine, etc.. nothing works. Have user / location data cleared doesn't help.

The only way I can get a machine to enroll when this happens is to delete it from the JSS, and frankly I am getting a little upset at the lack of response from JAMF Support.

Any other ideas?