locked
Samba to Active Directory Migration (with a bit of NT 4 in there too) RRS feed

  • Question

  • Hi

    Sorry if this has been answered somewhere but I spent three days searching google with no luck

    I have three domains currently

    Domain1 - NT4 Domain with NT4 PDC and BDC
    Domain2 - Samba Domain
    Domain3 - Windows 2008 Active Directory

    We are moving everyone to Domain3 and the Domain1 is not an issue.

    However I do not know how to move the users from the Samba server to the AD and maintain their SID History.

    • I thought about putting an NT4 server in the samba network and promoting it to PDC but I am not sure of the impact of have an NT4 BDC where Samba thinks its the PDC
    • I thought about migrating users to the NT4 Domain1 and then to the AD
    • I thought about migrating the users directly to the AD
    There is domain trusts running between all three domains but I cannot find a documented definative process that will achieve what I need.

    Does anyone know the best way to do this?
    Thursday, July 3, 2008 10:18 AM

Answers

  • You can use ADMT Tool to Migrate Samba users to AD but be aware from some
    of the issue which I am posing below.

    1. Administrator password must be THE SAME on the Samba server, the 2003
    ADS, and the local Administrator account on the workstations. This is
    not documented. (Perhaps this goes without saying, but there needs to be
    an account called "Administrator" in your Samba domain, with full
    administrative (root) rights to that domain.)

    2. In the Advanced/DNS section of the TCP/IP settings on your Windows
    workstations, make sure "DNS suffix for this connection" field is blank.
    This is not documented.

    3. Because you are migrating from Samba, user passwords cannot be
    migrated. You'll have to reset everyone's passwords. (If you were
    migrating from NT4 to ADS, you could migrate passwords as well.)

    4. Disable the Windows Firewall on all workstations. Otherwise,
    workstations won't be migrated to the new domain. This is not documented.

    5. When migrating machines, always test first (using ADMT's test mode)
    and satisfy all errors before committing the migration. Note that the
    test will always fail, because the machine will not have been actually
    migrated. You'll need to interpret the errors to know whether the
    failure was due to a problem, or simply due to the fact that it was just
    a test.

    There are some significant benefits of using the ADMT, besides just
    migrating user accounts.

    1. You can also migrate workstations remotely. You can specify that SIDs
    be simply added instead of replaced, giving you the option of joining a
    workstation back to the old domain if something goes awry. The
    workstations will be joined to the new domain.

    2. Not only are user accounts migrated from the old domain to the new
    domain, but ACLs on the workstations are migrated as well. Like SIDs,
    ACLs can be added instead of replaced.

    3. Locally stored user profiles on workstations are migrated as well,
    presenting almost no disruption to the user. Saved passwords will be
    lost, just as when you administratively reset the password in Windows ADS.

    4. The ADMT lets you test all operations before actually performing the
    migration. You can migrate accounts and workstations individually or in
    batches. User accounts can be safely migrated all at once (since no
    changes are made on the original domain); I recommend migrating only one
    or two workstations as a test before committing them all.

    I'm fairly impressed with the Active Directory Migration Tool. It sure
    made my job easier, both times I used it (once migrating from NT4 to ADS
    2003; second time from Samba 3 to ADS 2003). The three gotchas that I
    labeled "not documented" are things that tripped me up, but (thankfully)
    I was able to resolve.

    Thanks

    Syed Khairuddin
    Thursday, July 3, 2008 10:41 AM

All replies

  • You can use ADMT Tool to Migrate Samba users to AD but be aware from some
    of the issue which I am posing below.

    1. Administrator password must be THE SAME on the Samba server, the 2003
    ADS, and the local Administrator account on the workstations. This is
    not documented. (Perhaps this goes without saying, but there needs to be
    an account called "Administrator" in your Samba domain, with full
    administrative (root) rights to that domain.)

    2. In the Advanced/DNS section of the TCP/IP settings on your Windows
    workstations, make sure "DNS suffix for this connection" field is blank.
    This is not documented.

    3. Because you are migrating from Samba, user passwords cannot be
    migrated. You'll have to reset everyone's passwords. (If you were
    migrating from NT4 to ADS, you could migrate passwords as well.)

    4. Disable the Windows Firewall on all workstations. Otherwise,
    workstations won't be migrated to the new domain. This is not documented.

    5. When migrating machines, always test first (using ADMT's test mode)
    and satisfy all errors before committing the migration. Note that the
    test will always fail, because the machine will not have been actually
    migrated. You'll need to interpret the errors to know whether the
    failure was due to a problem, or simply due to the fact that it was just
    a test.

    There are some significant benefits of using the ADMT, besides just
    migrating user accounts.

    1. You can also migrate workstations remotely. You can specify that SIDs
    be simply added instead of replaced, giving you the option of joining a
    workstation back to the old domain if something goes awry. The
    workstations will be joined to the new domain.

    2. Not only are user accounts migrated from the old domain to the new
    domain, but ACLs on the workstations are migrated as well. Like SIDs,
    ACLs can be added instead of replaced.

    3. Locally stored user profiles on workstations are migrated as well,
    presenting almost no disruption to the user. Saved passwords will be
    lost, just as when you administratively reset the password in Windows ADS.

    4. The ADMT lets you test all operations before actually performing the
    migration. You can migrate accounts and workstations individually or in
    batches. User accounts can be safely migrated all at once (since no
    changes are made on the original domain); I recommend migrating only one
    or two workstations as a test before committing them all.

    I'm fairly impressed with the Active Directory Migration Tool. It sure
    made my job easier, both times I used it (once migrating from NT4 to ADS
    2003; second time from Samba 3 to ADS 2003). The three gotchas that I
    labeled "not documented" are things that tripped me up, but (thankfully)
    I was able to resolve.

    Thanks

    Syed Khairuddin
    Thursday, July 3, 2008 10:41 AM
  • sorry for the delay with my reply.  This was pretty much the answer I was looking for.

    Thanks for assistance

    Regards


    James
    Monday, July 7, 2008 3:39 PM
  • I have similar project on my hands.  However my Samba is still version 2.2.8.  Do I have to update Samba first or should the above procedure work?

    Thanks so much!   Like James, I've been search for an answer for quite some time.

    Regards,
    Shawn
    Friday, April 3, 2009 9:54 PM
  • Hi,

    I need to migrate from Samba 3 to Windows Server 2003 and it's proving to be quite difficult. Essentially the SIDs will not migrate across due to Tcpipclientsupport and auditing not being enabled on the Samba domain controller, well, because it's not a windows box. It's linux so it's never going to be enabled.

    Is there any easy way to do this migration such as going to NT4 first? Will this work?

    Any suggestions greatly appreciated!
    Monday, April 27, 2009 1:34 PM
  • Hi Photek420,
    Did you manage to get this working?
    Thanks
    P

    Celtic
    Tuesday, May 19, 2009 9:53 AM
  • Hi Syed,
    Would you have anymore documentation on this? e.g. how do you deal with requirement of Tcpipclientsupport and auditing needing to be turned on. Also are trusts a requirement for it to work.
    Any help would be appreicated thanks
    P

    Celtic
    Tuesday, May 19, 2009 9:57 AM
  • I have done this several times and while you can use ADMT etc.. its too slow more annoyingly it can get 99% of the way through and die particularly on large profiles.

    Firstly some house keeping:
    • Clear all temp files ( %userprofile%\temp ) within all profile(s) you wish to migrate.
    • Clear Internet Explorer (and any other Internet Browser) cache from the profile(s) your are wanting to migrate.
    • If users are using Outlook/Outlook Express without using MS Exchange I recommend you backup the mail passwords (Thunderbird and other third Party applications usually do not have any problems) as the Outlook password will get wiped in the next steps. A good utility I use is this .
    • If this is your first time or your particularly worried clone/image the workstation so you can have a few goes at this.
    • Create any necessary domain logons on the new win2k3 DC (they do not have to be the same username).
    • Make sure on the workstation you know which folder belongs to which profile for each user profile you need to migrate within the documents and settings folder as you will not be able to as easily tell once you disjoin the domain.  This is particularly important for a profile that has been renamed several times as the folder name will not match the logon name.
    • Make sure you have a local (non Domain) Administator account created on the workstation that you can login to at all times.

    Domain Migration:
    • Dis-join the workstation from the samba domain (If you cloned the workstation you could do this with the network unplugged so the machine account still exists on the samba pdc saving you having to re-create it if you revert to using samba ).
    • Join the workstation to the win2k3 domain controller.

    The previous domain user profile(s) will now be unassigned but don't worry!  Download a utility by ForensiT called ProfWiz which has a free version that is adequate.

    Run this utility (make sure you are connected to the network):
    1. On the first screen you will be prompted to choose a domain user on the new domain that you are wanting to take over one of the old profiles on the workstation.
    2. There is an option to show unassigned profiles.
    3. Select the appropriate profile directory then click next. Providing you gave a correct username and profwiz can contact the new DC the program could take awhile to run it is resetting the SID within ntuser.dat and resetting ownership permissions on all the files within that profile directory this is why it pays to clear temp/cached files first.
    You can now re-run the utility multiple times to migrate other profiles.

    Some Notes:
    After joining the new domain do not login as one of the new user accounts that is for the existing profileas otherwise a new profile will be created meaning you will end up with two folders under documents and settings for the one user.  I usually logon as the new domain Administrator because this profile isnt being migrated and has the necessary privledges to run profwiz.  To avoid problems make sure you do not run profwiz as the user you are trying to migrate if you have logged onto one of the profiles being migrated since the computer has booted it is recommended to reboot the computer first before attempting a migration. Likewise after migrating user profiles I recommend a final reboot before logging in as the newly migrated  profile to avoid problems (usually it is fine but not always).
    Thursday, June 4, 2009 12:29 AM
  • I'm running into an error 1355 with regards to the Domain being unavailable, yet I've followed the steps documented.

    How can I build a trust between the new and old domain?
    Friday, June 12, 2009 1:12 PM
  • You can use ADMT Tool to Migrate Samba users to AD but be aware from some
    of the issue which I am posing below.

    1. Administrator password must be THE SAME on the Samba server, the 2003
    ADS, and the local Administrator account on the workstations. This is
    not documented. (Perhaps this goes without saying, but there needs to be
    an account called "Administrator" in your Samba domain, with full
    administrative (root) rights to that domain.)

    2. In the Advanced/DNS section of the TCP/IP settings on your Windows
    workstations, make sure "DNS suffix for this connection" field is blank.
    This is not documented.

    3. Because you are migrating from Samba, user passwords cannot be
    migrated. You'll have to reset everyone's passwords. (If you were
    migrating from NT4 to ADS, you could migrate passwords as well.)

    4. Disable the Windows Firewall on all workstations. Otherwise,
    workstations won't be migrated to the new domain. This is not documented.

    5. When migrating machines, always test first (using ADMT's test mode)
    and satisfy all errors before committing the migration. Note that the
    test will always fail, because the machine will not have been actually
    migrated. You'll need to interpret the errors to know whether the
    failure was due to a problem, or simply due to the fact that it was just
    a test.

    There are some significant benefits of using the ADMT, besides just
    migrating user accounts.

    1. You can also migrate workstations remotely. You can specify that SIDs
    be simply added instead of replaced, giving you the option of joining a
    workstation back to the old domain if something goes awry. The
    workstations will be joined to the new domain.

    2. Not only are user accounts migrated from the old domain to the new
    domain, but ACLs on the workstations are migrated as well. Like SIDs,
    ACLs can be added instead of replaced.

    3. Locally stored user profiles on workstations are migrated as well,
    presenting almost no disruption to the user. Saved passwords will be
    lost, just as when you administratively reset the password in Windows ADS.

    4. The ADMT lets you test all operations before actually performing the
    migration. You can migrate accounts and workstations individually or in
    batches. User accounts can be safely migrated all at once (since no
    changes are made on the original domain); I recommend migrating only one
    or two workstations as a test before committing them all.

    I'm fairly impressed with the Active Directory Migration Tool. It sure
    made my job easier, both times I used it (once migrating from NT4 to ADS
    2003; second time from Samba 3 to ADS 2003). The three gotchas that I
    labeled "not documented" are things that tripped me up, but (thankfully)
    I was able to resolve.

    Thanks

    Syed Khairuddin

    Hello I am migrating from Samba NT4 to Windows AD 2016; Do you think this will still work?

    Tuesday, August 14, 2018 7:47 PM