Creating users

When we were mostly running 10.5 & 10.6 we used mobile accounts but now apple is directing people away from them.

I have not heard of Apple recommending people not use mobile accounts, so this is news to me if true.

But, back to the issue, it sounds like you want the students to go through the regular setup process, as if it were a new Mac out of the box, but still have the management framework installed, hidden admin account, etc.

I think your best bet is to remove the hidden .AppleSetupDone file at the end of the imaging process before the student gets it. That can be done via the jamf binary, as in:

[sudo] jamf deleteSetupDone

The next time the Mac boots up/restarts, the regular Apple Setup Assistant should launch and allow them to create an account for themselves. Only thing is, this will be an admin user by default, I believe. So if this is a concern, you'll need to create a policy that runs a script after the user actually logs in that removes them from the local admin group.

Something like this syntax should actually work (not tested at all so please test)-

/usr/sbin/dseditgroup -o edit -d $3 -t user admin

That can be plugged into a login policy that runs Once per User.
I would recommend fleshing out the script with checks on the UID of the account that is currently logged in to make sure it will only run on an account with UID of 501 or higher, that way if you ever happen to log into your hidden admin account it won't affect it or cause issues.

I haven't heard about Apple directing folks away from mobile users (network accounts that have cached authentication and local homes.) I have heard them directing folks away from using network users (network accounts where the home is on a remote server and there's no cached authentication on the Mac itself.)

my mistake... I had meant network users. Some that i have talked to have directed us towards local users or users with home directories on removable media.

if we have them go through the setup assistant is there any way that we can force them to restart once they create their account to ensure remote management and any other settings we do prior to handing out the laptops is left alone?

The 'dseditgroup' command is immediate. They will become standard users as soon as the script runs, with no need for restart or logout/login. However, in my experience with the Casper Suite there is a brief delay of anywhere from 5 to 10 or more seconds when "login" policies run, unfortunately, so its possible they could open System Preferences and unlock the Sharing tab for example, before it actually kicks in. (I believe the delay is due to the fact that the jamf loginhook script runs at login, which tells the Mac to check in with the JSS for any policies using the 'login' trigger, so its not a true loginhook script execution)

I'm not sure of the best way to avoid that. You can perhaps have the Once per User on login policy launch jamfHelper as a full screen app blocking the users from doing anything further while it makes the change to their account, then kill jamfHelper and immediately reboots the Mac? There would still be a brief delay, but at least it will lock them out from the computer while it revokes their privs in the background and then reboot. There are probably more secure ways of accomplishing all of this though.

jfreeseman,

Do the users have to be purely local users, where the username and password information is stored only on the specific Mac that the student is using? Or can they be mobile users, where the account and password information is coming from a directory service (like Active Directory or Open Directory) and cached locally along with a local home folder?

The reason I'm asking is that mobile users are standard users by default when they log in. Using mobile users would also allow you to skip having the students set up their own local accounts; you could just give them a username and password to use on their machines.

Thanks for the info everyone.

@rtrouton

in the past the school has used mobile user accounts. I am a newbie to mac servers so I am not sure how to get the mobile users to not sync files with the servers in the school. In past places that were mostly windows environments I dealt primarily with local users. If mobile user accounts can be created and not have their data synced to the local server in house I would be all for it.

I am also wanting to migrate the MCX settings from their server to the JSS as I think it would be easier to manage because of the server being retired/replaced soon.

Your Mac's mobile accounts do not need to sync anywhere if you don't want them to. In fact, you have to go through a bit of setup to even make that happen. We use mobile accounts on all our Macs (99% laptops) with AD accounts. The settings in Directory Utility are what determines them being mobile accounts, or cached credentials.
Do you have an underlying AD environment there, or is it strictly OD? If you have AD, have you considered setting the users up there and binding the Macs to AD? That should get you where you want to be without having home folders located anywhere except the local drives. You can do the same if its just OD I believe, but its been a while since I've used OD based accounts, so my memory on how that works is getting fuzzy.

everything is OD here.

@jfreeseman

I am managing a 1to1 rollout of 500+ macbook airs and decided against putting all the kids in OD and I just having the kids setup their accounts. After imaging I delete the .AppleStartupDone file via casper and each kids goes through a setup process with the ICT Coordinators. MCX is managed via Casper. Also when they setup the account there is a launch daemon that removes any account with a UID over 500 from the admin group so the kids are never admin, have a white list of approved apps and are managed via a static and smart groups via Casper.

I have policies and daemons in place that manage software updates, computer naming... etc.

If you want more info just let me know...

Hey Everyone,

A couple things to consider here, best practices would be debatable in each scenario. here they are:

1) Use the AppleSetupDone file to have users create their own local accounts, then via managed preferences and/or scripts restrict the account. You can even have MCX restrict Admin accounts. There are obvious caveats with this model.

2) Pre-populate the local accounts based on a script that checks a master list and then deploys the user account. The caveat here is you gotta do the leg work up front, test it, and support this solution.

3) Go into a end user model of ownership and let them be admins, but let them know support is going to just reimage their machine if they mess up.

You have to figure out what is best for you.

Thanks,
Tom