Skip to main content

I am in the process of migrating my users from using a mix of OD and AD to a new AD domain. The users are all local users on their machines, and all laptop users have FileVault2 enabled. I would like to do this via Self Service so that the users can move themselves when they are ready.

I have cobbled together a script that works for the migration of the user: removes any current OD or AD bind, deletes the local account with dscl, binds to the new domain, changes ownership of the home folder to the new AD user. The problem I am having is with the FV2 enabled devices. Once you delete the local user account with dscl, the user is not part of FV2 anymore.

I've tried using cocoaDialog to get the user's password and then use fdesetup to add the user, but the user has to exist locally first. That means the user has to login to the machine once before I can add their user to the FV2 creds.

I've thought of a few ways to possibly handle this using a logout policy to set another logout policy, modifying the local user via dscl instead of deleting the user, and decrypting the drive before doing the move.

Has anyone had to do this before, and is there an easier way? With the amount of time I've been working on this I could have probably manually moved everyone, but I'm too stubborn to do that. :-)

Thanks!

Looks like a trigger policy that would bind the system to the new domain. The script would need the ID number of that policy (which you would need to create) to call it in this section:

## using a JAMF policy

jamf policy -id $9

I've been through this migration process and as a seasoned Casper admin it was very difficult, so I wish you the best of luck.

@alexjdale I have created the Jamf policy to bind to the new AD, how do I find the policy number is my confusion at this time.

Thank you,

@fneidhardt when you click on your policy in Casper, in the URL you will see the ID after the "policies.html?id=" part of the URL.

@alexjdale I have created the Jamf policy to bind to the new AD, how do I find the policy number is my confusion at this time.

Thank you,

Hey Everyone, We have been tasked to move all machines to a new domain, we have adapted the above script from @jason.bracy But it seems as though the machine does the migration as expected and changes permissions but it doesn't seem to ask for the user to change the password at first login. We migrate the user with the same PW, then ask the user to change it at first login. It seems like it is still using the mobile profile and PW not the new domain PW.

Anyone experience this or know how to get the mobile profile to see the new domain.

Otherwise the script works great! just need to get past this issue!

It's been a while since I did this, let me take a look and see where the issue may be.

Been testing this script in combination with a policy that binds the machine to the new AD domain. All seems well except when logging in with my test user, I keep getting keychain errors along the lines of "no keychain found", "no AuthToken", etc. Also, Directory Utility for my same test user is still looking at the old AD domain under the AuthenticationAuthority attribute.

If I run: 

dsconfigad -show | grep -I "active directory domain' | awk '{ print $5 }'

it returns the correct (new) AD domain as does: 

dscl /Search read /Groups/Domain Users | awk '/^AppleMetaNodeLocation:/,/^AppleMetaRecordName:/' | head -2 | tail -1 | cut -c 2-

which returns the full Active Directory path.

It seems like the machine migration works great, its the user migration piece that I'm either missing something or not setting things up/prestaging correctly. Any help would be most appreciated; been trying to slog my way through this since Friday.

@bjharper Apple changed how FileVault works in 10.13, so since this script was written back in 2014 I was using 10.9/10.10 at the time. I really haven't gotten my head around how to manage FileVault in the CLI with 10.13. Seems like Apple doesn't want us to do that anymore.

@jason.bracy Based on a few things I found on Der Flounder, looks like Apple made changes to FV on 10.13 and with APFS by adding a 'SecureToken' attribute that's required to be present for an account to be able to unlock a FV encrypted disk.

From Der Flounder: (https://derflounder.wordpress.com/2018/01/20/secure-token-and-filevault-on-apple-file-system/#more-9561)

"As part of Apple File System’s FileVault encryption on mac OS High Sierra, Apple introduced Secure Token. This is a new and undocumented account attribute, which is now required to be added to a user account before that account can be enabled for FileVault on an encrypted Apple File System (APFS) volume. To help make sure that at least one account has a Secure Token attribute associated with it, a Secure Token attribute is automatically added to the first account to log into the OS loginwindow on a particular Mac."

I'm reading more into this to see if this is something that needs to be added to your script. I'll update here if I make any headway with it.

Terms & ConditionsCookie settingsAccessibility statement