Casper remote is not authenticating properly on some machines. I am getting the following whne it tried to authenticate
Sending Wake On LAN command...
Opening SSH Connection to 10.2.104.17...
any ideas? I think this machine has lost it's management username and password im not sure how to fix this.
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.
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.
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.
@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.
@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.
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