We have our Mac users configured with UNIX attributes in the AD. If we were to create a local account with their AD name and then have them login again when connected to the network, it'd fetch their AD account which has a different UID so I'm not sure how that would work...I've never actually tried it as we always set them up as AD accounts from the start. Let me check though and see what happens, it got me curios.

@hsekiv You probably do want mobile accounts enabled. There's been a problem observed where AD logins that don't have the "Create mobile account at login" option enabled don't work (the user's Home directory gets created as Read Only).

You might also want to re-think not having teachers, and anyone else, use their AD login to access the machine. I'm also in a school environment, and our district policy is that AD logins are required for auditing/accountability (that's also why we disable the Guest account). Once the teacher has logged in and their mobile account is created you can give it admin rights. Using only AD logins also allows everybody to print via PaperCut.

@jonlju Curious to your results as well.

@StoneMagnet AD is not a requirement for us, and since the laptops are assigned to each teacher, they are not intended to be shared. I deployed 7 MacBook Airs at the beginning of the year (Australia school year begins in Jan) with AD but when a teacher changed their AD password online (and not on the Mac) it resulted in keychain errors. I read the forums here and it seems to be a known issue with various workaround options, some of which are currently above my skill level.

PaperCut launches without issue when the username matches the AD username, and they are still prompted for their credentials when going to print.

Thanks for the info for the mobile account, I didn't really have any reason to not create one, so if I do go AD, then I can enable these to avoid possible issues.

@hsekiv We use mobile AD accounts, sometimes with unmanaged laptops that become managed the local account is the same as the AD account, this has not really been a problem once we started to use a third party app called NoMAD which resolves the keychain errors.

NoMAD syncs the local and AD password even if the laptop is not bound to the AD.

In the event that a local account already exists that is exactly the same name, profile name, after the binding, the local credentials take precedence. That is to say, the when attempting to login the local credentials are always taken first and AD credentials are ignored.

Thanks @bsuggett, that answers my question.

Just an update, have deployed the Airs without AD and guest account enabled. All working well. Any lab computers and relief staff laptops are setup with AD.