path: root/docs-xml/Samba3-ByExample/SBE-MigrateNT4Samba3.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
<chapter id="ntmigration">
  <title>Migrating NT4 Domain to Samba-3</title>

	<para>
	Ever since Microsoft announced that it was discontinuing support for Windows
	NT4, Samba users started to ask for detailed instructions on how to migrate
	from NT4 to Samba-3. This chapter provides background information that should
	meet these needs.
	</para>

	<para>
	One wonders how many NT4 systems will be left in service by the time you read this
	book though.
	</para>

<sect1>
	<title>Introduction</title>

      <para><indexterm>
	  <primary>migration</primary>
	</indexterm>
	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.
	</para>

	<para>
	<indexterm><primary>group policies</primary></indexterm>
	<indexterm><primary>accounts</primary><secondary>user</secondary></indexterm>
	<indexterm><primary>accounts</primary><secondary>group</secondary></indexterm>
	<indexterm><primary>accounts</primary><secondary>machine</secondary></indexterm>
	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 migration of the users, groups, and machine
	accounts.
	</para>

	<para>
	<indexterm><primary>accounts</primary><secondary>Domain</secondary></indexterm>
	It should be pointed out now that it is possible to migrate some systems from
	a Windows NT4 domain environment 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
	the exception than the rule. Most systems require some tweaking after
	migration before an environment that is acceptable for immediate use
	is obtained.
	</para>

	<sect2>
	<title>Assignment Tasks</title>

	<para>
	<indexterm><primary>LDAP</primary></indexterm>
	<indexterm><primary>ldapsam</primary></indexterm>
	<indexterm><primary>passdb backend</primary></indexterm>
	You are about to migrate an MS Windows NT4 domain accounts database to
	a Samba-3 server. The Samba-3 server is using a 
	<parameter>passdb backend</parameter> based on LDAP. The 
	<constant>ldapsam</constant> is ideal because an LDAP backend can be distributed
	for use with BDCs &smbmdash; generally essential for larger networks.
	</para>

	<para>
	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.
	</para>

	</sect2>
</sect1>

<sect1>
	<title>Dissection and Discussion</title>

	<para>
	<indexterm><primary>snap-shot</primary></indexterm>
	<indexterm><primary>NT4 registry</primary></indexterm>
	<indexterm><primary>registry</primary><secondary>keys</secondary><tertiary>SAM</tertiary></indexterm>
	<indexterm><primary>registry</primary><secondary>keys</secondary><tertiary>SECURITY</tertiary></indexterm>
	<indexterm><primary>SAM</primary></indexterm>
	<indexterm><primary>Security Account Manager</primary><see>SAM</see></indexterm>
	The migration process takes a snapshot 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
	<constant>SAM</constant> and <constant>SECURITY</constant>.
	</para>

	<warning><para>
	<indexterm><primary>crippled</primary></indexterm>
	<indexterm><primary>inoperative</primary></indexterm>
	The Windows NT4 registry keys called <constant>SAM</constant> and <constant>SECURITY</constant>
	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.
	</para></warning>

	<para>
	<indexterm><primary>migration</primary><secondary>objectives</secondary></indexterm>
	<indexterm><primary>disruptive</primary></indexterm>
	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 the process involves going
	through a certain amount of disruptive activity anyhow, why not take this opportunity to
	review the structure of the network, how Windows clients are controlled and how they
	interact with the network environment.
	</para>

	<para>
	<indexterm><primary>network</primary><secondary>logon scripts</secondary></indexterm>
	<indexterm><primary>profiles share</primary></indexterm>
	<indexterm><primary>security descriptors</primary></indexterm>
	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.
	Do not forget to 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, but rather, with due diligence and care, should make their network experience
	a much happier one.
	</para>

	<sect2>
	<title>Technical Issues</title>

	<para>
	<indexterm><primary>strategic</primary></indexterm>
	<indexterm><primary>active directory</primary></indexterm>
	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 NT4
	domains into one Samba-3 LDAP database. It seems 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 <link linkend="ch8-migration"/> illustrates the effect of migration
	from a Windows NT4 domain to a Samba domain.
	</para>

	<figure id="ch8-migration">
		<title>Schematic Explaining the <command>net rpc vampire</command> Process</title>
		<imagefile scale="55">ch8-migration</imagefile>
	</figure>

	<para>
	<indexterm><primary>merge</primary></indexterm>
	<indexterm><primary>passdb.tdb</primary></indexterm>
	If you want 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 (<filename>passdb.tdb</filename>) or the LDAP database
	files. You must start each migration with a new database into which you merge your NT4 
	domains.
	</para>

	<para><indexterm>
	<primary>dump</primary>
	</indexterm>
	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.
	</para>

	<para><indexterm>
	<primary>LDAP</primary>
	</indexterm><indexterm>
	<primary>migrate</primary>
	</indexterm><indexterm>
	<primary>Domain SID</primary>
	</indexterm>
	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.
	</para>

	<para>
	<indexterm><primary>passdb.tdb</primary></indexterm>
	<indexterm><primary>/etc/passwd</primary></indexterm>
	<indexterm><primary>merged</primary></indexterm>
	<indexterm><primary>logon script</primary></indexterm>
	<indexterm><primary>logon hours</primary></indexterm>
	<indexterm><primary>logon machines</primary></indexterm>
	<indexterm><primary>profile path</primary></indexterm>
	<indexterm><primary>smbpasswd</primary></indexterm>
	<indexterm><primary>tdbsam</primary></indexterm>
	<indexterm><primary>LDAP backend</primary></indexterm>
	<indexterm><primary>export</primary></indexterm>
	<indexterm><primary>import</primary></indexterm>
	If you choose to use a tdbsam (<filename>passdb.tdb</filename>) backend file, your best choice
	is to use <command>pdbedit</command> 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 who end up in the merged smbpasswd
	file must have an account in <filename>/etc/passwd</filename>. The resulting smbpasswd file
	may be exported or imported into either a tdbsam (<filename>passdb.tdb</filename>) or
	an LDAP backend.
	</para>

	<figure id="NT4DUM">
		<title>View of Accounts in NT4 Domain User Manager</title>
		<imagefile scale="50">UserMgrNT4</imagefile>
	</figure>

</sect2>


<sect2>
	<title>Political Issues</title>

	<para>
	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.
	</para>

	<para>
	The best advice that can be given to those who set out to merge NT4 domains into a single
	Samba-3 domain is to promote (sell) the action as one that reduces costs and delivers
	greater network interoperability and manageability.
	</para>

	</sect2>

</sect1>

