diff options
Diffstat (limited to 'docs-xml/Samba3-ByExample/SBE-MigrateNT4Samba3.xml')
| -rw-r--r-- | docs-xml/Samba3-ByExample/SBE-MigrateNT4Samba3.xml | 1787 |
1 files changed, 1787 insertions, 0 deletions
diff --git a/docs-xml/Samba3-ByExample/SBE-MigrateNT4Samba3.xml b/docs-xml/Samba3-ByExample/SBE-MigrateNT4Samba3.xml new file mode 100644 index 0000000000..f7ab1d1c1c --- /dev/null +++ b/docs-xml/Samba3-ByExample/SBE-MigrateNT4Samba3.xml @@ -0,0 +1,1787 @@ +<?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] > +smbldap Config file Location (global parameters) + [/etc/smbldap-tools/smbldap.conf] > +smbldap Config file Location (bind parameters) + [/etc/smbldap-tools/smbldap_bind.conf] > +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +Let's start configuring the smbldap-tools scripts ... + +. workgroup name: name of the domain Samba act as a PDC + workgroup name [DAMNATION] > +. netbios name: netbios name of the samba controller + netbios name [MERLIN] > +. logon drive: local path to which the home directory + will be connected (for NT Workstations). Ex: 'H:' + logon drive [X:] > 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] > \\%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] > \\%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] > scripts\logon.cmd + default password validation time (time in days) [45] > 180 +. ldap suffix [dc=terpstra-world,dc=org] > +. ldap group suffix [ou=Groups] > +. ldap user suffix [ou=People] > +. ldap machine suffix [ou=People] > +. Idmap suffix [ou=Idmap] > +. 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 [] > 127.0.0.1 +. ldap master port [389] > +. ldap master bind dn [cn=Manager,dc=terpstra-world,dc=org] > +. ldap master bind password [] > +. ldap slave server: IP address or DNS name of the slave ldap server: + can also be the master one + ldap slave server [] > 127.0.0.1 +. ldap slave port [389] > +. ldap slave bind dn [cn=Manager,dc=terpstra-world,dc=org] > +. ldap slave bind password [] > +. ldap tls support (1/0) [0] > +. SID for domain DAMNATION: SID of the domain + (can be obtained with 'net getlocalsid MERLIN') + SID for domain DAMNATION [] + > S-1-5-21-1385457007-882775198-1210191635 +. unix password encryption: encryption used for unix passwords +unix password encryption (CRYPT, MD5, SMD5, SSHA, SHA) [SSHA] > MD5 +. default user gidNumber [513] > +. default computer gidNumber [515] > +. default login shell [/bin/bash] > +. default domain name to append to mail address [] > + terpstra-world.org +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +backup old configuration files: + /etc/smbldap-tools/smbldap.conf-> + /etc/smbldap-tools/smbldap.conf.old + /etc/smbldap-tools/smbldap_bind.conf-> + /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) + -> Domain Admins +Domain Users (S-1-5-21-1385457007-882775198-1210191635-513) + -> Domain Users +Domain Guests (S-1-5-21-1385457007-882775198-1210191635-514) + -> Domain Guests +Domain Computers (S-1-5-21-1385457007-882775198-1210191635-515) + -> Domain Computers +Administrators (S-1-5-32-544) -> Administrators +Print Operators (S-1-5-32-550) -> Print Operators +Backup Operators (S-1-5-32-551) -> 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 > /tmp/vampire.log 2>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) + -> Domain Admins +Domain Users (S-1-5-21-1385457007-882775198-1210191635-513) + -> Domain Users +Domain Guests (S-1-5-21-1385457007-882775198-1210191635-514) + -> Domain Guests +Domain Computers (S-1-5-21-1385457007-882775198-1210191635-515) + -> Domain Computers +Administrators (S-1-5-32-544) -> Administrators +Print Operators (S-1-5-32-550) -> Print Operators +Backup Operators (S-1-5-32-551) -> Backup Operators +Replicator (S-1-5-32-552) -> Replicators +Engineers (S-1-5-21-1385457007-882775198-1210191635-1020) -> Engineers +Marketoids (S-1-5-21-1385457007-882775198-1210191635-1022) -> Marketoids +Gnomes (S-1-5-21-1385457007-882775198-1210191635-1023) -> Gnomes +Catalyst (S-1-5-21-1385457007-882775198-1210191635-1024) -> Catalyst +Recieving (S-1-5-21-1385457007-882775198-1210191635-1025) -> Recieving +Rubberboot (S-1-5-21-1385457007-882775198-1210191635-1026) -> Rubberboot +Sales (S-1-5-21-1385457007-882775198-1210191635-1027) -> Sales +Accounting (S-1-5-21-1385457007-882775198-1210191635-1028) -> Accounting +Shipping (S-1-5-21-1385457007-882775198-1210191635-1029) -> Shipping +Account Operators (S-1-5-32-548) -> Account Operators +Guests (S-1-5-32-546) -> Guests +Server Operators (S-1-5-32-549) -> Server Operators +Users (S-1-5-32-545) -> 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> + |