Looking at the Action button for mass updates if we change the "jamfmanagement" account password would this break the communication with the agents? (since in the inventory the "jamfmanagement" password would no longer match the password stored on those computers)
This is probably an obvious answer but I want to confirm if possible.
I think if you want to update the jamf management account password you should do that in a policy, using the Management Accounts payload. It has an option to update the account password and specifically states that it will also update the keychain and FileVault (if needed). The action above doesn't seem like it would do that, which could leave the machines in an odd state.
Truthfully, the management account is not really used much by Jamf anymore. I think mostly it's Jamf Remote that relies on it since it needs to ssh into an account on the device. Most of the work is done with the LaunchDaemons and LaunchAgents these days.
@mm2270 that makes sense about the LaunchDaemons but does that mean that the "jamfmanagement" account is optional and could be removed completely?
I'm assuming it's still needed for user-initiated enrollments and I see "jamfmanagement" entered there but otherwise I don't see any other references to "jamfmanagement" anywhere else.
If I was to disable user-initiated enrollments would jamf still create a hidden "jamfmanagement" account in dslocal (for machines coming in via DEP)?
I had also found an older jamf discussion speaking about computer objects showing up as "unmanaged" and them fixing this issue via a mass update in the inventory by setting the correct password for the management account.
Which got me a bit worried that if a tech had access to the mass action button for updating the management password that if they specified the "jamfmanagement" account that our machines could become "unmanaged".