<sect1>
	<title>Implementation</title>

	<para>
	From feedback on the Samba mailing lists, it seems that most Windows NT4 migrations
	to Samba-3 are being performed using a new server or a new installation of a Linux or UNIX
	server. If you contemplate doing this, please note that the steps that follow in this
	chapter assume familiarity with the information that has been previously covered in this
	book. You are particularly encouraged to be familiar with <link linkend="secure"/>,
	<link linkend="Big500users"/> and <link linkend="happy"/>.
	</para>

	<para>
	We 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 &smb.conf; file for the <parameter>add user script</parameter>
	collection of parameters are used to effect the addition of accounts into the passdb backend.
	</para>

	<para>
	Before proceeding to NT4 migration using either a tdbsam or ldapsam, it is most strongly recommended to
	review <link linkend="ch5-dnshcp-setup"/> for DNS and DHCP configuration. The importance of correctly
	functioning name resolution must be recognized. This applies equally for both hostname and NetBIOS names
	(machine names, computer names, domain names, workgroup names &smbmdash; ALL names!).
	</para>

	<para>
	The migration process involves the following steps:
	</para>

	<itemizedlist>
		<listitem><para>
		Prepare the target Samba-3 server. This involves configuring Samba-3 for
		migration to either a tdbsam or an ldapsam backend.
		</para></listitem>

		<listitem><para>
		<indexterm><primary>uppercase</primary></indexterm>
		<indexterm><primary>Posix</primary></indexterm>
		<indexterm><primary>lower-case</primary></indexterm>
		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 lowercase user and group
		names.
		</para></listitem>

		<listitem><para>
		Step through the migration process.
		</para></listitem>

		<listitem><para><indexterm><primary>PDC</primary></indexterm>
		Remove the NT4 PDC from the network.
		</para></listitem>

		<listitem><para>
		Upgrade the Samba-3 server from a BDC to a PDC, and validate all account
		information.
		</para></listitem>
	</itemizedlist>

	<para>
	It may help to use the above outline as a pre-migration checklist.
	</para>

	<sect2>
	<title>NT4 Migration Using LDAP Backend</title>

	<para>
	In this example, the migration is of an NT4 PDC to a Samba-3 PDC with an LDAP backend. The accounts about
	to be migrated are shown in <link linkend="NT4DUM"/>. In this example use is made 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. Other scripts 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 <link linkend="ch8-vampire"/> to see which scripts
	must be provided so that the migration process can complete.
	</para>

	<para>
	Verify that you have correctly specified in the &smb.conf; file the scripts and arguments 
	that should be passed to them before attempting to perform the account migration. Note also
	that the deletion scripts must be commented out during migration. These should be uncommented
	following successful migration of the NT4 Domain accounts.
	</para>

	<warning><para>
	Under absolutely no circumstances should the Samba daemons be started until instructed to do so.
	Delete the <filename>/etc/samba/secrets.tdb</filename> file and all Samba control tdb files
	before commencing the following configuration steps.
	</para></warning>

	<table id="ch8-vampire">
		<title>Samba &smb.conf; Scripts Essential to Samba Operation</title>
		<tgroup cols="3">
			<colspec align="left"/>
			<colspec align="center"/>
			<colspec align="center"/>
			<thead>
				<row>
					<entry>Entity</entry>
					<entry>ldapsam Script</entry>
					<entry>tdbsam Script</entry>
				</row>
			</thead>
			<tbody>
				<row>
					<entry>Add User Accounts</entry>
					<entry>smbldap-useradd</entry>
					<entry>useradd</entry>
				</row>
				<row>
					<entry>Delete User Accounts</entry>
					<entry>smbldap-userdel</entry>
					<entry>userdel</entry>
				</row>
				<row>
					<entry>Add Group Accounts</entry>
					<entry>smbldap-groupadd</entry>
					<entry>groupadd</entry>
				</row>
				<row>
					<entry>Delete Group Accounts</entry>
					<entry>smbldap-groupdel</entry>
					<entry>groupdel</entry>
				</row>
				<row>
					<entry>Add User to Group</entry>
					<entry>smbldap-groupmod</entry>
					<entry>usermod (See Note)</entry>
				</row>
				<row>
					<entry>Add Machine Accounts</entry>
					<entry>smbldap-useradd</entry>
					<entry>useradd</entry>
				</row>
			</tbody>
		</tgroup>
	</table>

	<note><para>
	<indexterm><primary>usermod</primary></indexterm>
	<indexterm><primary>groupmem</primary></indexterm>
	<indexterm><primary>smbldap-tools</primary></indexterm>
	The UNIX/Linux <command>usermod</command> 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 must create your own tool to do this. Alternately, you can search the Web
	to locate a utility called <command>groupmem</command> (by George Kraft) that provides this functionality.
	The <command>groupmem</command> utility was contributed to the shadow package but has not surfaced
	in the formal commands provided by Linux distributions (March 2004).
	</para></note>

	<note><para>
	<indexterm><primary>tdbdump</primary></indexterm>
	The <command>tdbdump</command> 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 forgo its use.
	</para></note>

	<para>
	<indexterm><primary>User Manager</primary></indexterm>
	Before starting the migration, all dead accounts were removed from the NT4 domain using the User Manager for Domains.
	</para>

	<procedure>
	<title>User Migration Steps</title>

		<step><para>
		Configure the Samba &smb.conf; file to create a BDC. An example configuration is
		given in <link linkend="sbent4smb"/>.
		The delete scripts are commented out so that during the process of migration
		no account information can be deleted.
		</para></step>

<example id="sbent4smb">
<title>NT4 Migration Samba-3 Server <filename>smb.conf</filename> &smbmdash; Part: A</title>
<smbconfblock>
<smbconfsection name="[global]"/>
        <smbconfoption name="workgroup">DAMNATION</smbconfoption>
        <smbconfoption name="netbios name">MERLIN</smbconfoption>
        <smbconfoption name="passdb backend">ldapsam:ldap://localhost</smbconfoption>
        <smbconfoption name="log level">1</smbconfoption>
        <smbconfoption name="syslog">0</smbconfoption>
        <smbconfoption name="log file">/var/log/samba/%m</smbconfoption>
        <smbconfoption name="max log size">0</smbconfoption>
        <smbconfoption name="smb ports">139 445</smbconfoption>
        <smbconfoption name="name resolve order">wins bcast hosts</smbconfoption>
        <smbconfoption name="add user script">/opt/IDEALX/sbin/smbldap-useradd -m '%u'</smbconfoption>
        <smbconfoption name="#delete user script">/opt/IDEALX/sbin/smbldap-userdel '%u'</smbconfoption>
        <smbconfoption name="add group script">/opt/IDEALX/sbin/smbldap-groupadd '%g'</smbconfoption>
        <smbconfoption name="#delete group script">/opt/IDEALX/sbin/smbldap-groupdel '%g'</smbconfoption>
		<smbconfoption name="add user to group script">/opt/IDEALX/sbin/ smbldap-groupmod -m '%u' '%g'</smbconfoption>
		<smbconfoption name="#delete user from group script">/opt/IDEALX/sbin/smbldap-groupmod -x '%u' '%g'</smbconfoption>
		<smbconfoption name="set primary group script">/opt/IDEALX/sbin/smbldap-usermod -g '%g' '%u'</smbconfoption>
		<smbconfoption name="add machine script">/opt/IDEALX/sbin/smbldap-useradd -w '%u'</smbconfoption>
        <smbconfoption name="logon script">scripts\logon.cmd</smbconfoption>
        <smbconfoption name="logon path">\\%L\profiles\%U</smbconfoption>
        <smbconfoption name="logon home">\\%L\%U</smbconfoption>
        <smbconfoption name="logon drive">X:</smbconfoption>
        <smbconfoption name="domain logons">Yes</smbconfoption>
        <smbconfoption name="domain master">No</smbconfoption>
        <smbconfoption name="#wins support">Yes</smbconfoption>
        <smbconfoption name="wins server">192.168.123.124</smbconfoption>
        <smbconfoption name="ldap admin dn">cn=Manager,dc=terpstra-world,dc=org</smbconfoption>
        <smbconfoption name="ldap group suffix">ou=Groups</smbconfoption>
        <smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption>
        <smbconfoption name="ldap machine suffix">ou=People</smbconfoption>
        <smbconfoption name="ldap passwd sync">Yes</smbconfoption>
        <smbconfoption name="ldap suffix">dc=terpstra-world,dc=org</smbconfoption>
        <smbconfoption name="ldap ssl">no</smbconfoption>
        <smbconfoption name="ldap timeout">20</smbconfoption>
        <smbconfoption name="ldap user suffix">ou=People</smbconfoption>
        <smbconfoption name="idmap backend">ldap:ldap://localhost</smbconfoption>
        <smbconfoption name="idmap uid">15000-20000</smbconfoption>
        <smbconfoption name="idmap gid">15000-20000</smbconfoption>
        <smbconfoption name="winbind nested groups">Yes</smbconfoption>
        <smbconfoption name="ea support">Yes</smbconfoption>
        <smbconfoption name="map acl inherit">Yes</smbconfoption>
	</smbconfblock>
