Section 9.5. Migrating an NT 4.0 Domain to Samba

9.5. Migrating an NT 4.0 Domain to Samba

Earlier, we stated that Samba 3.0 does not support the Windows NT 4.0 SAM replication protocol. This is true in the sense that you cannot configure Samba to receive incremental change sets from a Windows PDC (or vice versa). However, developers have implemented enough of the protocol to allow what is referred to as SAM synchronization. Windows servers do this when a BDC is first brought online. It synchronizes its local SAM with the domain SAM by requesting the complete set of users and groups from the PDC. By requesting this initial synchronization operation with a Windows NT 4.0 PDC, Samba can obtain a complete list of users and groups along with passwords and account details, thus providing a means of migrating from the Windows domain controller to a Samba-based domain.

The basic steps for migrating an NT 4.0 domain from Windows to Samba are:

1. Ensure that all Samba daemons are stopped.

2. Configure the Samba host's smb.conf as a BDC for the domain, including the user management family of scripts.

3. Synchronize the Samba's machine SID stored in secrets.tdb with the domain SID.

4. Create a BDC account on the Windows PDC for the Samba server.

5. Join the domain.

6. Issue the SAM synchronization request.

7. Reconfigure Samba as a PDC.

8. Shut down the Windows PDC.

9. Start smbd and nmbd on the Samba server.

Most of effort necessary for migrating a domain is in generating a working set of user management scripts. These are required so that Samba can generate the new Unix users and groups before creating the user accounts or group mapping entries in its passdb. However, one major hurdle is that many Unix account utilities restrict the format of a new user or group name. For example, the Linux groupadd command fails if the group name contains whitespace:

 # groupadd "Domain Admins" groupadd: Invalid group name 'Domain Admins'. 

One workaround is to bypass the OS tools and manually create the Unix groups. On Linux at least, the rejection of white space in group names is a tool issue, not a limitation of /etc/group or the libnss_files.so.2 library. The following excerpt from /etc/group illustrates these group names:

 Domain Admins:!:1000: Domain Users:!:1001: Domain Guests:!:1002: Account Operators:!:1003: Server Operators:!:1004: Backup Operators:!:1005: Print Operators:!:1006: 

If you have a large number of groups, however, such manual creation may be too tedious. In this case, customize the user management scripts called by Samba to accept valid Windows user and group names.

The next question is which passdb backend to use. Our recommendation is to begin with tdbsam. The reasons are simple. tdbsam is easier to configure than an LDAP backend and more robust than an smbpasswd file. Additionally, it is easier to remove tdb files than to rebuild an LDAP DIT when performing migration experiments. You can always convert Samba's users and groups from a tdb backend to an LDAP directory service later using the following command:

 # pdbedit -i tdbsam -e ldapsam:ldap://ldap.example.com/ 

With these recommendations in mind, let's begin the example by defining the following smb.conf for our soon-to-be Samba PDC. All the parameters should be familiar at this point. The Windows NT domain that we are migrating is named DOA. Remember to disable the domain master option when configuring a backup domain controller. The [netlogon] share is not required for the migration process, but will be necessary once we swap the Samba server to a PDC. Finally, we have omitted any support for roaming user profiles, because this feature is independent of transferring accounts. We will, however, revisit some specific issues surrounding the user environment profile after completing the migration.

 [global]     netbios name = CAT     workgroup = DOA     security = user     encrypt passwords = yes     passdb backend = tdbsam     domain logons = yes     domain master = no     add user script = /usr/sbin/useradd -m '%u'     delete user script = /usr/sbin/userdel '%u'     rename user script = /usr/sbin/usermod -l '%unew' '%uold'     add group script = /usr/sbin/groupadd '%g'     delete group script = /usr/sbin/groupdel '%g'     add user to group script = /usr/sbin/groupmod -A '%u' '%g'     delete user from group script = /usr/sbin/groupmod -D '%u' '%g'     set primary group script = /usr/sbin/usermod -g '%g' '%u' [netlogon]     path = /data/netlogon     read only = yes     write list = +"Domain Admins" 

After the initial smb.conf has been created, the next step is to synchronize Samba's machine SID with the domain SID. This is done by running the net rpc getsid command against the Windows PDC. Because you are writing directly to secrets.tdb, these commands must be run as root. In the example, medic is the name of the PDC for the DOA domain.

 # net rpc getsid -S medic Storing SID S-1-5-21-406022937-1377575209-526660263 for Domain DOA in secrets.tdb 

Samba's machine SID must be manually set to match this domain SID using net setlocalsid. If the command succeeds, you are immediately returned to a shell prompt with no additional output.

 # net setlocalsid S-1-5-21-406022937-1377575209-526660263 

The next two steps, creating the BDC account and joining the domain, should be executed in immediate succession in order to prevent an attacker from hijacking the machine account. Ideally, this should be done on a separate, secure network, but that is not always possible when migrating a production domain. When experimenting, consider moving a Windows BDC to an isolated network and promoting it to a PDC.

Figure 9-11 shows the Server Manager (srvmgr.exe) application and the Add Computer to Domain dialog boxes. Use these to create a BDC account for the Samba host.

Figure 9-11. Using Server Manager to create a BDC account for the Samba host CAT

Next, join the domain using net rpc join. We'll provide much more detail about joining Windows (and Samba) domains in the next chapter. For now, this one command is enough to get the job done:

 # net rpc join Joined domain DOA. 

You are finally ready to migrate the users and groups from the DOA domain into Samba's passdb. Assume that all group names containing whitespace have been previously created in /etc/group by hand. Begin the migration process by running net rpc vampire. The -S option is used to define the name of the Windows NT 4.0 PDC to contact. After the migration completes, it is a good idea to verify the new users and groups both in the server's Unix accounts and in Samba's passdb.

 # net rpc vampire -S medic Fetching DOMAIN database Creating unix group: 'testgroup' Creating unix group: 'testgroup2' Creating account: Administrator Creating account: Guest Creating account: foo Creating account: foo2 Creating account: foo3 Creating account: user1 Creating account: NURSE$ Creating account: CAT$ Group members of Domain Admins: Administrator, Group members of Domain Users: Administrator(primary),foo2(primary),   user1(primary),foo3(primary),NURSE$(primary),CAT$(primary), Group members of Domain Guests: nobody, Group members of testgroup: foo(primary), Group members of testgroup2: foo, Creating unix group: 'LocalTestGrp' Fetching BUILTIN database skipping SAM_DOMAIN_INFO delta for 'Builtin' (is not my domain) Creating unix group: 'Administrators' Creating unix group: 'Guests' Creating unix group: 'Replicator' Creating unix group: 'Users' 

The final steps are to shut down the Windows PDC and launch the new Samba PDC. Before starting smbd and nmbd, make sure to enable the domain master parameter so that Samba registers the DOA<0x1b> name and the Windows client recognizes the new PDC.

Here are a few pieces of advice. Migrating a domain is tricky business. You should expect to run through several test migrations before disabling the Windows PDC. Also consider any additional services such as file and printer shares, web servers, or other applications offered by the Windows PDC. These must be migrated individually. The good news is that you have to successfully complete the migration process only once.