<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 8. Migrating NT4 Domain to Samba-3</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.64.1"><link rel="home" href="index.html" title="Samba-3 by Example"><link rel="up" href="index.html" title="Samba-3 by Example"><link rel="previous" href="2000users.html" title="Chapter 7. A Distributed 2000 User Network"><link rel="next" href="unixclients.html" title="Chapter 9. Adding UNIX/LINUX Servers and Clients"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 8. Migrating NT4 Domain to Samba-3</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="2000users.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="unixclients.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="migration"></a>Chapter 8. Migrating NT4 Domain to Samba-3</h2></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="migration.html#id2549168">Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="migration.html#id2549263">Assignment Tasks</a></span></dt></dl></dd><dt><span class="sect1"><a href="migration.html#id2549322">Dissection and Discussion</a></span></dt><dd><dl><dt><span class="sect2"><a href="migration.html#id2549514">Technical Issues</a></span></dt><dt><span class="sect2"><a href="migration.html#id2549916">Political Issues</a></span></dt></dl></dd><dt><span class="sect1"><a href="migration.html#id2549942">Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="migration.html#id2549968">NT4 Migration Using LDAP Backend</a></span></dt><dt><span class="sect2"><a href="migration.html#id2550682">NT4 Migration Using tdbsam Backend</a></span></dt><dt><span class="sect2"><a href="migration.html#id2551066">Key Points Learned</a></span></dt></dl></dd><dt><span class="sect1"><a href="migration.html#id2551104">Questions and Answers</a></span></dt></dl></div><p> Ever since Microsoft announced that they are discontinuing support for Windows NT4, Samba users started to ask for detailed instructions for how to migrate from NT4 to Samba-3. This chapter provides background information that should meet these needs. </p><p> One wonders how many NT4 systems will be left in service by the time you read this book though. </p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2549168"></a>Introduction</h2></div></div><div></div></div><p><a class="indexterm" name="id2549175"></a> Network administrators who want to migrate off a Windows NT4 environment know one thing with certainty. They feel that NT4 has been abandoned and they want to update. The desire to get off NT4 and to not adopt Windows 200x and Active Directory is driven by a mixture of concerns over complexity, cost, fear of failure, and much more. </p><p><a class="indexterm" name="id2549192"></a><a class="indexterm" name="id2549200"></a><a class="indexterm" name="id2549211"></a><a class="indexterm" name="id2549222"></a> The migration from NT4 to Samba-3 can involve a number of factors, including: migration of data to another server, migration of network environment controls such as group policies, and finally migration of the users, groups, and machine accounts. </p><p><a class="indexterm" name="id2549241"></a> It should be pointed out now that it is possible to migrate some systems from Windows NT4 Domain environments to a Samba-3 Domain Environment. This is certainly not possible in every case. It is possible to just migrate the Domain accounts to Samba-3 and then to switch machines, but as a hands-off transition, this is more an exception than the rule. Most systems require some tweaking and adjusting following migration before an environment that is acceptable for immediate use is obtained. </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2549263"></a>Assignment Tasks</h3></div></div><div></div></div><p><a class="indexterm" name="id2549270"></a><a class="indexterm" name="id2549278"></a><a class="indexterm" name="id2549286"></a> You are about to migrate an MS Windows NT4 Domain accounts database to a Samba-3 server. The Samba-3 server is using a <i class="parameter"><tt>passdb backend</tt></i> based on LDAP. The <tt class="constant">ldapsam</tt> is ideal because an LDAP backend can be distributed for use with BDCs generally essential for larger networks. </p><p> Your objective is to document the process of migrating user and group accounts from several NT4 Domains into a single Samba-3 LDAP backend database. </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2549322"></a>Dissection and Discussion</h2></div></div><div></div></div><p><a class="indexterm" name="id2549328"></a><a class="indexterm" name="id2549336"></a><a class="indexterm" name="id2549344"></a><a class="indexterm" name="id2549358"></a><a class="indexterm" name="id2549373"></a><a class="indexterm" name="id2549381"></a> The migration process takes a snap-shot of information that is stored in the Windows NT4 registry based accounts database. That information resides in the Security Account Manager (SAM) portion of the NT4 Registry under keys called <tt class="constant">SAM</tt> and <tt class="constant">SECURITY</tt>. </p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p><a class="indexterm" name="id2549408"></a><a class="indexterm" name="id2549415"></a> The Windows NT4 registry keys called <tt class="constant">SAM</tt> and <tt class="constant">SECURITY</tt> are protected so that you cannot view the contents. If you change the security setting to reveal the contents under these hive keys, your Windows NT4 Domain is crippled. Do not do this unless you are willing to render your domain controller inoperative. </p></div><p><a class="indexterm" name="id2549439"></a><a class="indexterm" name="id2549450"></a> Before commencing an NT4 to Samba-3 migration, you should consider what your objectives are. While in some cases it is possible simply to migrate an NT4 domain to a single Samba-3 server, that may not be a good idea from an administration perspective. Since you are going through a certain amount of disruptive activity anyhow, why not take this as an opportunity to review the structure of the network, how Windows clients are controlled and how they interact with the network environment. </p><p><a class="indexterm" name="id2549469"></a><a class="indexterm" name="id2549481"></a><a class="indexterm" name="id2549489"></a> MS Windows NT4 was introduced some time around 1996. Many environments in which NT4 was deployed have done little to keep the NT4 server environment up-to-date with more recent Windows releases, particularly Windows XP Professional. The migration provides opportunity to revise and update roaming profile deployment as well as folder redirection. Given that you must port the greater network configuration of this from the old NT4 server to the new Samba-3 server, you also must validate the security descriptors in the profiles share as well as network logon scripts. Feedback from sites that are migrating to Samba-3 suggests that many are using this as a good time to update desktop systems also. In all, the extra effort should constitute no real disruption to users, rather with due diligence and care should make their network experience a much happier one. </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2549514"></a>Technical Issues</h3></div></div><div></div></div><p><a class="indexterm" name="id2549521"></a> Migration of an NT4 Domain user and group database to Samba-3 involves a certain strategic element. Many sites have asked for instructions regarding merging of multiple different NT4 Domains into one Samba-3 LDAP database. It would appear that this is viewed as a significant added value compared with the alternative of migration to Windows Server 200x and Active Directory. The diagram in <a href="migration.html#ch8-migration" title="Figure 8.1. Schematic Explaining the net rpc vampire Process">???</a> illustrates the effect of migration from a Windows NT4 Domain to a Samba Domain. </p><div class="figure"><a name="ch8-migration"></a><p class="title"><b>Figure 8.1. Schematic Explaining the net rpc vampire Process</b></p><div class="mediaobject"><img src="images/ch8-migration.png" width="297" alt="Schematic Explaining the net rpc vampire Process"></div></div><p> In any case, the migration process involves the following steps: </p><div class="itemizedlist"><ul type="disc"><li><p> Prepare the target Samba-3 server. This involves configuring Samba-3 for migration to either a tdbsam or an ldapsam backend. </p></li><li><p><a class="indexterm" name="id2549606"></a><a class="indexterm" name="id2549613"></a><a class="indexterm" name="id2549621"></a> Clean up the source NT4 PDC. Delete all accounts that need not be migrated. Delete all files that should not be migrated. Where possible, change NT Group names so there are no spaces or uppercase characters. This is important if the target UNIX host insists on Posix compliant all lower-case user and group names. </p></li><li><p> Step through the migration process. </p></li><li><p><a class="indexterm" name="id2549644"></a> Remove the NT4 PDC from the network. </p></li><li><p> Upgrade the Samba-3 server from a BDC to a PDC, and validate all account information. </p></li></ul></div><p><a class="indexterm" name="id2549663"></a><a class="indexterm" name="id2549671"></a> If you are wanting to merge multiple NT4 Domain account databases into one Samba Domain, you must now dump the contents of the first migration and edit it as appropriate. Now clean out (remove) the tdbsam backend file (<tt class="filename">passdb.tdb</tt>), or the LDAP database files. You must start each migration with a new database into which you merge your NT4 domains. </p><p><a class="indexterm" name="id2549694"></a> At this point, you are ready to perform the second migration following the same steps as for the first. In other words, dump the database, edit it, and then you may merge the dump for the first and second migrations. </p><p><a class="indexterm" name="id2549709"></a><a class="indexterm" name="id2549717"></a><a class="indexterm" name="id2549724"></a> You must be careful. If you choose to migrate to an LDAP backend, your dump file now contains the full account information, including the Domain SID. The Domain SID for each of the two NT4 Domains will be different. You must choose one, and change the Domain portion of the account SIDs so that all are the same. </p><p><a class="indexterm" name="id2549741"></a><a class="indexterm" name="id2549749"></a><a class="indexterm" name="id2549757"></a><a class="indexterm" name="id2549765"></a><a class="indexterm" name="id2549772"></a><a class="indexterm" name="id2549780"></a><a class="indexterm" name="id2549788"></a><a class="indexterm" name="id2549796"></a><a class="indexterm" name="id2549804"></a><a class="indexterm" name="id2549812"></a><a class="indexterm" name="id2549820"></a><a class="indexterm" name="id2549828"></a> If you choose to use a tdbsam (<tt class="filename">passdb.tdb</tt>) backend file, your best choice is to use <span><b class="command">pdbedit</b></span> to export the contents of the tdbsam file into an smbpasswd data file. This automatically strips out all Domain specific information, such as logon hours, logon machines, logon script, profile path, as well as the Domain SID. The resulting file can be easily merged with other migration attempts (each of which must start with a clean file). It should also be noted that all users that end up in the merged smbpasswd file must have an account in <tt class="filename">/etc/passwd</tt>. The resulting smbpasswd file may be exported/imported into either a tdbsam (<tt class="filename">passdb.tdb</tt>), or else into an LDAP backend. </p><div class="figure"><a name="NT4DUM"></a><p class="title"><b>Figure 8.2. View of Accounts in NT4 Domain User Manager</b></p><div class="mediaobject"><img src="images/UserMgrNT4.png" width="270" alt="View of Accounts in NT4 Domain User Manager"></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2549916"></a>Political Issues</h3></div></div><div></div></div><p> The merging of multiple Windows NT4 style Domains into a single LDAP-backend-based Samba-3 Domain may be seen by those who had power over them as a loss of prestige or a loss of power. The imposition of a single Domain may even be seen as a threat. So in migrating and merging account databases, be consciously aware of the political fall-out in which you may find yourself entangled when key staff feel a loss of prestige. </p><p> The best advice that can be given to those who set out to merge NT4 Domains into one single Samba-3 Domain is to promote (sell) the action as one that reduces costs and delivers greater network interoperability and manageability. </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2549942"></a>Implementation</h2></div></div><div></div></div><p> You can present here the steps and example output for two NT4 to Samba-3 Domain migrations. The first uses an LDAP-based backend, and the second uses a tdbsam backend. In each case the scripts you specify in the <tt class="filename">smb.conf</tt> file for the <i class="parameter"><tt>add user script</tt></i> collection of parameters are used to effect the addition of accounts into the passdb backend. </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2549968"></a>NT4 Migration Using LDAP Backend</h3></div></div><div></div></div><p> In this instance, you migrate an NT4 PDC to an LDAP backend. The accounts you are about to migrate are shown in <a href="migration.html#NT4DUM" title="Figure 8.2. View of Accounts in NT4 Domain User Manager">???</a>. In this example you make use of the smbldap-tools scripts to add the accounts that are migrated into the ldapsam passdb backend. Four scripts are essential to the migration process. There are other scripts that will be required for daily management, but these are not critical to migration. The critical scripts are dependant on which passdb backend is being used. Refer to <a href="migration.html#ch8-vampire" title="Table 8.1. Samba smb.conf Scripts Essential to Migration">???</a> to see which scripts must be provided so that the migration process can complete. </p><p> Do verify that you have correctly specified in the <tt class="filename">smb.conf</tt> file the scripts, and arguments that should be passed to them, before attempting to perform the account migration. </p><div class="table"><a name="ch8-vampire"></a><p class="title"><b>Table 8.1. Samba <tt class="filename">smb.conf</tt> Scripts Essential to Migration</b></p><table summary="Samba smb.conf Scripts Essential to Migration" border="1"><colgroup><col align="left"><col align="center"><col align="center"></colgroup><thead><tr><th align="left">Entity</th><th align="center">ldapsam Script</th><th align="center">tdbsam Script</th></tr></thead><tbody><tr><td align="left">Add User Accounts</td><td align="center">smbldap-useradd.pl</td><td align="center">useradd</td></tr><tr><td align="left">Delete User Accounts</td><td align="center">smbldap-userdel.pl</td><td align="center">userdel</td></tr><tr><td align="left">Add Group Accounts</td><td align="center">smbldap-groupadd.pl</td><td align="center">groupadd</td></tr><tr><td align="left">Delete Group Accounts</td><td align="center">smbldap-groupdel.pl</td><td align="center">groupdel</td></tr><tr><td align="left">Add User to Group</td><td align="center">smbldap-groupmod.pl</td><td align="center">usermod (See Note)</td></tr><tr><td align="left">Add Machine Accounts</td><td align="center">smbldap-useradd.pl</td><td align="center">useradd</td></tr></tbody></table></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> The UNIX/Linux <span><b class="command">usermod</b></span> utility does not permit simple user addition to (or deletion of users from) groups. This is a feature provided by the smbldap-tools scripts. If you want this capability you will need to create your own tool to do this. Alternately, you can search the web to locate a utility called <span><b class="command">groupmem</b></span> (by George Kraft) that provides this functionality. The <span><b class="command">groupmem</b></span> utility was contributed to the shadow package but has not surfaced in the formal commands provided by Linux distributions (March 2004). </p></div><p> Before starting the migration, all dead accounts were removed using the User Manager for Domains. </p><div class="procedure"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> The <span><b class="command">tdbdump</b></span> utility is a utility that you can build from the Samba source code tree. Not all Linux binary distributions include this tool. If it is missing from your Linux distribution you will need to build this yourself, or else for-go its use. </p></div><ol type="1"><li><p> Install and configure the Samba-3 server precisely as shown in Chapter 6 for the server called <tt class="constant">MASSIVE</tt>. The Domain name <tt class="constant">MEGANET</tt> must match that of the NT4 Domain from which you are about to migrate. Do not execute any Samba executables. </p></li><li><p><a class="indexterm" name="id2550217"></a><a class="indexterm" name="id2550225"></a> Edit the <tt class="filename">smb.conf</tt> file to temporarily change the parameter <a class="indexterm" name="id2550241"></a>domain master = No so the Samba server functions as a BDC for the purpose of migration. </p></li><li><p><a class="indexterm" name="id2550255"></a> Create a file called <tt class="filename">preload.LDIF</tt> as shown in <a href="migration.html#ch8-LDIF" title="Example 8.1. LDAP Preload LDIF file preload.LDIF">???</a>. </p></li><li><p><a class="indexterm" name="id2550283"></a> Preload the LDAP database so it is ready to receive the information from the NT4 PDC. This pre-loads the LDAP directory with the top-level information, as well as the top level containers for user, group, computer, and domain account data. Execute the instruction shown here: </p><pre class="screen"> <tt class="prompt">root# </tt> slapadd -v -l preload.LDIF added: "dc=abmas,dc=biz" (00000001) added: "cn=Manager,dc=abmas,dc=biz" (00000002) added: "ou=People,dc=abmas,dc=biz" (00000003) added: "ou=Computers,dc=abmas,dc=biz" (00000004) added: "ou=Groups,dc=abmas,dc=biz" (00000005) added: "ou=Idmap,dc=abmas,dc=biz" (00000006) added: "ou=Domains,dc=abmas,dc=biz" (00000007) </pre><p> </p></li><li><p> Start the LDAP server. </p></li><li><p><a class="indexterm" name="id2550327"></a> Verify that the NT4 PDC can be reached: </p><pre class="screen"> <tt class="prompt">root# </tt> ping nt4s PING nt4s.abmas.biz (192.168.2.250) 56(84) bytes of data. 64 bytes from NT4S (192.168.2.250): icmp_seq=1 ttl=128 time=10.2 ms 64 bytes from NT4S (192.168.2.250): icmp_seq=2 ttl=128 time=0.518 ms 64 bytes from NT4S (192.168.2.250): icmp_seq=3 ttl=128 time=0.578 ms --- nt4s.abmas.biz ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 0.518/3.773/10.223/4.560 ms </pre><p> It can. Great. </p></li><li><p><a class="indexterm" name="id2550362"></a> Validate that the resources on the NT4 PDC can be listed: </p><pre class="screen"> <tt class="prompt">root# </tt> smbclient -L nt4s -UAdministrator%not24get Sharename Type Comment --------- ---- ------- NETLOGON Disk Logon server share IPC$ IPC Remote IPC UserProfiles Disk All Network User Profiles Server Comment --------- ------- NT4S Workgroup Master --------- ------- MEGANET NT4S </pre><p> This looks good. </p></li><li><p><a class="indexterm" name="id2550397"></a><a class="indexterm" name="id2550405"></a> At this point, it is necessary to fetch the Domain SID from the NT4 PDC and apply that to the Samba-3 BDC (soon to be PDC): </p><pre class="screen"> <tt class="prompt">root# </tt> net rpc getsid -S NT4S -W MEGANET Storing SID S-1-5-21-1988699175-926296742-1295600288 for Domain MEGANET in secrets.tdb </pre><p> Done. </p></li><li><p><a class="indexterm" name="id2550442"></a><a class="indexterm" name="id2550450"></a><a class="indexterm" name="id2550458"></a> At this point, you can validate that the information is correct in the <tt class="filename">secrets.tdb</tt> file, as shown here: </p><pre class="screen"> <tt class="prompt">root# </tt> tdbdump /etc/samba/secrets.tdb { key = "SECRETS/SID/MASSIVE" data = "\01\04\00\00\00\00\00\05\15\00\00\00'$\89v\A6*67\A0J9M\ 00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\ 00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00" } { key = "SECRETS/LDAP_BIND_PW/cn=Manager,dc=abmas,dc=biz" data = "not24get\00" } </pre><p> This has returned the information expected. </p></li><li><p><a class="indexterm" name="id2550513"></a> We are ready to join the NT4 Domain as a BDC by executing the following: </p><pre class="screen"> <tt class="prompt">root# </tt> net rpc join -S NT4S -W MEGANET -U Administrator%not24get Joined domain MEGANET. </pre><p> Done. </p></li><li><p><a class="indexterm" name="id2550548"></a> The Samba-3 BDC is now ready to receive the NT4 PDC accounts database, as shown here: </p><pre class="screen"> <tt class="prompt">root# </tt> net rpc vampire -S NT4S Fetching DOMAIN database SAM_DELTA_DOMAIN_INFO not handled Creating account: Administrator Creating account: Guest Creating account: NT4S$ Creating account: massive$ Creating account: barryf Creating account: gdaison Creating account: atrikhoffer Creating account: hramsbotham Creating account: fsellerby Creating account: jrhapsody Group members of Domain Admins: Group members of Domain Users: NT4S$(primary),massive$(primary), Group members of Domain Guests: nobody(primary), Group members of rubberboot: Group members of engineers: Group members of accounting: Group members of catalyst: Group members of shipping: Group members of receiving: Group members of marketiod: Group members of sales: Fetching BUILTIN database SAM_DELTA_DOMAIN_INFO not handled </pre><p> </p></li><li><p><a class="indexterm" name="id2550608"></a><a class="indexterm" name="id2550616"></a> Edit the <tt class="filename">smb.conf</tt> file to reset the parameter <a class="indexterm" name="id2550632"></a>domain master = Yes so that the Samba server functions as a PDC for the purpose of migration. </p></li></ol></div><div class="example"><a name="ch8-LDIF"></a><p class="title"><b>Example 8.1. LDAP Preload LDIF file <tt class="filename">preload.LDIF</tt></b></p><pre class="screen"> dn: dc=abmas,dc=biz objectClass: dcObject objectClass: organization dc: abmas o: Abmas Demo description: POSIX and Samba LDAP Identity Database structuralObjectClass: organization dn: cn=Manager,dc=abmas,dc=biz objectClass: organizationalRole cn: Manager description: Directory Manager structuralObjectClass: organizationalRole dn: ou=People,dc=abmas,dc=biz objectClass: top objectClass: organizationalUnit ou: People structuralObjectClass: organizationalUnit dn: ou=Groups,dc=abmas,dc=biz objectClass: top objectClass: organizationalUnit ou: Groups structuralObjectClass: organizationalUnit dn: ou=Idmap,dc=abmas,dc=biz objectClass: top objectClass: organizationalUnit ou: Idmap structuralObjectClass: organizationalUnit dn: ou=Domains,dc=abmas,dc=biz objectClass: organizationalUnit ou: Domains structuralObjectClass: organizationalUnit </pre></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2550682"></a>NT4 Migration Using tdbsam Backend</h3></div></div><div></div></div><p> In this example, you have chosen to change the Domain name of the NT4 server from <tt class="constant">DRUGPREP</tt> to <tt class="constant">MEGANET</tt> prior to the use of the vampire (migration) tool. This migration process makes use of Linux system tools (like <span><b class="command">useradd</b></span>) to add the accounts that are migrated into the UNIX/Linux <tt class="filename">/etc/passwd</tt>, and <tt class="filename">/etc/group</tt> databases. These entries must therefore be present, and correct options specified, in your <tt class="filename">smb.conf</tt> file or else the migration does not work as it should. </p><div class="procedure"><ol type="1"><li><p> Prepare a Samba-3 server precisely per the instructions shown in Chapter 5. Set the workgroup name to <tt class="constant">MEGANET</tt>. </p></li><li><p><a class="indexterm" name="id2550748"></a><a class="indexterm" name="id2550756"></a> Edit the <tt class="filename">smb.conf</tt> file to temporarily change the parameter <a class="indexterm" name="id2550771"></a>domain master = No so the Samba server functions as a BDC for the purpose of migration. </p></li><li><p> Start Samba as you have done previously. </p></li><li><p><a class="indexterm" name="id2550793"></a> Join the NT4 Domain as a BDC, as shown here: </p><pre class="screen"> <tt class="prompt">root# </tt> net rpc join -S oldnt4pdc -W MEGANET -UAdministrator%not24get Joined domain MEGANET. </pre><p> </p></li><li><p><a class="indexterm" name="id2550828"></a> You may vampire the accounts from the NT4 PDC by executing the command, as shown here: </p><pre class="screen"> <tt class="prompt">root# </tt> net rpc vampire -S oldnt4pdc -U Administrator%not24get Fetching DOMAIN database SAM_DELTA_DOMAIN_INFO not handled Creating unix group: 'Domain Admins' Creating unix group: 'Domain Users' Creating unix group: 'Domain Guests' Creating unix group: 'Engineers' Creating unix group: 'Marketoids' Creating account: Administrator Creating account: Guest Creating account: oldnt4pdc$ Creating account: jacko Creating account: maryk Creating account: bridge Creating account: sharpec Creating account: jimbo Creating account: dhenwick Creating account: dork Creating account: blue Creating account: billw Creating account: massive$ Group members of Engineers: Administrator, sharpec(primary),bridge,billw(primary),dhenwick Group members of Marketoids: Administrator,jacko(primary), maryk(primary),jimbo,blue(primary),dork(primary) Creating unix group: 'Gnomes' Fetching BUILTIN database SAM_DELTA_DOMAIN_INFO not handled Creating unix group: 'Account Operators' Creating unix group: 'Administrators' Creating unix group: 'Backup Operators' Creating unix group: 'Guests' Creating unix group: 'Print Operators' Creating unix group: 'Replicator' Creating unix group: 'Server Operators' Creating unix group: 'Users' </pre><p> </p></li><li><p><a class="indexterm" name="id2550903"></a> At this point, we can validate our migration. Let's look at the accounts in the form as they would be seen in a smbpasswd file. This achieves that: </p><pre class="screen"> <tt class="prompt">root# </tt> pdbedit -Lw Administrator:505:84B0D8E14D158FF8417EAF50CFAC29C3: AF6DD3FD4E2EA8BDE1695A3F05EFBF52:[UX ]:LCT-3DF7AA9F: jimbo:512:6E9A2A51F64A1BD5C187B8085FE1D9DF: CDF7E305E639966E489A0CEFB95EE5E0:[UX ]:LCT-3E9362BC: sharpec:511:E4301A7CD8FDD1EC6BBF9BC19CDF8151: 7000255938831D5B948C95C1931534C5:[UX ]:LCT-3E8B42C4: dhenwick:513:DCD8886141E3F892AAD3B435B51404EE: 2DB36465949CB938DD98C312EFDC2639:[UX ]:LCT-3E939F41: bridge:510:3FE6873A43101B46417EAF50CFAC29C3: 891741F481AF111B4CAA09A94016BD01:[UX ]:LCT-3E8B4291: blue:515:256D41D2559BB3D2AAD3B435B51404EE: 9CCADDA4F7D281DD0FAD321478C6F971:[UX ]:LCT-3E939FDC: diamond$:517:6C8E7B64EDCDBC4218B6345447A4454B: 3323AC63C666CFAACB60C13F65D54E9A:[S ]:LCT-00000000: oldnt4pdc$:507:3E39430CDCABB5B09ED320D0448AE568: 95DBAF885854A919C7C7E671060478B9:[S ]:LCT-3DF7AA9F: Guest:506:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:[DUX ]:LCT-3E93A008: billw:516:85380CA7C21B6EBE168C8150662AF11B: 5D7478508293709937E55FB5FBA14C17:[UX ]:LCT-3FED7CA1: dork:514:78C70DDEC35A35B5AAD3B435B51404EE: 0AD886E015AC595EC0AF40E6C9689E1A:[UX ]:LCT-3E939F9A: jacko:508:BC472F3BF9A0A5F63832C92FC614B7D1: 0C6822AAF85E86600A40DC73E40D06D5:[UX ]:LCT-3E8B4242: maryk:509:3636AB7E12EBE79AB79AE2610DD89D4C: CF271B744F7A55AFDA277FF88D80C527:[UX ]:LCT-3E8B4270: </pre><p> </p></li><li><p><a class="indexterm" name="id2550956"></a> An expanded view of a user account entry shows more of what was obtained from the NT4 PDC: </p><pre class="screen"> sleeth:~ # pdbedit -Lv maryk Unix username: maryk NT username: maryk Account Flags: [UX ] User SID: S-1-5-21-5672968813-926296742-3245673225-1003 Primary Group SID: S-1-5-21-5672968813-926296742-3245673225-1007 Full Name: Mary Kathleen Home Directory: \\diamond\maryk HomeDir Drive: X: Logon Script: scripts\logon.bat Profile Path: \\diamond\profiles\maryk Domain: MEGANET Account desc: Peace Maker Workstations: Munged dial: Logon time: 0 Logoff time: Mon, 18 Jan 2038 20:14:07 GMT Kickoff time: Mon, 18 Jan 2038 20:14:07 GMT Password last set: Wed, 02 Apr 2003 13:05:04 GMT Password can change: 0 Password must change: Mon, 18 Jan 2038 20:14:07 GMT </pre><p> </p></li><li><p><a class="indexterm" name="id2550991"></a> And this command lists the long names of the groups that have been imported (vampired) from the NT4 PDC: </p><pre class="screen"> <tt class="prompt">root# </tt> net group -l -Uroot%not24get -Smassive Group name Comment ----------------------------- Engineers Snake Oil Engineers Marketoids Untrustworthy Hype Vendors Gnomes Plain Vanilla Garden Gnomes Replicator Supports file replication in a domain Guests Users granted guest access to the computer/domain Administrators Members can fully administer the computer/domain Users Ordinary users </pre><p> Everything looks well and in order. </p></li><li><p><a class="indexterm" name="id2551031"></a><a class="indexterm" name="id2551039"></a> Edit the <tt class="filename">smb.conf</tt> file to reset the parameter <a class="indexterm" name="id2551054"></a>domain master = Yes so the Samba server functions as a PDC for the purpose of migration. </p></li></ol></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2551066"></a>Key Points Learned</h3></div></div><div></div></div><p> Migration of an NT4 PDC database to a Samba-3 PDC is possible. </p><div class="itemizedlist"><ul type="disc"><li><p> An LDAP backend is a suitable vehicle for NT4 migrations. </p></li><li><p> A tdbsam backend can be used to perform a migration. </p></li><li><p> Multiple NT4 Domains can be merged into a single Samba-3 Domain. </p></li><li><p> The net Samba-3 Domain most likely requires some administration and updating before going live. </p></li></ul></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2551104"></a>Questions and Answers</h2></div></div><div></div></div><p> </p><div class="qandaset"><dl><dt> <a href="migration.html#id2551120">clean database Why must I start each migration with a clean database? </a></dt><dt> <a href="migration.html#id2551160">Domain SID Is it possible to set my Domain SID to anything I like? </a></dt><dt> <a href="migration.html#id2551217">/etc/passwd/etc/grouptdbsampassdb backendaccountsuseraccountsgroupaccountsDomain When using a tdbsam passdb backend, why must I have all Domain user and group accounts in /etc/passwd and /etc/group? </a></dt><dt> <a href="migration.html#id2551392">validateconnectivitymigration Why did you validate connectivity before attempting migration? </a></dt><dt> <a href="migration.html#id2551441"> How would you merge 10 tdbsam-based domains into an LDAP database? </a></dt><dt> <a href="migration.html#id2551563">machine accountsaccountsmachine I want to change my Domain name after I migrate all accounts from an NT4 Domain to a Samba-3 Domain. Does it make any sense to migrate the machine accounts in that case? </a></dt><dt> <a href="migration.html#id2551638">multiple group mappings After merging multiple NT4 Domains into a Samba-3 Domain, I lost all multiple group mappings. Why? </a></dt><dt> <a href="migration.html#id2551703"> How can I reset group membership after loading the account information into the LDAP database? </a></dt><dt> <a href="migration.html#id2551737">group names What are the limits or constraints that apply to group names? </a></dt><dt> <a href="migration.html#id2551831">vampire My Windows NT4 PDC has 323,000 user accounts. How long will it take to migrate them to a Samba-3 LDAP backend system using the vampire process? </a></dt></dl><table border="0" summary="Q and A Set"><col align="left" width="1%"><tbody><tr class="question"><td align="left" valign="top"><a name="id2551120"></a><a name="id2551122"></a><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551126"></a> Why must I start each migration with a clean database? </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551141"></a> This is a recommendation that permits the data from each NT4 Domain to be kept separate until you are ready to merge them. Also, if you do not do this, you may find errors due to users or groups from multiple Domains having the same name, but different SIDs. It is better to permit each migration to complete without undue errors and then to handle the merging of vampired data under proper supervision. </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2551160"></a><a name="id2551162"></a><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551166"></a> Is it possible to set my Domain SID to anything I like? </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551181"></a><a class="indexterm" name="id2551189"></a><a class="indexterm" name="id2551197"></a> Yes, so long as the SID you create has the same structure as an auto-generated SID. The typical SID looks like this: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX, where the XXXXXXXXXX can be any number with from 6 to 10 digits. On the other hand, why would you really want to create your own SID? I cannot think of a good reason. You may want to set the SID to one that is already in use somewhere on your network, but that is a little different from straight out creating your own Domain SID. </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2551217"></a><a name="id2551220"></a><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551223"></a><a class="indexterm" name="id2551231"></a><a class="indexterm" name="id2551238"></a><a class="indexterm" name="id2551246"></a><a class="indexterm" name="id2551254"></a><a class="indexterm" name="id2551266"></a><a class="indexterm" name="id2551277"></a> When using a tdbsam passdb backend, why must I have all Domain user and group accounts in <tt class="filename">/etc/passwd</tt> and <tt class="filename">/etc/group</tt>? </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551308"></a><a class="indexterm" name="id2551316"></a><a class="indexterm" name="id2551324"></a><a class="indexterm" name="id2551332"></a><a class="indexterm" name="id2551339"></a><a class="indexterm" name="id2551347"></a> Samba-3 must be able to tie all user and group account SIDs to a UNIX UID or GID. Samba does not fabricate the UNIX IDs from thin air, but rather requires them to be located in a suitable place. </p><p> When migrating a <tt class="filename">smbpasswd</tt> file to an LDAP backend, the UID of each account is taken together with the account information in the <tt class="filename">/etc/passwd</tt> and both sets of data are used to create the account entrt in the LDAP database. </p><p> If you elect to create the Posix account also, the entire UNIX account is copied to the LDAP backend. The same occurs with NT groups and UNIX groups. At the conclusion of migration to the LDAP database, the accounts may be removed from the UNIX database files. In short then, all UNIX and Windows networking accounts, both in tdbsam as well as in LDAP, require UIDs/GIDs. </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2551392"></a><a name="id2551394"></a><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551397"></a><a class="indexterm" name="id2551405"></a><a class="indexterm" name="id2551413"></a> Why did you validate connectivity before attempting migration? </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p> Access validation before attempting to migrate NT4 Domain accounts helps to pin-point potential problems that may otherwise affect or impede account migration. I am always mindful of the 4P's of migration Planning Prevents Poor Performance. </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2551441"></a><a name="id2551443"></a><b></b></td><td align="left" valign="top"><p> How would you merge 10 tdbsam-based domains into an LDAP database? </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551454"></a><a class="indexterm" name="id2551461"></a><a class="indexterm" name="id2551469"></a><a class="indexterm" name="id2551477"></a><a class="indexterm" name="id2551485"></a><a class="indexterm" name="id2551492"></a><a class="indexterm" name="id2551500"></a><a class="indexterm" name="id2551508"></a><a class="indexterm" name="id2551516"></a><a class="indexterm" name="id2551524"></a><a class="indexterm" name="id2551532"></a> If you have 10 tdbsam Samba Domains, there is considerable risk that there are a number of accounts that have the same UNIX identifier (UID/GID). This means that you almost certainly have to edit a lot of data. It would be easiest to dump each database in smbpasswd file format and then manually edit all records to ensure that each has a unique UID. Each file can then be imported a number of ways. You can use the <span><b class="command">pdbedit</b></span> tool, to affect a transfer from the smbpasswd file to LDAP, or you can migrate them en masse to tdbsam and then to LDAP. The final choice is yours. Just remember to verify all accounts that you have migrated before handing over access to a user. After all, too many users with a bad migration experience may threaten your career. </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2551563"></a><a name="id2551565"></a><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551568"></a><a class="indexterm" name="id2551576"></a> I want to change my Domain name after I migrate all accounts from an NT4 Domain to a Samba-3 Domain. Does it make any sense to migrate the machine accounts in that case? </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551597"></a><a class="indexterm" name="id2551605"></a><a class="indexterm" name="id2551612"></a><a class="indexterm" name="id2551620"></a> I would recommend not. The machine accounts should still work, but there are registry entries on each Windows NT4 and upward client that have a tattoo of the old domain name. If you un-join the domain and then rejoin the newly renamed Samba-3 Domain, you can be certain to avoid this tattooing effect. </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2551638"></a><a name="id2551640"></a><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551643"></a> After merging multiple NT4 Domains into a Samba-3 Domain, I lost all multiple group mappings. Why? </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551660"></a><a class="indexterm" name="id2551667"></a> Samba-3 currently does not implement multiple group membership internally. If you use the Windows NT4 Domain User Manager to manage accounts and you have an LDAP backend, the multiple group membership is stored in the Posix groups area. If you use either tdbsam or smbpasswd backend, then multiple group membership is handled through the UNIX groups file. When you dump the user accounts no group account information is provided. When you edit (change) UIDs and GIDs in each file to which you migrated the NT4 Domain data, do not forget to edit the UNIX <tt class="filename">/etc/passwd</tt> and <tt class="filename">/etc/group</tt> information also. That is where the multiple group information is most closely at your fingertips. </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2551703"></a><a name="id2551705"></a><b></b></td><td align="left" valign="top"><p> How can I reset group membership after loading the account information into the LDAP database? </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551716"></a> You can use the NT4 Domain User Manager that can be downloaded from the Microsoft Web site. The installation file is called <tt class="filename">SRVTOOLS.EXE</tt>. </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2551737"></a><a name="id2551739"></a><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551742"></a> What are the limits or constraints that apply to group names? </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551758"></a><a class="indexterm" name="id2551766"></a><a class="indexterm" name="id2551774"></a><a class="indexterm" name="id2551782"></a><a class="indexterm" name="id2551789"></a><a class="indexterm" name="id2551797"></a> A Windows 200x group name can be up to 254 characters long, while in Windows NT4 the group name is limited to 20 characters. Most UNIX systems limit this to 32 characters. Windows groups can contain upper- and lower-case characters, as well as spaces. Many UNIX system do not permit the use of upper-case characters, and some do not permit the space character either. A number of systems (i.e., Linux) work fine with both upper-case and space characters in group names, but the shadow-utils package that provides the group control functions (<span><b class="command">groupadd, groupmod, groupdel</b></span>, and so on) do not permit them. Also, a number of UNIX systems management tools enforce their own particular interpretation of the Posix standards, and likewise do not permit upper-case or space characters in group or user account names. You have to experiment with your system to find what its peculiarities are. </p></td></tr><tr class="question"><td align="left" valign="top"><a name="id2551831"></a><a name="id2551833"></a><b></b></td><td align="left" valign="top"><p><a class="indexterm" name="id2551836"></a> My Windows NT4 PDC has 323,000 user accounts. How long will it take to migrate them to a Samba-3 LDAP backend system using the vampire process? </p></td></tr><tr class="answer"><td align="left" valign="top"><b></b></td><td align="left" valign="top"><p> UNIX UIDs and GIDs on most UNIX systems use an unsigned short or an unsigned integer. Recent Linux kernels support at least a much larger number. On systems that have a 16-bit constraint on UID/GIDs, you would not be able to migrate 323,000 accounts because this number can not fit into a 16-bit unsigned integer. UNIX/Linux systems that have a 32-bit UID/GID can easily handle this number of accounts. Please check this carefully before you attempt to effect a migration using the vampire process. </p><p><a class="indexterm" name="id2551865"></a> Migration speed depends much on the processor speed, the network speed, disk I/O capability, and LDAP update overheads. On a dual processor AMD MP1600+ with 1 GB memory, that was mirroring LDAP to a second identical system over 1 gigabit ethernet, I was able to migrate around 180 user accounts per minute. Migration would obviously go much faster if LDAP mirroring is turned off during the migration. </p></td></tr></tbody></table></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="2000users.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="index.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="unixclients.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 7. A Distributed 2000 User Network </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 9. Adding UNIX/LINUX Servers and Clients</td></tr></table></div></body></html>