OT **HELP** Active directory migration

@Masenati just so I understand what you're describing:

- you are moving your computers from one AD domain to a new AD domain
- you did not move the existing users on machines from the old domain to the new domain
- users that have never logged into a machine can login to the new domain on the computer
- users that HAVE logged in before cannot login with their new domain credentials

You have to migrate the existing users on a machine from the old domain to the new domain. The users will have new User IDs (UID) in the new domain, and because of that their local accounts on the machines will not have the correct UID.

I had to do the same thing last year. I was migrating users from an old AD and from an old OD to a new AD server. I was able to complete most of the moves using a Self Service method. I came up with a script that would remove the the machine from AD or OD, bind it to the new AD, and apply the proper permissions to the user's home folder. You can read about it in this post:

https://jamfnation.jamfsoftware.com/discussion.html?id=11606

Now, I only had to deal with one user per machine, I did not have multiple users on a machine (not certain that you have that problem). If you only have one user per machine, then your process should be something like this:

- remove the machine from the old AD
- remove the local user account using dscl
- bind to the new AD
- reset the permissions on the user's home folder to the new AD user
- if you use FileVault, add the new user to FV

Hope that at least gives you a starting point. Post here on JAMF Nation and I'm sure one of us can help out.

@stevewood Thank you Very much for the quick Response sir so basically the users are all in the NEW AD domain but this to answer your questions we are moving from one AD to the next, user name is still the same and password , users that didnt log into the computer before can using new AD info, users that already logged in before cannot log in now, Only one user on the machine.. Funny thing is i already used that exact post (Wonderful script by the way) and no luck.. but ill give it a go again.

As @stevewood mentions, the only fix is to recreate the account from AD once the Mac is joined to the new domain. Despite the same username, the UniqueID assigned in the new AD environment is likely different, which is why they can't log in. AD logins use more than the username & password. The UID has to match or it won't work.

hey @mm2270 how can i change the UID to match the new AD?

Try running the commands by hand on a machine that has not been migrated. The problem you are running into is most likely a user ID problem. Just because the users have the same short name and same password on the new as they did on the old, their UID is different and that will prevent them from logging in.

Walk through the commands one by one and make sure you understand what they are doing and that they are working. Like I mentioned previously, your steps are the following:

- remove the machine from the old AD (dsconfigad -remove -user <networkuser>
- remove the local user account using dscl (dscl . delete /Users/<username>)
- bind to the new AD (dsconfigad -add <domain> -user <networkuser> OR use the JSS)
- reset the permissions on the user's home folder to the new AD user - if you use FileVault, add the new user to FV

Once you've tried that on a machine, you can find out where it is falling down.

It's easier to delete the user in the local database using dscl. When the user logs in it will re-create them in the local database with the new UID.

@stevewood keep getting error 14009 ?

Can you post the exact command you are using that gets that error?

What happens if you do:

dscl . read /Users/<username>

i get everything about the user except the fact is i still see the old DOMAIN on that user but a new user (myself) i see the new Domain @stevewood

whe i do dscl authonly i get 14090 error when i do it with my account its golden

Right, and that's why you have to delete the user from the local database and then login as that user from the new domain.

dscl . delete /Users/<username>

That removes them from the machine but DOES NOT remove their home folder. Then, as long as you have changed the permissions on the home folder, when they login with their new AD account it will log right in.

tried doing that still getting the error <dscl_cmd> DS Error: -14009 (eDSUnknownNodeName) not sure wht and im getting it on both accounts...

sorry for the troubles

Are you logged in as the user you are trying to delete or as an admin? You need to be logged in as an admin and you'll need to sudo the command. I should have made that clear just in case.

So when logged in as a different user, and you do:

sudo dscl . delete /Users/<username>

Do you get an error or does the user get removed from the machine?

still getting error even with sudo Yikes man i'm stomped for answer

...and you're entering what I'm sending exactly, besides replacing <username> with the user name you are trying to delete, right? The list command works, but delete does not?

So this works: dscl . list /Users/<username>

But this does not: dscl . delete /Users/<username>

It doesn't make sense that sudo dscl . delete would not work if its being run under an admin account that is different than the account being targeted. You shouldn't be getting an error unless there is something very wrong with the account in question. Or if the "admin" account you're running it from doesn't actually have sudo rights.
Also, make certain there is a space on both sides of the period. The UnknownNodeName error usually means it doesn't understand the node you're targeting with the command.

yup doing that @mm2270 still errors out

I've got a blog post and a script that may help here:

Blog post:
https://derflounder.wordpress.com/2013/11/20/fixing-permissions-after-changing-directory-services/

Script: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/migrate_local_user_to_AD_domain

As far as the script's operation goes, you should be able to treat an AD mobile user from your old domain as being a local user.

@rtrouton Thank you! I will give this a go and let you know! thanks everyone ! for taking the time out to help me figure this out.

Thanks

Question for you folks who have done this before: is there a way to migrate users across domains without deleting the mobile account and recreating it? That creates obvious problems when the system is FileVault encrypted: we usually have only that one user account enabled for FV, so deleting it leaves the system in a bad state.

I am hoping there is some way to re-home the mobile account to the new domain after the disjoin/rejoin. In our scenario, UIDs and usernames will all remain the same, only the domain changes. I can't test this for a couple weeks since our new domain is not ready yet.

@alexjdale it can get a bit tricky if you do not have a second account on the system. I migrated users that had FV on their systems. If you go back and look at the post I referenced earlier (https://jamfnation.jamfsoftware.com/discussion.html?id=11606 you'll see the script that I used to do it. It worked fairly well, although I did have troubles on about 10% of the machines.

The main trouble I ran into was users not putting in their correct password when prompted. Because of that, FV was unable to authenticate them and add them to the list of enabled FV users. This then caused the machine to reboot to the FV screen waiting for our admin user to login. It was an easy fix, but required me to come fix it.

Could you add an admin user to the FV on each machine temporarily? Then just remove the user once you've completed the migration. Or, decrypt the drive, migrate the user, then re-encrypt the drive.

I'm not certain how this will work if you are not changing UIDs of the users. I would obviously look at the method I used and test it in a lab environment to see if it will work.

Hope that helps a little.