Anyway to find out what the jamf management account password is from the JSS page

rgranholm
Contributor

We somehow, have no idea, what the password is from the user initiated enrollment package.

Is there anyway to decipher what this password is shown here? http://take.ms/ya53W

10 REPLIES 10

stevewood
Honored Contributor II
Honored Contributor II

@rgranholm no, but you could spin change that password if you need to via a policy:

optional image ALT text

rgranholm
Contributor

Thanks, will look into that, due to some other issues we're having to re-enroll users, but this is good to know. What do you mean by "spin change" ... just curious?

-r

mm2270
Legendary Contributor III

Its whatever the password is you, or someone, set up in your JSS under Global Management >> User-Initiated Enrollment >> Platforms >> OS X. There are Username and Password fields there that you use to set up an account to be created when doing the enrollment.

If you don't know what you entered, you'll need to reset it there. For any Macs that are already enrolled, you should be able to set up a Management Account payload in a policy that resets the password to something else.

rgranholm
Contributor

Hmm can you also let me know now how to delete the old management account from terminal or elsewhere, it's hidden, and on reenrollement, sees the old account and won't let me use it for enrollment.

We have already deleted the computers from the JSS.

stevewood
Honored Contributor II
Honored Contributor II

@rgranholm I meant change the password. I use the term internally "spin the password" to refer to changing it.

To remove the old user you'd need to use dscl locally on the machine to remove the user:

dscl . delete /Users/<username>

That should take care of it.

rgranholm
Contributor

Yeah I tried that, but these are old jamf management accounts, so don't they live somewhere else, and are hidden?

Can you confirm the management account that get's created is a local account on the computer with administrative privileges? If it's just some other type of account only JAMF can use and it's not any sort of security hole to simply abandon that old account, then I'll just ignore it.

Thanks!

-r

mm2270
Legendary Contributor III

Its a regular local admin account on the Mac. Nothing special about it. They can and often are created as "hidden" which puts their home directory in /private/var/ but deleting an account from dscl always uses the /Users/ path regardless of where the actual home directory is. But, you may need to go and remove the actual home directory as well once you locate it. Deleting it from dscl only removes the local directory services record, not the home folder.

rgranholm
Contributor

Awesome thanks!

Okay, but if it is a local admin account, it has the power to delete other accounts and change files if someone used it via SSH or through terminal, correct?

mm2270
Legendary Contributor III

Yep, pretty much. If security is an issue here, then you'll want to remove it. but.. since even you don't know the password for the account, what are the chances anyone else would? I guess I'm saying I don't see it as a huge risk, but that's your call on whether its worth just leaving it alone.

Here's what I might do about it. The JSS knows what the account name and password is for Macs enrolled with that account. It has to or it can't actually manage the Mac in some respects. So, set up a policy that deploys a new QuickAdd.pkg to any Macs using that old management account to get them enrolled with a new management account that gets created in the QuickAdd. Then later set up a policy that will remove the old management account, so you only have the one on there.

That's only one idea. There are probably a half dozen different ways it could be handled though.

rgranholm
Contributor

Thanks!