Domain migration from SAMBA 3 to ActiveDirectory (domain migration experience without downtime)

In a recently published article, TerAnYu described how a domain was migrated from Samba to Active Directory. The method was chosen, in my opinion, very interesting, but, unfortunately, when migrating a small domain (the author mentions about 70 office users in the text of the article), many interesting problems remained behind the scenes.
I, in turn, will try to ignore dump / restore user scripts and concentrate on describing the problems that have arisen and solving them. Perhaps the experience described will help someone reduce the labor involved in preparing the migration.

And, of course, I was cunning - it will be simple, but the most minimal.

Why abandoned Samba

To warn all further questions about Samba I will answer:
Initially, the architecture embedded in the Samba domain (by us in our installation, and not by the developers) had some miscalculations that showed themselves when scaling the domain. When the need arose for a complete restructuring of the domain, weighing the pros and cons, the management decided to migrate to Active Directory instead of reorganizing Samba.
I further consider this question closed.

Concept

I will briefly describe the concept of migration:

1. A list of ALL services using the domain is compiled (for authorization or as a repository of other information)
2. New sets of configurations are being prepared for these services to work with Active Directory.
3. Samba source domain data is saved in a dump.
4. The first controller of the new domain is being prepared on the Windows 2003 server (after migration, you can easily migrate the domain to controllers with a newer OS, but the next step will work only on the 2003 server). New server utility newsid set SID on a Samba domain (with an increase in the role of the SID will be the Active Directory domain SID'om)
5. Configured DNS.
6. In the created domain, security objects (users / groups / computers) are started in ascending order of their RID. In a domain with a single DC, RIDs are assigned strictly in order (for a large number of test import runs, I did not have a single case proving the opposite)
7. The user passwords are synchronized from the old domain to the new one.
8. Workstations and servers are being transferred to the new domain.
9. On services using a domain, the configuration changes to pre-prepared and tested.

Now consider each step in order.

The list of services using the domain.

This list should be all dependent on whether you are going to migrate somewhere or not. It is always important to know who and how uses your domain. The list should contain information about:

1. The host (s) on which the service is running.
2. About the protocol and authentication method used when connecting to the domain.
3. About the credentials with which the service is authorized in the domain.
4. About the format of service data stored in LDAP (if the service saves its data in LDAP)

You will need this list when reconfiguring services.

New configuration kits

They will be needed and they should be prepared in advance (we don’t want the business to be idle!).
What will change? It is logical that after the move you will still have a large number of linux systems that will need to
be integrated into the new domain (maybe you are not going to get rid of most of these systems)

1. Your services will no longer be able to verify the user's password by checking its hash with that stored in LDAP - they will no longer receive any hash from LDAP. We will have to redo everything (I mean services that will not work with kerberos) to check the password using LDAP bind. I highly recommend that wherever possible it is possible to use kerberos for authorization - this will make life easier for users and reduce the load on your domain controllers.
2. Now your domain may have nested groups, therefore, when checking the user's membership in a group, you will have to consider the possibility of having nested groups.
3. It makes sense to transfer your services to the use of kerberos (if this has not been done before).
4. For the data stored in LDAP, you will have to look for other attributes, or work on expanding the Active Directory schema (I strongly do not recommend using the first available attribute with the appropriate format - try to think about what your solution may turn out in the future). The benefit of setting Active Directory attributes is well documented - don't be too lazy to spend time studying the documentation.

Samba domain dump

Here the interesting moments begin.
Samba does not control the uniqueness of the SID. Therefore, in a large, distributed domain, you can get several security objects with the same SID. As a rule, this is a consequence of an administrator error and this error must be fixed immediately! The presence of several security objects with the same SID is unacceptable (but, unfortunately, in Samba domains I have come across this phenomenon more than once)
In a typical (on a manual from the Internet) samba RID installations begin to be issued from 1000. Unfortunately, using the method described above you cannot migrate security objects with RIDs less than about 1034 (I confess - I forgot the exact number, but it’s easy to figure it out - put a clean new controller domain and see the latest RID). When creating an Active Directory domain, a number of service security objects are created and they “occupy” these very first RIDs.
In these two described cases, there is only one solution:
did you preload and analyze the domain dump on Samba? Is X still far away? So there’s time to slowly sort through all the conflict situations and fix them with minimal downtime for the business.

Preparing the first controller of the new domain

First, try to ensure that there are no extraneous local groups and users on the server before the role is increased (otherwise they will increase the number of initially occupied RIDs) - this can happen if you use some kind of typical server image.
Secondly, you need to get newsid. It was deleted on the official site , but as they say, what got on the Internet ...
Yes, you can prepare a new domain next to the existing one (I highly recommend it), you don’t intend to keep the old NETBIOS domain name ?!

DNS setup

When transferring a PC to a new domain (and when synchronizing passwords), you will need to ensure that the names in both domains are correctly resolved on any computer in your infrastructure. It makes sense to configure Conditional Forwarding on DNS servers serving both domains.

Recreating security objects in a new domain.

Import Time

It's good to have a domain dump sorted by RID.
The choice of means for importing the dump is yours. I initially sketched the script in VBScript, but in the end I had to rewrite everything in C # - otherwise it turned out very slowly (before hour X, I conducted a test migration more than once to identify potential problems). I imported all the data in about half a day (this is with some tricks - more on that later).
When the domain is old and when the domain is large, there is a high probability of fragmentation of the RID pool (there may be large omissions in your domain dump sorted by RID: users / groups / computers were started and then deleted) - the logical solution is:
Create a user, get his RID, delete the user. If RID-1 is equal to the RID of the next user from the dump, start the user from the dump, otherwise repeat the RID “cheat” cycle.
The decision is logical, but very catastrophically slow.
The default RID pool size is 500. There is a nice invalidateRidPool mechanism that forces the server to request a new pool from RID Master.
Using invalidateRidPool allowed us to significantly reduce the time to “scroll” the RID, and also eased the following problem.

Cleaning the garbage

Unfortunately, after “wrapping” the RID in Active Directory, there remains a lot of tombstone because of them ntds.dit takes on enormous size and its replication to remote sites starts to look like a headache. How to get rid of them and facilitate ntds.dit? Only in a natural way.
tombstoneLifetimesets the lifetime of the remote object in Active Directory (not to be confused with objects in the Recycle Bin - these are different things) the minimum value that can be set is 2 days (the default value is 180 days), i.e. deleted objects older than two days will be deleted from the database. If you set tombstoneLifetime = 2 and wait two days ... only the first 5000 tombstones will be deleted. Tombstones are removed as a result of the Garbage Collection procedure. This procedure starts independently once every 12 hours and deletes no more than 5000 objects at a time. To clear a larger number of tombstones, you will need to run the Garbage Collection several times: by reducing the launch interval , or by calling the procedure forcibly.
After that, be sure return the value tombstoneLifetime and do offline defragmentation ntds.dit

Synchronize user passwords from the old domain to the new one.

There are several “how to do this” options:

• In Samba, you can set your own password complexity test script . Unfortunately, the user’s login is not passed to the script, but it’s easy to fix (this is Open Source!)
• Samba stores NT and LM (for passwords shorter than 14 characters) password hashes - if the situation allows , you have the opportunity to find out the passwords of your users.
• You can set a default password for users and set the checkbox "require password change at next login" (I highly recommend not doing this)
• You can bypass all users

In general, you choose. I prefer the first option.

Actually migration.

All the previous steps did not affect the operation of the domain. It was only preparation that can be carried out for months without interfering with the work of the business. The remaining two stages will have to be done in a period of inactivity agreed with the business. With appropriate preparation and the availability of the required number of hands, it’s easy to actually reduce it to a few nights (depending on the size of the domain, it can be up to several hours).
Here it is important to know which services and which users are critical and which can wait that are easy to use - in general, you need to know your company's business processes.
Check again the settings of the new domain: IP subnets, sites, policies, setting up time synchronization from an external source on your PDC emulator.
Check that the DNS names of both domains are correctly deployed from your workstations.

Transfer to a new domain of workstations and servers

If OC is on XP / 2003 domain members and above - there will be no particular problems - they can be easily transferred immediately to a new domain using JoinDomainOrWorkgroup
For the 2000s, you will have to do an intermediate reboot (remove from the domain-reload-enter into the domain)
Here you can use any the centralized management system available to you, or write your own scripts (they will turn out quite simple). Do not forget that to transfer a PC from a domain to a domain, you will need an account with the appropriate privileges both in the domain and on the PCs themselves.
Yes, do not forget to change the DNS addresses to new ones in the DHCP server setup (you intend to use the AD-integrated zones of MS DNS, right?) The DHCP server itself can not be migrated right away (you will lose a lot of functionality) - it can be painless replace with a product from Microsoft later.

Change of configuration on services using a domain.

You prepared new configuration files (instructions for migration), tested new settings on the layout - so there should be no problems.

Total.

After spending a lot of time preparing, about 3-4 days to import security objects, you can transfer a company from Samba to Active Directory in 1 - several nights.

If you have another vision / experience of such migration - please share it - it is very interesting to analyze your actions, to find out what could be done better.
Naturally, I touched on only general problems and peculiarities - there are no two identical companies and everywhere there will be their own unique snag.