Casper remote not authenticating

If yuo think it lost its management account information, you can check that in the Mac's detailed inventory section. Under Computer Information (in version 8.x) or General (in version 9.x) click either the (•••) or "Edit" button. You should then see fields for Management account name & password. in Version 8.x they show up as SSH Username and SSH Password.

If you know what that should be, you can change them or update them there and try again.

One way to test if the account is working is to simply ssh into the Mac from your own with the username & password you think it should be. If you can get in, then enter those same credentials in the above fields.

If that doesn't work its possible some services are disabled on the target Mac, like ssh itself.

This happens when people update the machine instead of fresh installs. Updates kill off sub-500 users. Two options are to either run the QuickAdd package on the machine, or to add the user back in.

One of the ways to do this is to have two policies, one that creates the user and another that resets the password. In the first policy, have it run on the every15 trigger and run this in the advanced section...

/usr/sbin/jamf createAccount -username CasperAdminAccount -realname CasperAdminAccount -password PasswordGoesHere -home /private/var -admin -hidden -secureSSH -verbose; /usr/sbin/jamf policy -trigger reset_admin_password

The second policy is triggered by the reset_admin_password trigger. All the second policy does is randomize the password and update inventory. Then you should be able to SSH/Remote into the machine.

any Ideas on how to do this on a larger scale?

To be accurate, regular OS updates, such as updating from 10.8.3 to 10.8.5, do not and have never killed sub 501 accounts. Only full OS installs, such as going from 10.7.x to 10.8, as an example. We'll have the same issue when 10.9 is out I'm sure.

and i changed the management username and password on the jss and on the machine and I still have not gotten remote to authenticate.

Did you confirm the account actually exists, by trying to ssh into the Mac yourself with that account? Or, if you know of another admin account on that Mac, you can ssh in with that and then check dscl to see if the SSH account listed in the JSS actually exists.
@ctangora may be correct that the account was removed at some point and needs to be recreated using a QuickAdd.pkg.

So to confirm the management account is on the computer we use something like this. It doesn't check to see if the use is an admin, but does see if it exists.

#!/bin/bash

if [[ $(dscl . -search /Users RecordName JSSAdmin) ]]; then
echo "<result>OK</result>"
else
echo "<result>MISSING</result>"
fi

exit 0

There is more to the script that we use, but if you have all the same management account this should do the trick for you.

Just ran into this issue ourselves. Here was our fix:

1. Remove the jamf framework (sudo jamf removeFramework)
2. Manually remove your management user account
3. Re-enroll computer
4. Profit!

We are still getting this error when trying to send thru casper remote. I have done what kylegato suggested and it has worked in the past but not now. Anybody else have any other ideas?

@jillhughes , we have been losing Casper Remote access to some of our machines in the same way--authentication failure. The fix I found that has worked consistently for me was to remove the Management account on the bugged machine using the jamf binary. It's just one line:

sudo jamf deleteAccount -username Management

After that, I reinstall the QuickAdd package, refresh my Casper Remote session and everything works. Hope this helps.

We just started seeing this when upgrading iMacs from Mavericks to Yosemite but none of these fixes seem to work. Are there any fresh ideas out there?

I've seen this upgrade re-introduce the "Device Signature" error that some JAMF users saw in mid-2013. What happens when you run jamf recon?

@Chris_Hafner do the devices with the error have a differing UUID from their JSS records UDID?

@bentoms Honestly, I have no idea. Worse, I never thought to check! I solved that issue some time ago here on campus as, for us, it was as simple as running another quickadd to correct an issue after the 9.8 binary move. I actually never thought to check the differences between the UUID/UDIDs That's quite a good idea and I'm going to keep that one under my hat for future thinking. No, in regards to this issue I'm really just fishing for symptoms.

@Chris_Hafner Yea I'm just guessing.

We've got a couple of duplicate JSS entries as the Macs UUID has changed somehow. I've been trying to figure out what caused that, & what errors that causes.

Then correcting via the API.

@bentoms wrote:

We've got a couple of duplicate JSS entries as the Macs UUID has changed somehow. I've been trying to figure out what caused that, & what errors that causes.

This can happen when logic boards are replaced.

UUID records match on our machines. Recon works as suspected and enrolls machines properly. Yes mother board swaps will certainly cause UUID issues.

Hi,

I had the same problem. Kyle's method was very similar to what worked for us:

Remove the jamf framework (sudo jamf removeFramework) Did not remove the management account Removed the machine from the JSS Re-enrolled the computer

Regards,

David