Posted on 04-24-2017 09:37 AM
We've slowly been deploying JAMF to a handful of computers and we've been using multiple methods to deploy. (QuickAdd Package, Self Enrollment, and Apple DEP Enrollment). We've noticed that not all computers are being managed by the same Management account. Is this going to be a problem going forward and if so is there an easy way to clean it up? Most of the managed accounts have random passwords and we're creating additional hidden local administrators on each computer.
Solved! Go to Solution.
Posted on 04-24-2017 10:01 AM
Technically it's not really a problem for them to be different, but for the purposes of preventing things from breaking later, it's best practice to have them all managed by the same account, and it should be an account that is specifically for management from Jamf Pro, not something you log into the Macs with to do management/repair tasks with. You can always have one of those local admin accounts on the Macs as well if you need those. Most Jamf admins will also make the Jamf management account hidden (sub 501 UID) so it does not show up in Users & Groups or at the login window.
As for getting them all on the same account, you could create a Smart Group that gathers Macs that are not being managed by your preferred account (as for criteria, I believe the management account is now a criteria item you can use for Smart Group purposes) Once you have that group together, what you could do is have a Recon.app created QuickAdd.pkg that uses your preferred management account uploaded into Casper Admin, and then push that via a policy, scoped to the group that isn't using that account. You'd want to make sure the policy collects inventory when done so the Mac will then fall out of the group and it won't run again at a later time (assuming you used something other than Once per computer as the frequency)
The only thing to keep in mind is that if you have any policies that trigger on enrollment, these may run again on those Macs, depending on how things are set up. But other than that, it should eventually get them all on the same account.
We needed to do something just like this at one time, because early enrollments to our JSS were happening using a local admin account, before we'd set up our exact Jamf management account. Back then the management account was not a standard criteria item we could use with Smart Groups so we needed to make an API Extension Attribute script that captured this information instead.
Hope that helps some.
Posted on 04-24-2017 10:01 AM
Technically it's not really a problem for them to be different, but for the purposes of preventing things from breaking later, it's best practice to have them all managed by the same account, and it should be an account that is specifically for management from Jamf Pro, not something you log into the Macs with to do management/repair tasks with. You can always have one of those local admin accounts on the Macs as well if you need those. Most Jamf admins will also make the Jamf management account hidden (sub 501 UID) so it does not show up in Users & Groups or at the login window.
As for getting them all on the same account, you could create a Smart Group that gathers Macs that are not being managed by your preferred account (as for criteria, I believe the management account is now a criteria item you can use for Smart Group purposes) Once you have that group together, what you could do is have a Recon.app created QuickAdd.pkg that uses your preferred management account uploaded into Casper Admin, and then push that via a policy, scoped to the group that isn't using that account. You'd want to make sure the policy collects inventory when done so the Mac will then fall out of the group and it won't run again at a later time (assuming you used something other than Once per computer as the frequency)
The only thing to keep in mind is that if you have any policies that trigger on enrollment, these may run again on those Macs, depending on how things are set up. But other than that, it should eventually get them all on the same account.
We needed to do something just like this at one time, because early enrollments to our JSS were happening using a local admin account, before we'd set up our exact Jamf management account. Back then the management account was not a standard criteria item we could use with Smart Groups so we needed to make an API Extension Attribute script that captured this information instead.
Hope that helps some.