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

In a recently published article, TerAnYu described how he migrated a domain from Samba to Active Directory. The method was chosen, in my opinion, very interesting, but, unfortunately, during the migration of a small domain (the author mentions in the text of the article about 70 office users) many interesting problems remained “behind the scenes”.
I, in turn, will try to abstract from the user dump / restore scripts and concentrate on the description of the problems encountered and their solutions. Perhaps the described experience will help someone to reduce labor costs for the preparation of migration.

And, of course, I was a goof - it would be simple, but the most minimal.


')

Why abandoned Samba

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

Concept

I will describe briefly the concept of migration:

1. A list of ALL services using the domain is made (for authorization or as a repository of other information)
2. New configuration sets are being prepared for these services to work with Active Directory.
3. Samba source domain data is stored in a dump.
4. The first controller of the new domain is being prepared on the Windows 2003 server (after migration, you can migrate the domain to the controllers from the newer OS without problems, but the next step will work only on the 2003rd server). The new server with the newsid utility installs the SID of the domain on Samba (if you increase the role, this SID will become the SID of the Active Directory domain)
5. DNS is configured.
6. Security objects are created in the created domain (users / groups / computers) in ascending order of their RID. In a domain with a single DC, the RIDs are assigned strictly in order (I have not had a single case that proves the opposite with a large number of import test runs)
7. Synchronization of user passwords from the old domain to the new one.
8. Workstations and servers are transferred to the new domain.
9. On services using a domain, the configuration changes to a previously prepared and tested.

Now consider each stage in order.

The list of services using the domain.

This list should be all dependencies whether you are going to migrate somewhere or not. It is always important to know who uses your domain and how . 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 a 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 required and they should be prepared in advance (we do not want the business to stand idle!).
What will change? It is logical that after the move you will still have a large number of linux systems that are needed
will integrate into a new domain (perhaps 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, verifying its hash with that stored in LDAP — they will no longer receive any hash from LDAP. We'll have to redo everything (I mean services that won't work with kerberos) to check for a password using an LDAP bind. I highly recommend wherever possible to use kerberos for authorization - this will make life easier for users and reduce the burden on your domain controllers.
2. Now there may be nested groups in your domain, so when checking the user's membership in a group, you will have to consider the possibility of nested groups.
3. It makes sense to translate your services to use kerberos (if this has not been done before).
4. For the data stored in LDAP, you will have to search for other attributes, or to expand the Active Directory schema (I strongly recommend not using the first attribute with the appropriate format — try to think about what your decision may turn out in the future). The benefit of assigning attributes to Active Directory is well documented - do not be 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 the administrator’s error and this error must be corrected immediately! The presence of several security objects with the same SID is unacceptable (but, unfortunately, in the Samba domains I have repeatedly encountered this phenomenon)
In a typical (according to the manual from the Internet) installation, samba RIDs start issuing from 1000. Unfortunately, using the method described above, you cannot migrate security objects with a RID of less than about 1034 (I repent - I forgot the exact number, but it’s easy to figure out domain and see the last RID). When creating an Active Directory domain, a number of security service objects are created and they “occupy” these very first RIDs.
In these two cases, the solution is one:
You after all preempted and analyzed a domain dump on Samba? Is X far yet? So there is time to slowly figure out all conflict situations and fix them with minimal downtime for business.

The first controller of the new domain is being prepared.

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

DNS setup

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

Recreation of security objects in the new domain.

Import time

It's good to have a domain dump sorted by RID.
The choice of means to import the dump is yours. I originally sketched a script for VBScript, but in the end I had to rewrite everything to C # - otherwise it worked out very slowly (before X hour I did a test migration more than once to identify potential problems). Import of all the data took place in about half a day from me (this is with some tricks - about them further).
When the domain is old and when the domain is large there is a high probability of fragmentation of the RID pool (in your domain dump sorted by RID there may be large gaps: users / groups / computers were started and then deleted) - a logical solution:
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 cycle of the RID.
The solution is logical, but very catastrophically slow.
The default RID pool size is 500. There is a good invalidateRidPool mechanism that causes the server to request a new pool from RID Master.
Using invalidateRidPool allowed us to significantly reduce the time to “scroll” RID, and also eased the following problem.

Scavenging

Unfortunately, after the RID is “cheated” in Active Directory, a lot of tombstone remains because of them, ntds.dit becomes enormous and its replication to remote sites begins to look like a headache. How to get rid of them and facilitate ntds.dit? Only naturally.
tombstoneLifetime sets the lifetime of a remote object in Active Directory (not to be confused with objects in Recycle Bin 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 removed. Tombstones are removed as a result of the Garbage Collection procedure. This procedure starts on its own every 12 hours and removes no more than 5000 objects at a time. To clear more tombstones, you need to run the Garbage Collection several times: either by reducing the launch interval or by invoking the procedure.
After that, be sure to return the tombstoneLifetime value and offline defragment ntds.dit

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

There are several options for "how to do it":

• In Samba, it is possible to set your password complexity checker script . Unfortunately, the user's login is not transferred to the script, but it is easy to fix (this is an Open Source!)
• Samba stores NT and LM (for passwords shorter than 14 characters) password hashes - if the situation permits - 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 changing password on next login” (I highly recommend not to do this)
• You can bypass all users

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

Actually migration.

All previous steps had no effect on the work of the domain. It was just a 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 downtime interval agreed with the business. With proper preparation and the availability of the required number of hands, idle time can actually be reduced to several nights (depending on the size of the domain, it can be up to several hours).
Here it is important to know which services are easy to work and which users are critical, and which ones can wait - in general, you need to know the business processes of your company.
Check again the settings of the new domain: IP subnets, sites, policies, setting up time synchronization with 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 on members of the XP / 2003 domain and above - there will not be any special problems - they are easily transferred immediately to the 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 centralized management system available to you, or write your own scripts (they are pretty simple). Do not forget that to transfer PCs from domain to domain you will need an account with corresponding privileges both in the domain and on the PCs themselves.
Yes, do not forget to change the DNS server addresses to new ones in the DHCP server setup (you are going to use the AD-integrated MS DNS zones, right?) The DHCP server itself can be not migrated at once (you will lose not much functionality) - it can be painless replace with a product from Microsoft later.

Configuration change on services using a domain.

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

Total.

Having spent a lot of time preparing, about 3-4 days to import security objects you can transfer a company from Samba to Active Directory for 1 - a few nights.

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