Posted on 10-18-2017 11:14 AM
Jamf installed a hidden admin account called jamfadmin. How do I find the password?
Posted on 10-18-2017 11:17 AM
You should not need it. The Jamf Pro server keeps track of the password, but it's hashed in the db for each computer record, so there's no way to see it there.
If you need to, you can set up a policy to deploy out to machines that will reset the management account password to something you know, or just something random (which would mean you would not know it). There's a policy payload to do that called "Management Account"
Posted on 10-18-2017 12:46 PM
I see. The issue is that the jamadmin user was deleted after running a policy but the jamfadmin home folder is still there. I was going to recreate the account and trigger "use existing home folder" from the system but I have to provide a password. I guess I can use any password then sync it with the JSS?
Posted on 10-18-2017 01:58 PM
Why not just delete it and run the quickadd pkg to rebind the machine to the JSS, it will create a new admin account for it's own purposes.
Posted on 10-18-2017 02:53 PM
Are you saying the jamfadmin account appears in the /Users folder? The hidden management account for Jamf Pro doesn't keep its home folder there. If you're seeing a folder in /Users, then it's likely for some other purpose than Jamf's use.
Posted on 10-20-2017 06:53 AM
@talkingmoose No, the home folder is in the hidden location but the user profile is gone. All of the user profiles were gone after the policy ran but the home folders remain. I recreated the visible account by using the same exact name which gave me the option to use the previous home folder. Just thought could do the same with the jamfadmin accountant not mess anything up.
@Look Are you saying to delete the home folder or to delete the machine in Jamf?
Posted on 10-20-2017 07:45 AM
@Vernaf Are you saying that there is a hidden home folder in /private/var/ for the jamfadmin account, but no record in dscl, like if you do
dscl . list /Users it doesn't show up there? Did this policy get rid of other critical hidden accounts? While a system could survive if the hidden jamf management account gets removed, it's likely going to experience some problems if other hidden system level accounts got removed as well.
All that said, I would do what @Look mentioned and just deploy a QuickAdd pkg to your machine(s) using the recurring check-in trigger, which gets called by a LaunchDaemon, so it doesn't need that jamf admin account to work. Be sure when you create the QuickAdd in Recon.app that you specify that it should create the account if not present, and choose for it to be hidden. I would not trying manually fixing this as there's no guarantee doing it that way that the JSS will pick up any new password for that account.
Posted on 10-20-2017 08:27 AM
@mm2270 Yes, that's exactly what I am saying. Not sure what else was gone except that all the users in the dslocal subfolders were wiped. Ok, I'll try the QuickAdd in Recon.
Posted on 10-20-2017 08:34 AM
In Recon, the options:
" Ensure SSH is enabled",
"Use existing site membership, if applicable"
- Should they be checked?
Posted on 10-20-2017 08:40 AM
For the SSH option, only if you want to ensure SSH is enabled on the Mac. You can specify that only the Jamf management account have SSH enabled access for it, in case there is a security concern around that.
As for the "Sign with" option, generally no, unless you have a developer certificate that you want to use to sign the QuickAdd pkg. Otherwise it's not needed.
As for "Site membership", that just means if a Mac is already enrolled into a Site when the pkg runs, like in this case where you are re running a QuickAdd, then it will enroll it back into the Site it was part of before. If you don't use Sites, then it can be left unchecked.
So in all 3 cases, you will need to decide if you need those on. Do you recall what you used when you did your original enrollments? If possible, go back and look at what you used the first time around.