Automate conversion of local standalone accounts to managed, mobile

Its possible to convert local accounts to cached AD mobile ones. There are several threads here already that discuss methods of doing this. You'll see a few different opinions on how to do it when you find those.
Personally I feel the only truly reliable way to do it is to delete the local account from the Mac's local directory services, leaving the user's home folder intact, then create the cached AD mobile account with a script using the 'createmobileaccount' binary. and finally, pair up the new AD based account with the user's previous local home folder. Some folks have had success with simply changing values in the local accounts settings, but I don't know that I trust doing that.

For some threads that will help guide you on converting local to AD, check these out:
https://jamfnation.jamfsoftware.com/discussion.html?id=19433
https://jamfnation.jamfsoftware.com/discussion.html?id=14031

There are certainly more than just those 2. You'll see that @rtrouton has a link to his script posted on both threads that will help with this process that you should check out.

The bigger problem you're going to face is around FileVault encryption. For one, once you remove the existing local account and replace it with the AD one, if I'm not mistaken FV2 will no longer recognize that account as being enabled for FV2 unlocking privs, despite having the same name. The reason is, it stores the GUID for the account as its identifier to know that its the proper one trying to unlock the Mac, for security reasons. If you run the following command on a FileVault encrypted Mac, you will see something like this (in this example, the account enabled for FileVault is "mike"

$ sudo fdesetup list
mike,DADEB212-DFE3-452E-B2E3-9D40G3A62AD8

That long string after the name is the GUID. You can also see this string with the following command in Terminal:

$ dscl . read /Users/mike GeneratedUID
GeneratedUID: DADEB212-DFE3-452E-B2E3-9D40G3A62AD8

Once the AD based account is on the Mac, and the old one is gone, the above will return a different string, meaning FileVault won't recognize that account as being the same one enabled to unlock the Mac at the FileVault screen. In fact, if you were to then run the sudo fdesetup list command again, it will likely show something like:

(null),DADEB212-DFE3-452E-B2E3-9D40G3A62AD8

Meaning it no longer knows exactly what account can unlock the Mac since the only one that was on there was removed. I could be wrong on the above. I don't know if I've ever tried removing the only account enabled for FileVault on an encrypted Mac. Its possible FV2 won't allow it to happen, but I think it will and will just get messed up.
For more info on everything FileVault, refer again to Rich's blog. Here's a link to all or most of his FileVault 2 related entries: https://derflounder.wordpress.com/?s=FileVault+2

If I were doing this, I'd have everyone decrypt their Macs to start with, then do an AD binding in a policy, then trigger a policy to replace their local account with an AD cached one, then finally trigger the FileVault encryption policy to kick in so you can get their proper account enabled for it, and get the Recovery keys escrowed in the process.

You've inherited kind of a messy situation to fix. Its not hopeless, but its going to take a bit of work, research and testing to get it all correct. This is only accounting for the accounts that have a matching name in AD. I'm not sure what your plan is for the ones that have a completely different local account name.

Hope some of the above helps though.

Ian,

Is there a reason why you have to use AD? With IBM using local accounts there is very little the Mac "get" from binding to AD.

From the Apple side of things AD is on it's way out... Less and less people are binding to AD.

C

@mm2270 Thanks a lot, plenty to think about there! I was trying to make things as minimal touch as possible for our technicians but tbh a staged rollout will be a good learning opportunity for our staff; it'll ensure we gather information about devices that's been pretty patchy before now.

@gachowski Not using AD is not an option as far as my organization is concerned - we're Windoze centric and our Macs need to adhere to our password policies, utilize SSO etc.