New Domain / Active Directory

[billystanton]

Hi,

We are setting up a new domain in our infrastructure that will be completely separate from the old one.

All users are bound to AD and use mobile accounts.

Can anybody share previous experiences in doing this? We would like IT admins to unbind a machine from the current (.local) domain and then bind to the new (.com) domain.

We would then ideally like the user to just login as if nothing has changed.

We will setup new AD accounts using the same login name and password as is currently used.

Any advice for a plunge into mindless testing?

Thanks!

[stevewood]

@billystanton I made the same type of move a few years ago, but had to deal with FileVault also. I used a Self Service policy to let the users move themselves. Can be done as a logout policy instead. You read about it here:

Move Domains

[billystanton]

Thanks @stevewood

I should mention that all users are mobile accounts, and we aren't doing migrating users from old AD to new, we are setting up new users.. I believe they therefore have a new ID?

Thanks

[mm2270]

Will the previous AD accounts from the old domain and the accounts on the new domain have the same UID? Meaning, besides just the name of the accounts, will all other settings match exactly, other than where they are coming from?
If so, it will make the job a little easier, but keep in mind that cached AD mobile accounts, when created, pull down some specific settings from the domain they originated from that might need to be adjusted for the accounts after the migration.

As an example, if you do something like:

dscl . read /Users/someuser OriginalNodeName

You may see that it shows something like
/Active Directory/OLD_DOMAIN/domain.company.com as the string it returns, meaning the account and the Mac know that it originated from your older domain and not the new one. I can't say I'm 100% sure how much that affects things during such a migration, but it may.

My rudimentary advice would be to remove the local AD cached accounts from directory services on the Mac, leaving the home folder intact, and then use a script to recreate it from the new domain, by calling on the /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount binary to do it. The new account can be paired up with the original home folder since the names will be the same.
its a little extra work of course, but it will give you the best experience for your users I think.

Hope that helps, and feel free to post back with any questions.

EDIT: I see you answered one of my questions at the same time I was posting, about the UIDs. If they are going to be different ids, then you will definitely need to recreate the accounts. Its not going to be as simple as rejoining the Mac to the new domain and users just logging in, sorry to say.

[billystanton]

@mm2270 They won't be carried over so there won't be the same UID.

I've just tested with a dummy account here and it signed in but all the permissions are messed up and everything is esentially broken!

Almost all that you have explained has gone way over my head!

I understand that we should remove the account, but keep the home folder... then unbind, bind to new AD, login with new AD credentials and then somehow use the old home folder for the new acc?

[mm2270]

@billystanton Basically, yes. If you remove the account from directory services using something like

dscl . delete /Users/username

The above only removes the local dir services record and doesn't touch the home directory.

Then unbind and rebind the Mac to the new domain.
Upon login the Mac should create a new local directory services account with the user's name. (Make certain your new AD binding config is set to create mobile accounts at login without prompting for confirmation) I believe the OS would use the existing home folder (of the same name) that is there for the new account's home folder.
You might however end up with permissions problems, as you mentioned seeing. This is because, while the owner name will be the same, the group may not be. For example if you do an ls -l on the account in Terminal, like

ls -l /Users/username

It will show the group for the folders and files, which may be something like OLD_DOMAINDomain Users That can be fixed in a script after the fact to set the group to the correct string if need be though.

To take this all a step back for a moment, how do you plan on doing this migration? Will it be completely driven and controlled by IT, or will the switchover be something you allow users to do out of Self Service when they are ready?

[billystanton]

@mm2270 I see... The migration will almost defiantly IT driven. We would (naturally) like Self Service to take care of a lot of the hassle, but we are quite happy to go round to each users machine and un bind and re bind manually. We are still in a position to be able to do this.

For the dummy account test, all I did was unbind from current AD, and then bind to new AD.

Restart and login to the machine using the same user that was displayed before...I set the password on the new AD to be the same. This is the point when the permissions were broken. I'm guessing because of the UID change.

I have since then run the following script (https://macmule.com/2013/02/18/correct-ad-users-home-mobile-home-folder-permissions/)

All seems to function normally, though I need to see if I can now change the AD password via the Mac.

Can you see a problem with going down this route??

[stevewood]

@billystanton the script I posted in that other discussion does exactly what you need:

• disconnect from the old domain
• connect to new domain
• change permissions on home folder to new domain user ID

End users just login with their new ad domain info.

And yes this works for mobile accounts.

[billystanton]

I see, I will give it a go!

Thanks!

[billystanton]

The next issue I have is that all config profiles that were run on the machine prior to making the changes have now disappeared.

I have setup the new AD in "LDAP" on JSS, but I can't seem to assign the machine to the new user in AD. It just finds the older user.

Do I need to remove the old AD user from JSS first in order to find the new?

The issue is that we will have a mixture of users from the old AD and a mixture from the new AD, so we can remove the current LDAP server.

I should add that we scope out profiles based on department, so I think the JSS doesn't know that this machine should have those policies. Unfortunately the department name is the same on both AD's, and we are going to struggle to change it.

Thanks