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.

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 ?

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.

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.

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.

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.

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).