Posted on 02-21-2015 08:20 AM
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).
Solved! Go to Solution.
Posted on 02-21-2015 05:14 PM
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.
Posted on 02-21-2015 08:33 AM
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.
Posted on 02-21-2015 09:55 AM
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 ?
Posted on 02-21-2015 10:10 AM
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:
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.
Posted on 02-21-2015 11:46 AM
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.
Posted on 02-21-2015 05:14 PM
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.
Posted on 03-25-2015 07:48 AM
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 on 08-25-2015 02:20 PM
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).