</example>

<example id="sbent4smb2">
<title>NT4 Migration Samba-3 Server <filename>smb.conf</filename> &smbmdash; Part: B</title>
<smbconfblock>
<smbconfsection name="[apps]"/>
        <smbconfoption name="comment">Application Data</smbconfoption>
        <smbconfoption name="path">/data/home/apps</smbconfoption>
		<smbconfoption name="read only">No</smbconfoption>

<smbconfsection name="[homes]"/>
        <smbconfoption name="comment">Home Directories</smbconfoption>
        <smbconfoption name="path">/home/users/%U/Documents</smbconfoption>
        <smbconfoption name="valid users">%S</smbconfoption>
        <smbconfoption name="read only">No</smbconfoption>
        <smbconfoption name="browseable">No</smbconfoption>

<smbconfsection name="[printers]"/>
        <smbconfoption name="comment">SMB Print Spool</smbconfoption>
        <smbconfoption name="path">/var/spool/samba</smbconfoption>
        <smbconfoption name="guest ok">Yes</smbconfoption>
        <smbconfoption name="printable">Yes</smbconfoption>
        <smbconfoption name="use client driver">No</smbconfoption>
        <smbconfoption name="browseable">No</smbconfoption>

<smbconfsection name="[netlogon]"/>
        <smbconfoption name="comment">Network Logon Service</smbconfoption>
        <smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
        <smbconfoption name="guest ok">Yes</smbconfoption>
        <smbconfoption name="locking">No</smbconfoption>

<smbconfsection name="[profiles]"/>
        <smbconfoption name="comment">Profile Share</smbconfoption>
        <smbconfoption name="path">/var/lib/samba/profiles</smbconfoption>
        <smbconfoption name="read only">No</smbconfoption>
        <smbconfoption name="profile acls">Yes</smbconfoption>

<smbconfsection name="[profdata]"/>
        <smbconfoption name="comment">Profile Data Share</smbconfoption>
        <smbconfoption name="path">/var/lib/samba/profdata</smbconfoption>
        <smbconfoption name="read only">No</smbconfoption>
        <smbconfoption name="profile acls">Yes</smbconfoption>

<smbconfsection name="[print$]"/>
        <smbconfoption name="comment">Printer Drivers</smbconfoption>
        <smbconfoption name="path">/var/lib/samba/drivers</smbconfoption>
	</smbconfblock>
</example>

		<step><para>
		<indexterm><primary>slapd.conf</primary></indexterm>
		Configure OpenLDAP in preparation for the migration. An example
		<filename>sladp.conf</filename> file is shown in <link linkend="sbentslapd"/>.
		The <constant>rootpw</constant> value is an encrypted password string that can
		be obtained by executing the <command>slappasswd</command> command.
		</para></step>

<example id="sbentslapd">
<title>NT4 Migration LDAP Server Configuration File: <filename>/etc/openldap/slapd.conf</filename> &smbmdash; Part A</title>
<screen>
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/samba3.schema

pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args

access to dn.base=""
                by self write
                by * auth

access to attr=userPassword
                by self write
                by * auth

access to attr=shadowLastChange
                by self write
                by * read

access to *
                by * read
                by anonymous auth
</screen>
</example>

<example id="sbentslapd2">
<title>NT4 Migration LDAP Server Configuration File: <filename>/etc/openldap/slapd.conf</filename> &smbmdash; Part B</title>
<screen>
#loglevel       256

#schemacheck     on
idletimeout     30
#backend         bdb
database        bdb
checkpoint      1024 5
cachesize       10000

suffix          "dc=terpstra-world,dc=org"
rootdn          "cn=Manager,dc=terpstra-world,dc=org"

