Skip to main content
Solved

Create hidden account with Jamf binary - password security ?

M
Forum|alt.badge.img+12
  • May
  • Valued Contributor
  • 190 replies

Hi all

i need to create a hidden account with its home folder in /var/
if i place the account password in a script or add the full command including the password into Policy > Files and Processes isn't this a huge security flaw ?

/usr/local/bin/jamf createAccount -username <netadmin> -realname <"Network Administrator"> -password <p@55w0rd> -home </var/netadmin> -hiddenUser -admin

can anyone suggest a way to deal with this ?

or if i use CreateUSerPkg is the password any more secure in pkg on our JDS ?

and...

does using -secureSSH to the end of the command make it so no other users can ssh on ?

Best answer by mm2270

That could work too. I would say, yes, there is a difference between Files and Processes and the Reset Account Password. With the former, the command shows up in the policy logs, including any password passed to it as a string, and may show up in the system.log of the target Mac, at least until the log is rolled.

The latter, to my knowledge, does not show any command in the jamf.log or policy log nor anything in the system.log, so I'm thinking using the Reset Account Password is much more secure.

View original
    Did this topic help you find an answer to your question?

    5 replies

    M
    Forum|alt.badge.img+12
    • May
    • Author
    • Valued Contributor
    • 190 replies
    • June 28, 2017

    looks like CreateUserPkg may be the way to go, thanks @rtrouton link

    The problem i have with this approach is even if specify a Home Directory path in /var/ it doesn't get created,
    does it not create home folders for uid's under 500 ?

    M
    Forum|alt.badge.img+16
    • mm2270
    • Legendary Contributor
    • 7880 replies
    • June 28, 2017

    CreateUserPkg isn't being maintained anymore and it has now known issues with the latest versions of OS X. One of those issues is that it's not creating accounts as hidden even if you specify it to do so.
    However, you could use it as a start to get the base account in place, then run shell commands to move the account home dir and update the record in dscl (the NFSHomeDirectory path) into /var/ and make sure it's hidden. It's extra work, but at least you won't need to have the password in clear text in a script. Even if it's passed as a parameter it's not entirely safe.

    M
    Forum|alt.badge.img+12
    • May
    • Author
    • Valued Contributor
    • 190 replies
    • June 28, 2017

    Thanks,

    i was thinking i could maybe use the /usr/local/bin/jamf createAccount command in a policy > Files an Processes to create the account and home folder then immediately update the account password with a policy > Local Accounts > Reset Account Password,
    do you know if this would be a more secure way of creating the account from the JSS ?

    that said i'm assuming there's no difference in how the password is sent between Files and Processes and Reset Account Password ?

    M
    Forum|alt.badge.img+16
    • mm2270
    • Legendary Contributor
    • 7880 replies
    • Answer
    • June 28, 2017

    That could work too. I would say, yes, there is a difference between Files and Processes and the Reset Account Password. With the former, the command shows up in the policy logs, including any password passed to it as a string, and may show up in the system.log of the target Mac, at least until the log is rolled.

    The latter, to my knowledge, does not show any command in the jamf.log or policy log nor anything in the system.log, so I'm thinking using the Reset Account Password is much more secure.

    M
    Forum|alt.badge.img+12
    • May
    • Author
    • Valued Contributor
    • 190 replies
    • June 28, 2017

    Thanks for the help!

    i just checked and Reset Account Password doesn't seem to show the password in any of the logs where as Files and Processes does as you stated.

    Reply


    Most helpful members this week

    Terms & ConditionsCookie settingsAccessibility statement

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings