Hashing password (for "create hidden admin user" line in QuickAdd)

[donmontalvo]

We need to add a hidden admin user account to a QuickAdd package we're sending to a client. We want to use the jamf binary. How do we hash the password? -Don

####################################################
## Create hidden admin account "jdoe"
####################################################
/usr/sbin/jamf createAccount -username 'jdoe' -realname 'jdoe' -passhash '%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx' -admin -hiddenUser

[ernstcs]

Easiest thing to do is in your test environment image a box and set the account you want on the accounts tab, make sure you DONT check the box to Reboot after Imaging, and then pull the line out of the FirstRun script on your imaged partition. =)

Cheers,

Craig E

[donmontalvo]

Hi Craig,

I ended up creating a new QuickAdd with the account info we wanted, then I pulled it off the embedded script, copied to the QuickAdd we already had. :D

Don

[tlarkin]

You may also want to put the home folder outside of /Users if it is to remain hidden. That way you can assume later on in your policies and scripts that account won't be affected by anything.

[donmontalvo]

Yep, these kinds of details are why we went with the idea of creating a temporary QuickAdd package using the desired account info, then copying the "add hidden user" entry, pasting into our current QuickAdd. :)

The JAMF toolset surprises me more and more every day. It's stuff like this that shows JAMF clearly thought out the details when coming up with the design of their tools. I guess I was thrown off in the beginning by the "Easy button" appearance of the JAMF tools. There are still a few areas that can use a reworking, but for the most part, the tools can do just about anything you want. Where it can't, it offers hooks into technologies that can.

Don

[tlarkin]

If you look at my post imaging scripts I wrote, I put all local admin accounts home folders in /private/var this is because by my OS image design, I do not want any local user account living in /Users. This way if a client machine has been hacked, or more likely some student has given them self admin privileges I know by design no admin accounts should ever have home folders in /Users.

This way I can write scripts that loop through /Users and then check group membership of the admin group, and I will not get any false positives because my local admin accounts do not reside in /Users. I started doing this almost at the beginning of my employment here at the school system 4 years ago. I did it to hide the accounts from the students at first, and didn't really think about it beyond that.

However, you give a teenager a laptop and they will eventually find a way to bypass your security. Physical access trumps all security, and once one of them figured out how to ask the right question in Google, it was game over. So instead of me trying to lock down the system tight as I can, and restrict everything, and create a more complicated and less appealing end user experience I now just play detective instead.

I have a script like I mentioned earlier that loops through /Users, if it finds any account in the admin grouup a manual trigger policy is executed that puts a text file in /Library/Receipts and then that policy log is my proof of abuse of AUP and I just hand over the log files to the administration and let them deal with it. Where as before we were trying to think of every possible ability we had at our dsiposal to prevent it, which like I said, given they have physical access to the machines and all the time in the world because they are teenagers, some of them will find the ways to bypass security. Things like removing RAM to clear firmware and then booting into SUM and removing the AppleSetupDone file to create a local admin account is really something we cannot prevent.

Working here and using Casper has definitely changed my philosophy on client management and OS imaging.

just my 2 cents

have a good weekend

-Tom

[Cem]

Hi Don,

I use instadmg's createUser package. You can use /private/var/ path for the home folder and use UID 499 (anything less than 500 will make account invisible). Package has a functionality to hash the pw too.

Here is the link for read me file and the package.

http://instadmg.googlecode.com/svn/trunk/AddOns/createUser/

Cem

Sent from my iPhone

On 10 Dec 2010, at 20:00

[Cem]

Hi Don,

I use instadmg's createUser package. You can use /private/var/ path for the home folder and use UID 499 (anything less than 500 will make account invisible). Package has a functionality to hash the pw too.

Here is the link for read me file and the package.

<http://instadmg.googlecode.com/svn/trunk/AddOns/createUser/>http://instadmg.googlecode.com/svn/trunk/AddOns/createUser/

Cem

Sent from my iPhone

On 10 Dec 2010, at 20:00

[Cem]

Forgot to mention, by default createUser.pkg creates visible accounts. So it requires tweaking the postflight script (home folder path and UID number).
Cem

Sent from my iPhone

[loceee]

Did anyone ever find a solid way to generate a hash without the convoluted capture of a QuickAdd or postinstall script?

It would be nice to run jamf hashMyPass -password 'Password123'

[ctangora]

BUMP

Anybody have a simpler way? Or has JAMF released what it needs so we can at least do it without the bloody head banging?

[loceee]

Bump again. :P

[Sonic84]

Bump....