# rootpw = not24get
rootpw          {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV

directory       /var/lib/ldap

# Indices to maintain
index objectClass           eq
index cn                    pres,sub,eq
index sn                    pres,sub,eq
index uid                   pres,sub,eq
index displayName           pres,sub,eq
index uidNumber             eq
index gidNumber             eq
index memberUID             eq
index sambaSID              eq
index sambaPrimaryGroupSID  eq
index sambaDomainName       eq
index default               sub
</screen>
</example>

		<step><para>
		<indexterm><primary>nss_ldap</primary></indexterm>
		<indexterm><primary>/etc/ldap.conf</primary></indexterm>
		Install the PADL <command>nss_ldap</command> tool set, then configure the <filename>/etc/ldap.conf</filename>
		as shown in <link linkend="sbrntldapconf"/>.
		</para></step>

<example id="sbrntldapconf">
<title>NT4 Migration NSS LDAP File: <filename>/etc/ldap.conf</filename></title>
<screen>
host    127.0.0.1

base    dc=terpstra-world,dc=org

ldap_version    3

binddn cn=Manager,dc=terpstra-world,dc=org
bindpw not24get

pam_password exop

nss_base_passwd         ou=People,dc=terpstra-world,dc=org?one
nss_base_shadow         ou=People,dc=terpstra-world,dc=org?one
nss_base_group          ou=Groups,dc=terpstra-world,dc=org?one

ssl off
</screen>
</example>

		<step><para>
		<indexterm><primary>/etc/nsswitch.conf</primary></indexterm>
		Edit the <filename>/etc/nsswitch.conf</filename> file so it has the entries shown
		in <link linkend="sbentnss"/>. Note that the LDAP entries have been commented out.
		This is deliberate. If these entries are active (not commented out), and the
		<filename>/etc/ldap.conf</filename> file has been configured, when the LDAP server
		is started, the process of starting the LDAP server will cause LDAP lookups. This
		causes the LDAP server <command>slapd</command> to hang because it finds port 389
		open and therefore cannot gain exclusive control of it. By commenting these entries
		out, it is possible to avoid this gridlock situation and thus the overall
		installation and configuration will progress more smoothly.
		</para></step>

<example id="sbentnss">
<title>NT4 Migration NSS Control File: <filename>/etc/nsswitch.conf</filename> (Stage:1)</title>
<screen>
passwd:         files #ldap
shadow:         files #ldap
group:          files #ldap

hosts:          files dns wins
networks:       files dns

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files
publickey:      files

bootparams:     files
automount:      files nis
aliases:        files
#passwd_compat: ldap       #Not needed.
#group_compat:  ldap      #Not needed.
</screen>
</example>

		<step><para>
		Validate the the target NT4 PDC name is being correctly resolved to its IP address by
		executing the following:
<screen>
&rootprompt; ping transgression
PING transgression.terpstra-world.org (192.168.1.5) 56(84) bytes of data.
64 bytes from (192.168.1.5): icmp_seq=1 ttl=128 time=0.159 ms
64 bytes from (192.168.1.5): icmp_seq=2 ttl=128 time=0.192 ms
64 bytes from (192.168.1.5): icmp_seq=3 ttl=128 time=0.141 ms

--- transgression.terpstra-world.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.141/0.164/0.192/0.021 ms
</screen>
		Do not proceed to the next step if this step fails. It is imperative that the name of the PDC
		can be resolved to its IP address. If this is broken, fix it.
		</para></step>

		<step><para>
		Pull the domain SID from the NT4 domain that is being migrated as follows:
<screen>
&rootprompt; net rpc getsid -S TRANGRESSION -U Administrator%not24get
Storing SID S-1-5-21-1385457007-882775198-1210191635 \
                     for Domain DAMNATION in secrets.tdb
</screen>
		</para>

		<para>
		Another way to obtain the domain SID from the target NT4 domain that is being
		migrated to Samba-3 is by executing the following:
<screen>
&rootprompt; net rpc info -S TRANSGRESSION
</screen>
		If this method is used, do not forget to store the SID obtained into the
		<filename>secrets.tdb</filename> file. This can be done by executing:
<screen>
&rootprompt; net setlocalsid S-1-5-21-1385457007-882775198-1210191635
</screen>
		</para></step>

		<step><para>
		<indexterm><primary>Idealx</primary></indexterm>
		<indexterm><primary>configure.pl</primary></indexterm>
		<indexterm><primary>/opt/IDEALX/sbin</primary></indexterm>
		<indexterm><primary>smbldap-tools</primary></indexterm>
		Install the Idealx <command>smbldap-tools</command> software package, following
		the instructions given in <link linkend="sbeidealx"/>. The resulting perl scripts
		should be located in the <filename>/opt/IDEALX/sbin</filename> directory.
		Change into that location, or wherever the scripts have been installed. Execute the
		<filename>configure.pl</filename> script to configure the Idealx package for use.
		Note: Use the domain SID obtained from the step above. The following is
		an example configuration session:
<screen>
&rootprompt; ./configure.pl
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
       smbldap-tools script configuration
       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Before starting, check
 . if your samba controller is up and running.
 . if the domain SID is defined
                           (you can get it with the 'net getlocalsid')

 . you can leave the configuration using the Crtl-c key combination
 . empty value can be set with the "." character
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Looking for configuration files...

Samba Config File Location [/etc/samba/smb.conf] &gt;
smbldap Config file Location (global parameters)
           [/etc/smbldap-tools/smbldap.conf] &gt;
smbldap Config file Location (bind parameters)
      [/etc/smbldap-tools/smbldap_bind.conf] &gt;
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Let's start configuring the smbldap-tools scripts ...

. workgroup name: name of the domain Samba act as a PDC
  workgroup name [DAMNATION] &gt;
. netbios name: netbios name of the samba controller
  netbios name [MERLIN] &gt;
. logon drive: local path to which the home directory
         will be connected (for NT Workstations). Ex: 'H:'
  logon drive [X:] &gt; H:
. logon home: home directory location (for Win95/98 or NT Workstation)
  (use %U as username) Ex:'\\MERLIN\home\%U'
  logon home (leave blank if you don't want homeDirectory)
                                       [\\MERLIN\home\%U] &gt; \\%L\%U
. logon path: directory where roaming profiles are stored.
                                     Ex:'\\MERLIN\profiles\%U'
  logon path (leave blank if you don't want roaming profile)
                          [\\MERLIN\profiles\%U] &gt; \\%L\profiles\%U
. home directory prefix (use %U as username) [/home/%U] >
                                                        /home/users/%U
. default user netlogon script (use %U as username) 
                               [%U.cmd] &gt; scripts\logon.cmd
  default password validation time (time in days) [45] > 180
. ldap suffix [dc=terpstra-world,dc=org] &gt;
. ldap group suffix [ou=Groups] &gt;
. ldap user suffix [ou=People] &gt;
. ldap machine suffix [ou=People] &gt;
. Idmap suffix [ou=Idmap] &gt;
. sambaUnixIdPooldn: object where you want to store the next uidNumber
  and gidNumber available for new users and groups
  sambaUnixIdPooldn object (relative to ${suffix}) 
                                         [sambaDomainName=DAMNATION] >
. ldap master server: 
           IP address or DNS name of the master (writable) ldap server
  ldap master server [] &gt; 127.0.0.1
. ldap master port [389] &gt;
. ldap master bind dn [cn=Manager,dc=terpstra-world,dc=org] &gt;
. ldap master bind password [] &gt;
. ldap slave server: IP address or DNS name of the slave ldap server:
                                         can also be the master one
  ldap slave server [] &gt; 127.0.0.1
. ldap slave port [389] &gt;
. ldap slave bind dn [cn=Manager,dc=terpstra-world,dc=org] &gt;
. ldap slave bind password [] &gt;
. ldap tls support (1/0) [0] &gt;
. SID for domain DAMNATION: SID of the domain 
                       (can be obtained with 'net getlocalsid MERLIN')
  SID for domain DAMNATION []
        &gt; S-1-5-21-1385457007-882775198-1210191635
. unix password encryption: encryption used for unix passwords
unix password encryption (CRYPT, MD5, SMD5, SSHA, SHA) [SSHA] &gt; MD5
. default user gidNumber [513] &gt;
. default computer gidNumber [515] &gt;
. default login shell [/bin/bash] &gt;
. default domain name to append to mail address [] &gt;
                                                    terpstra-world.org
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
backup old configuration files:
  /etc/smbldap-tools/smbldap.conf-&gt;
                              /etc/smbldap-tools/smbldap.conf.old
  /etc/smbldap-tools/smbldap_bind.conf-&gt;
                              /etc/smbldap-tools/smbldap_bind.conf.old
writing new configuration file:
  /etc/smbldap-tools/smbldap.conf done.
  /etc/smbldap-tools/smbldap_bind.conf done.
</screen>
		<indexterm><primary>sambaDomainName</primary></indexterm>
		<indexterm><primary>NextFreeUnixId</primary></indexterm>
		<indexterm><primary>updating smbldap-tools</primary></indexterm>
		<indexterm><primary>smbldap-tools updating</primary></indexterm>
		Note that the NT4 domain SID that was previously obtained was entered above. Also,
		the sambaUnixIdPooldn object was specified as sambaDomainName=DAMNATION. This is
		the location into which the Idealx smbldap-tools store the next available UID/GID
		information. It is also where Samba stores domain specific information such as the
		next RID, the SID, and so on. In older version of the smbldap-tools this information
		was stored in the sambaUnixIdPooldn DIT location cn=NextFreeUnixId. Where smbldap-tools
		are being upgraded to version 0.9.1 it is appropriate to update this to the new location
		only if the directory information is also relocated.
		</para></step>

		<step><para>
		Start the LDAP server using the system interface script. On Novell SLES9
		this is done as shown here:
<screen>
&rootprompt; rcldap start
</screen>
		</para></step>

		<step><para>
		Edit the <filename>/etc/nsswitch.conf</filename> file so it has the entries shown in
		<link linkend="sbentnss2"/>. Note that the LDAP entries have now been uncommented.
		</para></step>

<example id="sbentnss2">
<title>NT4 Migration NSS Control File: <filename>/etc/nsswitch.conf</filename> (Stage:2)</title>
<screen>
passwd:         files ldap
shadow:         files ldap
group:          files ldap

hosts:          files dns wins
networks:       files dns

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files
publickey:      files

bootparams:     files
automount:      files nis
aliases:        files
#passwd_compat: ldap       #Not needed.
#group_compat:  ldap      #Not needed.
</screen>
</example>

		<step><para>
		The LDAP management password must be installed into the <filename>secrets.tdb</filename>
		file as follows:
<screen>
&rootprompt; smbpasswd -w not24get
Setting stored password for 
            "cn=Manager,dc=terpstra-world,dc=org" in secrets.tdb
</screen>
		</para></step>

		<step><para>
		Populate the LDAP directory as shown here:
<screen>
&rootprompt; /opt/IDEALX/sbin/smbldap-populate -a root -k 0 -m 0
Using workgroup name from sambaUnixIdPooldn (smbldap.conf):
                          sambaDomainName=DAMNATION
Using builtin directory structure
adding new entry: dc=terpstra-world,dc=org
adding new entry: ou=People,dc=terpstra-world,dc=org
adding new entry: ou=Groups,dc=terpstra-world,dc=org
entry ou=People,dc=terpstra-world,dc=org already exist.
adding new entry: ou=Idmap,dc=terpstra-world,dc=org
adding new entry: sambaDomainName=DAMNATION,dc=terpstra-world,dc=org
adding new entry: uid=root,ou=People,dc=terpstra-world,dc=org
adding new entry: uid=nobody,ou=People,dc=terpstra-world,dc=org
adding new entry: cn=Domain Admins,ou=Groups,dc=terpstra-world,dc=org
adding new entry: cn=Domain Users,ou=Groups,dc=terpstra-world,dc=org
adding new entry: cn=Domain Guests,ou=Groups,dc=terpstra-world,dc=org
adding new entry: cn=Domain Computers,ou=Groups,dc=terpstra-world,dc=org
adding new entry: cn=Administrators,ou=Groups,dc=terpstra-world,dc=org
adding new entry: cn=Print Operators,ou=Groups,dc=terpstra-world,dc=org
adding new entry: cn=Backup Operators,ou=Groups,dc=terpstra-world,dc=org
adding new entry: cn=Replicators,ou=Groups,dc=terpstra-world,dc=org
</screen>
		The script tries to add the ou=People container twice, hence the error message.
		This is expected behavior.
		</para></step>

		<step><para>
		<indexterm><primary>Novell SUSE SLES 9</primary></indexterm>
		Restart the LDAP server following initialization of the LDAP directory. Execute the
		system control script provided on your system. The following steps can be used on
		Novell SUSE SLES 9:
<screen>
&rootprompt; rcldap restart
&rootprompt; chkconfig ldap on
</screen>
		</para></step>

		<step><para>
		Verify that the new user accounts that have been added to the LDAP directory can be
		resolved as follows:
<screen>
&rootprompt; getent passwd
...
nobody:x:65534:65533:nobody:/var/lib/nobody:/bin/bash
man:x:13:62:Manual pages viewer:/var/cache/man:/bin/bash
news:x:9:13:News system:/etc/news:/bin/bash
uucp:x:10:14:Unix-to-Unix CoPy system:/etc/uucp:/bin/bash
+::0:0:::
root:x:0:0:Netbios Domain Administrator:/home/users/root:/bin/false
nobody:x:999:514:nobody:/dev/null:/bin/false
</screen>
		Now repeat this for the group accounts as shown here:
<screen>
&rootprompt; getent group
...
nobody:x:65533:
nogroup:x:65534:nobody
users:x:100:
+::0:
Domain Admins:x:512:root
Domain Users:x:513:
Domain Guests:x:514:
Domain Computers:x:515:
Administrators:x:544:
Print Operators:x:550:
Backup Operators:x:551:
Replicators:x:552:
</screen>
		In both cases the LDAP accounts follow the <quote>+::0:</quote> entry.
		</para></step>

		<step><para>
		Now it is time to join the Samba BDC to the target NT4 domain that is being
		migrated to Samba-3 by executing the following:
<screen>
&rootprompt; net rpc join -S TRANSGRESSION -U Administrator%not24get
merlin:/opt/IDEALX/sbin # net rpc join -S TRANSGRESSION \
                         -U Administrator%not24get
Joined domain DAMNATION.
</screen>
		</para></step>

		<step><para>
		Set the new domain administrator (root) password for both UNIX and Windows as shown here:
<screen>
&rootprompt; /opt/IDEALX/sbin/smbldap-passwd root
Changing password for root
New password : ********
Retype new password : ********
</screen>
		Note: During account migration, the Windows Administrator account will not be migrated
		to the Samba server.
		</para></step>

		<step><para>
		Now validate that these accounts can be resolved using Samba's tools as
		shown here for user accounts:
<screen>
&rootprompt; pdbedit -Lw
root:0:84B0D8E14D158FF8417EAF50CFAC29C3:
        AF6DD3FD4E2EA8BDE1695A3F05EFBF52:[U          ]:LCT-425F6467:
nobody:65534:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:
        NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:[NU         ]:LCT-00000000:
</screen>
		Now complete the following step to validate that group account mappings have
		been correctly set:
<screen>
&rootprompt; net groupmap list
Domain Admins (S-1-5-21-1385457007-882775198-1210191635-512)
                                            -&gt; Domain Admins
Domain Users (S-1-5-21-1385457007-882775198-1210191635-513) 
                                             -&gt; Domain Users
Domain Guests (S-1-5-21-1385457007-882775198-1210191635-514) 
                                            -&gt; Domain Guests
Domain Computers (S-1-5-21-1385457007-882775198-1210191635-515) 
                                          -&gt; Domain Computers
Administrators (S-1-5-32-544) -&gt; Administrators
Print Operators (S-1-5-32-550) -&gt; Print Operators
Backup Operators (S-1-5-32-551) -&gt; Backup Operators
Replicators (S-1-5-32-552) -> Replicators
</screen>
		These are the expected results for a correctly configured system.
		</para></step>

		<step><para>
		Commence migration as shown here:
<screen>
&rootprompt; net rpc vampire -S TRANSGRESSION \
       -U Administrator%not24get &gt; /tmp/vampire.log 2&gt;1
</screen>
		Check the vampire log to confirm that only expected errors have been
		reported. See <link linkend="sbevam1"/>.
		</para></step>

		<step><para>
		The migration of user accounts can be quickly validated as follows:
<screen>
&rootprompt; pdbedit -Lw
root:0:84B0D8E14D158FF8417EAF50CFAC29C3:...
nobody:65534:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:...
Administrator:0:84B0D8E14D158FF8417EAF50CFAC29C3:...
Guest:1:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:...
TRANSGRESSION$:2:CC044B748CEE294CE76B6B0D1B86C1A8:...
IUSR_TRANSGRESSION:3:64046AC81B056C375F9537FC409085F8:...
MIDEARTH$:4:E93186E5819706D2AAD3B435B51404EE:...
atrickhoffer:5:DC08CFE0C12B2867352502E32A407F23:...
barryf:6:B829BCDE01FF24376E45D5F10408CFBD:...
fsellerby:7:6A97CBEBE8F9826B417EAF50CFAC29C3:...
gdaison:8:48F6A8C8A900024351DA8C2061C5F1D3:...
hrambotham:9:7330D9EA0964465EAAD3B435B51404EE:...
jrhapsody:10:ACBA7D207E2BA35D9BD41A26B01626BD:...
maryk:11:293B5A4CA41F6CA1A7D80430B8342B73:...
jacko:12:8E8982D86BD037C364BBD09A598E07AD:...
bridge:13:0D2CA7D2BE67FE2193BE3A377C968336:...
sharpec:14:8841A75CAC19D2855D8B73B1F4D430F8:...
jimbo:15:6E8BDC904FD9EC5C17306D272A9441BB:...
dhenwick:16:D1694A03C33584BDAAD3B435B51404EE:...
dork:17:69E2D19E69A593D5AAD3B435B51404EE:...
blue:18:E355EBF9559979FEAAD3B435B51404EE:...
billw:19:EE35C3481CF7F7DB484448BC86A641A5:...
rfreshmill:20:7EC033B58661B60CAAD3B435B51404EE:...
MAGGOT$:21:A3B9334765AD30F7AAD3B435B51404EE:...
TRENTWARE$:22:1D92C8DD5E7F0DDF93BE3A377C968336:...
MORTON$:23:89342E69DCA9D3F8AAD3B435B51404EE:...
NARM$:24:2B93E2D1D25448BDAAD3B435B51404EE:...
LAPDOG$:25:14AA535885120943AAD3B435B51404EE:...
SCAVENGER$:26:B6288EB6D147B56F8963805A19B0ED49:...
merlin$:27:820C50523F368C54AB9D85AE603AD09D:...
</screen>
		</para></step>

		<step><para>
		The mapping of UNIX and Windows groups can be validated as show here:
<screen>
&rootprompt; net groupmap list
Domain Admins (S-1-5-21-1385457007-882775198-1210191635-512)
                                                     -&gt; Domain Admins
Domain Users (S-1-5-21-1385457007-882775198-1210191635-513)
                                                      -&gt; Domain Users
Domain Guests (S-1-5-21-1385457007-882775198-1210191635-514)
                                                     -&gt; Domain Guests
Domain Computers (S-1-5-21-1385457007-882775198-1210191635-515)
                                                   -&gt; Domain Computers
Administrators (S-1-5-32-544) -&gt; Administrators
Print Operators (S-1-5-32-550) -&gt; Print Operators
Backup Operators (S-1-5-32-551) -&gt; Backup Operators
Replicator (S-1-5-32-552) -&gt; Replicators
Engineers (S-1-5-21-1385457007-882775198-1210191635-1020) -&gt; Engineers
Marketoids (S-1-5-21-1385457007-882775198-1210191635-1022) -&gt; Marketoids
Gnomes (S-1-5-21-1385457007-882775198-1210191635-1023) -&gt; Gnomes
Catalyst (S-1-5-21-1385457007-882775198-1210191635-1024) -&gt; Catalyst
Recieving (S-1-5-21-1385457007-882775198-1210191635-1025) -&gt; Recieving
Rubberboot (S-1-5-21-1385457007-882775198-1210191635-1026) -&gt; Rubberboot
Sales (S-1-5-21-1385457007-882775198-1210191635-1027) -&gt; Sales
Accounting (S-1-5-21-1385457007-882775198-1210191635-1028) -&gt; Accounting
Shipping (S-1-5-21-1385457007-882775198-1210191635-1029) -&gt; Shipping
Account Operators (S-1-5-32-548) -&gt; Account Operators
Guests (S-1-5-32-546) -&gt; Guests
Server Operators (S-1-5-32-549) -&gt; Server Operators
Users (S-1-5-32-545) -&gt; Users
</screen>
		It is of vital importance that the domain SID portions of all group
		accounts are identical.
		</para></step>

		<step><para>
		The final responsibility in the migration process is to create identical
		shares and printing resources on the new Samba-3 server, copy all data
		across, set up privileges, and set share and file/directory access controls.
		</para></step>

		<step><para>
		<indexterm><primary>domain master</primary></indexterm>
		<indexterm><primary>PDC</primary></indexterm>
		Edit the &smb.conf; file to  reset the parameter 
		<smbconfoption name="domain master">Yes</smbconfoption> so that
		the Samba server functions as a PDC for the purpose of migration.
		Also, uncomment the deletion scripts so they will now be fully functional,
		enable the <parameter>wins support = yes</parameter> parameter and
		comment out the <parameter>wins server</parameter>. Validate the configuration
		with the <command>testparm</command> utility as shown here:
<screen>
&rootprompt; testparm
Load smb config files from /etc/samba/smb.conf
Processing section "[apps]"
Processing section "[media]"
Processing section "[homes]"
Processing section "[printers]"
Processing section "[netlogon]"
Processing section "[profiles]"
Processing section "[profdata]"
Processing section "[print$]"
Loaded services file OK.
Server role: ROLE_DOMAIN_PDC
Press enter to see a dump of your service definitions
</screen>
                </para></step>

		<step><para>
		Now shut down the old NT4 PDC. Only when the old NT4 PDC and all
		NT4 BDCs have been shut down can the Samba-3 PDC be started.
		</para></step>

		<step><para>
		All workstations should function as they did with the old NT4 PDC. All
		interdomain trust accounts should remain in place and fully functional.
		All machine accounts and user logon accounts should also function correctly.
		</para></step>

		<step><para>
		The configuration of Samba-3 BDC servers can be accomplished now or at any
		convenient time in the future. Please refer to the carefully detailed process
		for doing so is outlined in <link linkend="sbehap-bldg1"/>.
		</para></step>

	</procedure>

	<sect3 id="sbevam1">
	<title>Migration Log Validation</title>

	<para>
	The following <filename>vampire.log</filename> file is typical of a valid migration.
<screen>
adding user Administrator to group Domain Admins
adding user atrickhoffer to group Engineers
adding user dhenwick to group Engineers
adding user dork to group Engineers
adding user rfreshmill to group Marketoids
adding user jacko to group Gnomes
adding user jimbo to group Gnomes
adding user maryk to group Gnomes
adding user gdaison to group Gnomes
adding user dhenwick to group Catalyst
adding user jacko to group Catalyst
adding user jacko to group Recieving
adding user blue to group Recieving
adding user hrambotham to group Rubberboot
adding user billw to group Sales
adding user bridge to group Sales
adding user jrhapsody to group Sales
adding user maryk to group Sales
adding user rfreshmill to group Sales
adding user fsellerby to group Sales
adding user sharpec to group Sales
adding user jimbo to group Accounting
adding user gdaison to group Accounting
adding user jacko to group Shipping
adding user blue to group Shipping
Fetching DOMAIN database
Creating unix group: 'Engineers'
Creating unix group: 'Marketoids'
Creating unix group: 'Gnomes'
Creating unix group: 'Catalyst'
Creating unix group: 'Recieving'
Creating unix group: 'Rubberboot'
Creating unix group: 'Sales'
Creating unix group: 'Accounting'
Creating unix group: 'Shipping'
Creating account: Administrator
Creating account: Guest
Creating account: TRANSGRESSION$
Creating account: IUSR_TRANSGRESSION
Creating account: MIDEARTH$
Creating account: atrickhoffer
Creating account: barryf
Creating account: fsellerby
Creating account: gdaison
Creating account: hrambotham
Creating account: jrhapsody
Creating account: maryk
Creating account: jacko
Creating account: bridge
Creating account: sharpec
Creating account: jimbo
Creating account: dhenwick
Creating account: dork
Creating account: blue
Creating account: billw
Creating account: rfreshmill
Creating account: MAGGOT$
Creating account: TRENTWARE$
Creating account: MORTON$
Creating account: NARM$
Creating account: LAPDOG$
Creating account: SCAVENGER$
Creating account: merlin$
Group members of Domain Admins: Administrator,
Group members of Domain Users: Administrator(primary),
TRANSGRESSION$(primary),IUSR_TRANSGRESSION(primary),
MIDEARTH$(primary),atrickhoffer(primary),barryf(primary),
fsellerby(primary),gdaison(primary),hrambotham(primary),
jrhapsody(primary),maryk(primary),jacko(primary),bridge(primary),
sharpec(primary),jimbo(primary),dhenwick(primary),dork(primary),
blue(primary),billw(primary),rfreshmill(primary),MAGGOT$(primary),
TRENTWARE$(primary),MORTON$(primary),NARM$(primary),
LAPDOG$(primary),SCAVENGER$(primary),merlin$(primary),
Group members of Domain Guests: Guest(primary),
Group members of Engineers: atrickhoffer,dhenwick,dork,
Group members of Marketoids: rfreshmill,
Group members of Gnomes: jacko,jimbo,maryk,gdaison,
Group members of Catalyst: dhenwick,jacko,
Group members of Recieving: jacko,blue,
Group members of Rubberboot: hrambotham,
Group members of Sales: billw,bridge,jrhapsody,maryk,
rfreshmill,fsellerby,sharpec,
Group members of Accounting: jimbo,gdaison,
Group members of Shipping: jacko,blue,
Fetching BUILTIN database
skipping SAM_DOMAIN_INFO delta for 'Builtin' (is not my domain)
Creating unix group: 'Account Operators'
Creating unix group: 'Guests'
Creating unix group: 'Server Operators'
Creating unix group: 'Users'
</screen>
	</para>

	</sect3>

	</sect2>

	<sect2>
	<title>NT4 Migration Using tdbsam Backend</title>

	<para>
	In this example, we change the domain name of the NT4 server from
	<constant>DRUGPREP</constant> to <constant>MEGANET</constant> prior to the use
	of the vampire (migration) tool. This migration process makes use of Linux system tools
	(like <command>useradd</command>) to add the accounts that are migrated into the 
	UNIX/Linux <filename>/etc/passwd</filename> and <filename>/etc/group</filename>
	databases. These entries must therefore be present, and correct options specified,
	in your &smb.conf; file, or else the migration does not work as it should.
	</para>

	<procedure>
	<title>Migration Steps Using tdbsam</title>

		<step><para>
		Prepare a Samba-3 server precisely per the instructions shown in <link linkend="Big500users"/>.
		Set the workgroup name to <constant>MEGANET</constant>.
		</para></step>

	  <step><para><indexterm>
		<primary>domain master</primary>
	      </indexterm><indexterm>
		<primary>BDC</primary>
	      </indexterm>
		Edit the &smb.conf; file to temporarily change the parameter 
		<smbconfoption name="domain master">No</smbconfoption> so
		the Samba server functions as a BDC for the purpose of migration.
                </para></step>

		<step><para>
		Start Samba as you have done previously.
		</para></step>

	  <step><para><indexterm>
		<primary>net</primary>
		<secondary>rpc</secondary>
		<tertiary>join</tertiary>
	      </indexterm>
		Join the NT4 Domain as a BDC, as shown here:
<screen>
&rootprompt; net rpc join -S oldnt4pdc -W MEGANET -UAdministrator%not24get
Joined domain MEGANET.
</screen>
		</para></step>

		<step><para><indexterm>
		<primary>net</primary>
		<secondary>rpc</secondary>
		<tertiary>vampire</tertiary>
	      </indexterm>
		You may vampire the accounts from the NT4 PDC by executing the command, as shown here:
<screen>
&rootprompt; 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 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'
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
</screen>
		</para></step>

	  <step><para><indexterm>
		<primary>pdbedit</primary>
	      </indexterm>
		At this point, we can validate our migration. Let's look at the accounts
		in the form in which they are seen in a smbpasswd file. This achieves that:
<screen>
&rootprompt; 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:
</screen>
		</para></step>

		<step><para><indexterm>
		<primary>pdbedit</primary>
	      </indexterm>
		An expanded view of a user account entry shows more of what was
		obtained from the NT4 PDC:
<screen>
sleeth:~ # pdbedit -Lv maryk
Unix username:        maryk
NT username:          maryk
Account Flags:        [UX         ]
User SID:             S-1-5-21-1988699175-926296742-1295600288-1003
Primary Group SID:    S-1-5-21-1988699175-926296742-1295600288-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
</screen>
		</para></step>

	  <step><para><indexterm>
		<primary>net</primary>
		<secondary>group</secondary>
	      </indexterm>
		The following command lists the long names of the groups that have been
		imported (vampired) from the NT4 PDC:
<screen>
&rootprompt; 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
</screen>
		Everything looks well and in order.
		</para></step>

	  <step><para><indexterm>
		<primary>domain master</primary>
	      </indexterm><indexterm>
		<primary>PDC</primary>
	      </indexterm>
		Edit the &smb.conf; file to  reset the parameter 
		<smbconfoption name="domain master">Yes</smbconfoption> so
		the Samba server functions as a PDC for the purpose of migration.
                </para></step>
	</procedure>
	</sect2>

	<sect2>
		<title>Key Points Learned</title>

		<para>
		Migration of an NT4 PDC database to a Samba-3 PDC is possible.
		</para>

		<itemizedlist>
			<listitem><para>
			An LDAP backend is a suitable vehicle for NT4 migrations.
			</para></listitem>

			<listitem><para>
			A tdbsam backend can be used to perform a migration.
			</para></listitem>

			<listitem><para>
			Multiple NT4 domains can be merged into a single Samba-3
			domain.
			</para></listitem>

			<listitem><para>
			The net Samba-3 domain most likely requires some
			administration and updating before going live.
			</para></listitem>
		</itemizedlist>

	</sect2>

</sect1>

<sect1>
	<title>Questions and Answers</title>

	<para>
	</para>

	<qandaset defaultlabel="chap08qa" type="number">
	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>clean database</primary>
	      </indexterm>
		Why must I start each migration with a clean database?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>merge</primary>
	      </indexterm>
		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 start with a clean database,
		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.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>Domain SID</primary>
	      </indexterm>
		Is it possible to set my domain SID to anything I like?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>auto-generated SID</primary>
	      </indexterm><indexterm>
		<primary>SID</primary>
	      </indexterm><indexterm>
		<primary>Domain SID</primary>
	      </indexterm>
		Yes, so long as the SID you create has the same structure as an autogenerated 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.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>/etc/passwd</primary>
	      </indexterm><indexterm>
		<primary>/etc/group</primary>
	      </indexterm><indexterm>
		<primary>tdbsam</primary>
	      </indexterm><indexterm>
		<primary>passdb backend</primary>
	      </indexterm><indexterm>
		<primary>accounts</primary>
		<secondary>user</secondary>
	      </indexterm><indexterm>
		<primary>accounts</primary>
		<secondary>group</secondary>
	      </indexterm><indexterm>
		<primary>accounts</primary>
		<secondary>Domain</secondary>
	      </indexterm>
		When using a tdbsam passdb backend, why must I have all domain user and group accounts
		in <filename>/etc/passwd</filename> and <filename>/etc/group</filename>?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>UID</primary>
	      </indexterm><indexterm>
		<primary>GID</primary>
	      </indexterm><indexterm>
		<primary>smbpasswd</primary>
	      </indexterm><indexterm>
		<primary>/etc/passwd</primary>
	      </indexterm><indexterm>
		<primary>Posix</primary>
	      </indexterm><indexterm>
		<primary>LDAP database</primary>
	      </indexterm>
		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. 
		</para>

		<para>
		When migrating a <filename>smbpasswd</filename> file to an LDAP backend, the
		UID of each account is taken together with the account information in the 
		<filename>/etc/passwd</filename>, and both sets of data are used to create the account
		entry in the LDAP database. 
		</para>

		<para>
		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.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>validate</primary>
	      </indexterm><indexterm>
		<primary>connectivity</primary>
	      </indexterm><indexterm>
		<primary>migration</primary>
	      </indexterm>
		Why did you validate connectivity before attempting migration?
		</para>

	</question>
	<answer>

		<para>
		Access validation before attempting to migrate NT4 domain accounts helps to pinpoint
		potential problems that may otherwise affect or impede account migration. I am always
		mindful of the 4 P's of migration: Planning Prevents Poor Performance.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		How would you merge 10 tdbsam-based domains into an LDAP database?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>risk</primary>
	      </indexterm><indexterm>
		<primary>dump</primary>
	      </indexterm><indexterm>
		<primary>tdbsam</primary>
	      </indexterm><indexterm>
		<primary>Samba Domain</primary>
	      </indexterm><indexterm>
		<primary>UID</primary>
	      </indexterm><indexterm>
		<primary>GID</primary>
	      </indexterm><indexterm>
		<primary>pdbedit</primary>
	      </indexterm><indexterm>
		<primary>transfer</primary>
	      </indexterm><indexterm>
		<primary>smbpasswd</primary>
	      </indexterm><indexterm>
		<primary>LDAP</primary>
	      </indexterm><indexterm>
		<primary>tool</primary>
	      </indexterm>
		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 <command>pdbedit</command> 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.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>machine accounts</primary>
	      </indexterm><indexterm>
		<primary>accounts</primary>
		<secondary>machine</secondary>
	      </indexterm>
		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?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>registry</primary>
	      </indexterm><indexterm>
		<primary>un-join</primary>
	      </indexterm><indexterm>
		<primary>rejoin</primary>
	      </indexterm><indexterm>
		<primary>tattooing</primary>
	      </indexterm>
		I would recommend not to migrate the machine account. 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
		unjoin the domain and then rejoin the newly renamed Samba-3 domain, you can be certain to avoid
		this tattooing effect.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>multiple group mappings</primary>
	      </indexterm>
		After merging multiple NT4 domains into a Samba-3 domain, I lost all multiple group mappings. Why?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>/etc/passwd</primary>
	      </indexterm><indexterm>
		<primary>/etc/group</primary>
	      </indexterm>
		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 <filename>/etc/passwd</filename>
		and <filename>/etc/group</filename> information also. That is where the multiple group information
		is most closely at your fingertips.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

		<para>
		How can I reset group membership after loading the account information into the LDAP database?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>SRVTOOLS.EXE</primary>
	      </indexterm>
		You can use the NT4 Domain User Manager that can be downloaded from the Microsoft Web site. The
		installation file is called <filename>SRVTOOLS.EXE</filename>.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>group names</primary>
	      </indexterm>
		What are the limits or constraints that apply to group names?
		</para>

	</question>
	<answer>

	    <para><indexterm>
		<primary>limit</primary>
	      </indexterm><indexterm>
		<primary>shadow-utils</primary>
	      </indexterm><indexterm>
		<primary>groupadd</primary>
	      </indexterm><indexterm>
		<primary>groupdel</primary>
	      </indexterm><indexterm>
		<primary>groupmod</primary>
	      </indexterm><indexterm>
		<primary>account names</primary>
	      </indexterm>
		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 lowercase characters, as well as spaces.
		Many UNIX system do not permit the use of uppercase characters, and some do not permit the
		space character either. A number of systems (i.e., Linux) work fine with both uppercase
		and space characters in group names, but the shadow-utils package that provides the group
		control functions (<command>groupadd</command>, <command>groupmod</command>, <command>groupdel</command>, 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 uppercase or space characters in group
		or user account names. You have to experiment with your system to find what its 
		peculiarities are.
		</para>

	</answer>
	</qandaentry>

	<qandaentry>
	<question>

	    <para><indexterm>
		<primary>vampire</primary>
	      </indexterm>
		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?
		</para>

	</question>
	<answer>

		<para>
		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 cannot 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.
		</para>

	    <para><indexterm>
		<primary>Migration speed</primary>
	      </indexterm>
		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 Gb Ethernet, I was able to migrate around 180 user accounts
		per minute. Migration would obviously go much faster if LDAP mirroring were turned off during the migration.
		</para>

	</answer>
	</qandaentry>

	</qandaset>

</sect1>

</chapter>