Policy to add admin user account

tcandela
Valued Contributor II

Quick add.pkg adds administrator hidden account, but I also want to add a seperate administrator account through a policy, this account will not be hidden. On macs I am currently enrolling this unhidden admin account is already created and was manually created prior to Casper. If an add a user policy is run on a Mac that already has that user created, what will happen?
New macs deployed via Casper imaging will get the hidden management account, along with the Unhidden admin account (probably add unhidden admin account via Casper imaging custom section).

1 ACCEPTED SOLUTION

jcarr
Release Candidate Programs Tester

Why not just a policy with the Local Account payload scoped to a smart group of computers that match Local Accounts does not have 'localadmin' (or whatever your account is to be called).

You could also set up a policy to reset the local account password for your admin account (same payload as above, but with different parameter) and scope that to all, but excluding the smart group you use above (since members of that group do not have the admin account yet).

No EA, .pkg or script needed.

View solution in original post

7 REPLIES 7

rderewianko
Valued Contributor II

Your best bet is to use: https://github.com/MagerValp/CreateUserPkg to create an admin account thats a package.

With macs that already have an admin account casper will create a separate account hidden for its own usage.

You could also scope these out so it would only run on computers where "non hidden admin account doesn't exist" making casper on first enroll, see that theres no account and run one.

tcandela
Valued Contributor II

I don't want to make a .pkg to create a user account, I'm going to use a policy or casper admin.

what i'm asking is, quickadd.pkg/casper admin is going to create my hidden casper admin account, my seperate 'user account' policy, I will make, will add an UNhidden admin account. On some macs that I enroll with the quickadd.pkg already have this UNhidden admin account - if these macs (with the UNhidden admin account already created) get the 'create local admin account' policy, what happens to the already created UNhidden admin account (account will be named the same in the policy)?

could I could create a scope that checks for this UNhidden admin account, and if it has it do not run the 'create local admin policy' on that mac ?

justinrummel
Contributor III

I would create an Extension attribute to find machines that do not have your non-hidden admin account, then scope your "Account Policy" to those devices. This could be done by:

  1. See if the path to your admin account exists (assuming it's the same location for everyone)
  2. Use dscl to see if the account has been created

I would choose the dscl command as it's much easier to get a response by scripting.

#!/bin/sh
unhidden=`dscl /Search read /Users/admin RecordName | awk '/RecordName: /{print $2}'`
[[ "${unhidden}" == "admin" ]] && { echo "<result>Available</result>"; } || { echo "<result>NOT Available</result>"; }

The find all the "NOT Available" machines to scope.

There are a lot of assumptions... but this should get you started.

davidacland
Honored Contributor II
Honored Contributor II

Hi, I haven't tried it but I would expect it to fail if there is an account already there with the same name.

In cases like this I would normally try it out. If you have a spare Mac or a VM test OS it would only take a few minutes to get an answer.

jcarr
Release Candidate Programs Tester

Why not just a policy with the Local Account payload scoped to a smart group of computers that match Local Accounts does not have 'localadmin' (or whatever your account is to be called).

You could also set up a policy to reset the local account password for your admin account (same payload as above, but with different parameter) and scope that to all, but excluding the smart group you use above (since members of that group do not have the admin account yet).

No EA, .pkg or script needed.

jduvalmtb
Contributor

You can also use the built in JAMF binary; this is what we use to create student account post-imaging with input from a Cocoa Dialog box

#!/bin/sh
jamf createAccount -username $USERNAME -realname $USERNAME -password $PASSWORD -picture /Library/User Pictures/Animals/Eagle.tif

In your case, add the -admin flag, hardcode the passwords, and scope it out via a script or Execute Command.
I ran a quick test adding a user with a pre-existing username, and was thrown an error:

There was an error. An account with the user name test1 already exists.

Bhughes
Contributor
Posted: 3/25/15 at 9:48 AM by @jduvalmtb You can also use the built in JAMF binary; this is what we use to create student account post-imaging with input from a Cocoa Dialog box There was an error. An account with the user name test1 already exists.

So... if the account already exists - and you have this policy set during enrollment, it will fail. Is there any logic that could be added to bypass this if the account is already there (machine that needed to be re-enrolled).