Is it possible to change a Management Account

I have a smart group that checks for management accounts other than the one we want. Then created a quickadd.pkg with the correct management account and scope to that smart group in a policy.

At the bottom of your smart group, when viewing it, there should be an "action" button. From there there is an option to "Edit Management account information". That's how I go about doing it if a large group has the wrong account.

It would be great if I could automate that @Asnyder . I wonder if I could execute that action with the API.

@kbingham I like that. It would be a great stopgap if someone forgets to run the afromentioned SmartGroup Action.

You could in theory write a bash script using a "put" in the api for the management account info. I'm not too familiar with the api. I only use it for adding new computers to the JSS before they're issued for inventory purposes. So basically you could do a put of the management info in xml format and have it done to all computer ID's if they share the same. or Maybe there is a way to do it by group.

your.jss.org:8443/api

While it's relatively easy to change the management account for a system with the API, the problem is, the account needs to exist on the Mac in order for the change to be valid.
If you are enrolling Macs with a local standard (non Casper management) account and wanting to change them to your official management account later, your best bet is the workflow outlined by @kbingham We have actually done something like this ourselves. Very early on in our deployment, some systems were enrolled with regular local admin accounts and we had a policy to fix these with a QuickAdd.pkg deployment which creates the actual management account and (re) enrolls the device with that account.

Reviving this thread in hopes for some assistance with why my SSH access is breaking when management account is changed and how I might be able to go about troubleshooting. I'm unfamiliar with the ins and outs of SSH access.

In my environment, we wanted to change the management account to be different than the local admin account already on the computer. We had discovered issues when trying to reset the local admin acct password via policy. Policy seemed to get confused by local and management account having the same name and would fail most of the time.

To do this, we created a new QuickAdd via Recon. Ran it on the machines and they all updated the management account seemingly correctly. However, now, I cannot access any of the machines via Jamf Remote. It reports back "SSH is not enabled on the remote computer.", even though the SSH column in Jamf Remote is reporting Yes and the machine's GUI confirms this.

I've tried using the GUI to turn things off and on again. Remove and re-add users. Have also tried turning SSH off and on via Terminal. Have tried disabling and enabling ARD via Terminal.

To me, it comes off as a credentials issue where maybe new and old credentials are conflicting. I just don't really know where to check for these things.

I've tried to wipe the /.ssh/known_hosts file. I've also tried editing the com.apple.access.ssh GroupMembership.

I'm out of ideas and don't want to re-image 100+ machines just to separate the management account from the local admin account.

@crehorewp Is it possible that when you created the QuickAdd.pkg in Recon that you enabled to check box labeled something like “Enable SSH for this account only” I forget if that’s the actual label for that checkbox, but it’s something like that. When that option is checked and the management account is created it’s set as the only account that has SSH access.

Does Jamf Remote work on these Macs? Just not regular SSH login? If even Jamf Remote fails, then something went wrong. I would try enrolling again to see if it straightens things out.

Ugh. Never mind my last reply. I missed where you specifically said Jamf Remote wasn’t working.

Only thing I can recommend is recreating the QuickAdd pkg and make sure that the enable SSH box is checked. It may be that it wasn’t checked in the new pkg and so it got turned off somehow.

@mm2270 Thanks for the quick response!

Correct, Jamf Remote isn't working at all. I suppose I'm focused on SSH cause it's in the returned error.

I have another question. Say theoretically.. over time I went into my User-Initiated Enroll settings and changed the specified management account 3 different times. Am I correct in assuming that Jamf Remote should work on all machines no matter what management account it has? For instance, there is no account tied specifically to Jamf Remote, correct?

I ask because I've already changed my settings to get rid of the management account that had the same name as our local admin. Now, it's a brand new account that doesn't exist on any machines. I'm re-imaging a computer now and will enroll it fresh. I'm expecting Jamf Remote to work right off the bat. If it doesn't, then I'm going to bang my head on a wall in confusion.

Thanks for your help!

@crehorewp You're basically correct. As I understand the process, when you use Jamf Remote to do anything with a client, it communicates with the Jamf Pro server to get the target systems management account and corresponding password, then uses those credentials to do an SSH session into the computer, assuming it's available on the network of course. So technically, every device could have a different management account. As long as it's all recorded in the database, it should know how to connect.
That being said, sometimes the db and the actual management account password or details get out of sync and can cause the issue you're seeing.

I'd be curious to see if the machines you're trying to connect to getting those errors have the new management listed for them in their computer record. That's found in the General section. It should say "Managed: Managed by" and list the management account name. Can you check to make sure the new management account is listed there?

Just posted this in another thread earlier today, I think this should work as well. I use this to fix enrollments periodically.

Caveat: I believe the account would still need to be created on the Mac but could easily be scripted out.

#!/bin/bash

jssUser=""
jssPass=""
sshUser=""
sshPass=""

/usr/bin/expect >/dev/null 2>&1 <<EOF
    set timeout -1
    spawn /usr/local/jamf/bin/jamf enroll -prompt -verbose -noManage -noRecon -noPolicy
    expect "JSS Username:"
    send -- "$jssUser
"
    sleep 1
    expect "JSS Password:"
    send -- "$jssPass
"
    sleep 1
    expect "SSH Username:"
    send -- "$sshUser
"
    sleep 1
    expect "SSH Password:"
    send -- "$sshPass
"
    expect eof
EOF

So if you're doing this via a Quick Add package (which is essentially an enrollment) you could set up a policy to kick off your remote access upon enrollment complete with kickstart. Here's what I use.

#!/bin/sh
#
#  ARD Kickstart.sh
#
#
#  Created by Ed Corfman on 6/29/17.
#
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -targetdisk / -activate -configure -clientopts -setmenuextra -menuextra yes 
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -targetdisk / -configure -users 'jamfadminaccount' -access -on -privs -all
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -targetdisk / -configure -allowAccessFor -specifiedUsers -privs -all
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -targetdisk / -restart -agent -menu
/usr/sbin/systemsetup -setremotelogin on
exit 0

This will work for a few more weeks at least until Apple decides to nerf kickstart...