docs/Samba-Guide/Chap08-MigrateNT4Samba3.xml

   1 <?xml version="1.0" encoding="iso-8859-1"?>
   2 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
   3                 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
   4
   5   <!-- entities files to use -->
   6   <!ENTITY % global_entities SYSTEM '../entities/global.entities'>
   7   %global_entities;
   8
   9 ]>
  10
  11 <chapter id="migration">
  12   <title>Migrating NT4 Domain to Samba-3</title>
  13
  14         <para>
  15         Ever since Microsoft announced that they are discontinuing support for Windows
  16         NT4, Samba users started to ask for detailed instructions for how to migrate
  17         from NT4 to Samba-3. This chapter provides background information that should
  18         meet these needs.
  19         </para>
  20
  21         <para>
  22         One wonders how many NT4 systems will be left in service by the time you read this
  23         book though.
  24         </para>
  25
  26 <sect1>
  27         <title>Introduction</title>
  28
  29       <para><indexterm>
  30           <primary>migration</primary>
  31         </indexterm>
  32         Network administrators who want to migrate off a Windows NT4 environment know
  33         one thing with certainty. They feel that NT4 has been abandoned and they want
  34         to update. The desire to get off NT4 and to not adopt Windows 200x and Active
  35         Directory is driven by a mixture of concerns over complexity, cost, fear of
  36         failure, and much more.
  37         </para>
  38
  39       <para><indexterm>
  40           <primary>group policies</primary>
  41         </indexterm><indexterm>
  42           <primary>accounts</primary>
  43           <secondary>user</secondary>
  44         </indexterm><indexterm>
  45           <primary>accounts</primary>
  46           <secondary>group</secondary>
  47         </indexterm><indexterm>
  48           <primary>accounts</primary>
  49           <secondary>machine</secondary>
  50         </indexterm>
  51         The migration from NT4 to Samba-3 can involve a number of factors, including:
  52         migration of data to another server, migration of network environment controls
  53         such as group policies, and finally migration of the users, groups, and machine
  54         accounts.
  55         </para>
  56
  57       <para><indexterm>
  58           <primary>accounts</primary>
  59           <secondary>Domain</secondary>
  60         </indexterm>
  61         It should be pointed out now that it is possible to migrate some systems from
  62         Windows NT4 Domain environments to a Samba-3 Domain Environment. This is certainly
  63         not possible in every case. It is possible to just migrate the Domain accounts
  64         to Samba-3 and then to switch machines, but as a hands-off transition, this is more
  65         an exception than the rule. Most systems require some tweaking and adjusting
  66         following migration before an environment that is acceptable for immediate use
  67         is obtained.
  68         </para>
  69
  70         <sect2>
  71                 <title>Assignment Tasks</title>
  72
  73         <para><indexterm>
  74             <primary>LDAP</primary>
  75           </indexterm><indexterm>
  76             <primary>ldapsam</primary>
  77           </indexterm><indexterm>
  78             <primary>passdb backend</primary>
  79           </indexterm>
  80                 You are about to migrate an MS Windows NT4 Domain accounts database to
  81                 a Samba-3 server. The Samba-3 server is using a
  82                 <parameter>passdb backend</parameter> based on LDAP. The
  83                 <constant>ldapsam</constant> is ideal because an LDAP backend can be distributed
  84                 for use with BDCs &smbmdash; generally essential for larger networks.
  85                 </para>
  86
  87                 <para>
  88                 Your objective is to document the process of migrating user and group accounts
  89                 from several NT4 Domains into a single Samba-3 LDAP backend database.
  90                 </para>
  91
  92         </sect2>
  93 </sect1>
  94
  95 <sect1>
  96         <title>Dissection and Discussion</title>
  97
  98       <para><indexterm>
  99           <primary>snap-shot</primary>
 100         </indexterm><indexterm>
 101           <primary>NT4 registry</primary>
 102         </indexterm><indexterm>
 103           <primary>registry</primary>
 104           <secondary>keys</secondary>
 105           <tertiary>SAM</tertiary>
 106         </indexterm><indexterm>
 107           <primary>registry</primary>
 108           <secondary>keys</secondary>
 109           <tertiary>SECURITY</tertiary>
 110         </indexterm><indexterm>
 111           <primary>SAM</primary>
 112         </indexterm><indexterm>
 113           <primary>Security Account Manager</primary>
 114           <see>SAM</see>
 115         </indexterm>
 116         The migration process takes a snap-shot of information that is stored in the
 117         Windows NT4 registry based accounts database. That information resides in
 118         the Security Account Manager (SAM) portion of the NT4 Registry under keys called
 119         <constant>SAM</constant> and <constant>SECURITY</constant>.
 120         </para>
 121
 122       <warning><para><indexterm>
 123             <primary>crippled</primary>
 124           </indexterm><indexterm>
 125             <primary>inoperative</primary>
 126           </indexterm>
 127         The Windows NT4 registry keys called <constant>SAM</constant> and <constant>SECURITY</constant>
 128         are protected so that you cannot view the contents. If you change the security setting
 129         to reveal the contents under these hive keys, your Windows NT4 Domain is crippled. Do not
 130         do this unless you are willing to render your domain controller inoperative.
 131         </para></warning>
 132
 133       <para><indexterm>
 134           <primary>migration</primary>
 135           <secondary>objectives</secondary>
 136         </indexterm><indexterm>
 137           <primary>disruptive</primary>
 138         </indexterm>
 139         Before commencing an NT4 to Samba-3 migration, you should consider what your objectives are.
 140         While in some cases it is possible simply to migrate an NT4 domain to a single Samba-3 server,
 141         that may not be a good idea from an administration perspective. Since you are going through a
 142         certain amount of disruptive activity anyhow, why not take this as an opportunity to review
 143         the structure of the network, how Windows clients are controlled and how they
 144         interact with the network environment.
 145         </para>
 146
 147       <para><indexterm>
 148           <primary>network</primary>
 149           <secondary>logon scripts</secondary>
 150         </indexterm><indexterm>
 151           <primary>profiles share</primary>
 152         </indexterm><indexterm>
 153           <primary>security descriptors</primary>
 154         </indexterm>
 155         MS Windows NT4 was introduced some time around 1996. Many environments in which NT4 was deployed
 156         have done little to keep the NT4 server environment up-to-date with more recent Windows releases,
 157         particularly Windows XP Professional. The migration provides opportunity to revise and update
 158         roaming profile deployment as well as folder redirection. Given that you must port the
 159         greater network configuration of this from the old NT4 server to the new Samba-3 server, you
 160         also must validate the security descriptors in the profiles share as well as network logon
 161         scripts. Feedback from sites that are migrating to Samba-3 suggests that many are using this
 162         as a good time to update desktop systems also. In all, the extra effort should constitute no
 163         real disruption to users, rather with due diligence and care should make their network experience
 164         a much happier one.
 165         </para>
 166
 167         <sect2>
 168                 <title>Technical Issues</title>
 169
 170         <para><indexterm>
 171             <primary>strategic</primary>
 172           </indexterm>
 173                 Migration of an NT4 Domain user and group database to Samba-3 involves a certain strategic
 174                 element. Many sites have asked for instructions regarding merging of multiple different NT4
 175                 Domains into one Samba-3 LDAP database. It would appear that this is viewed as a significant
 176                 added value compared with the alternative of migration to Windows Server 200x and Active
 177                 Directory. The diagram in <link linkend="ch8-migration"/> illustrates the effect of migration
 178                 from a Windows NT4 Domain to a Samba Domain.
 179                 </para>
 180
 181                 <image id="ch8-migration">
 182                         <imagedescription>Schematic Explaining the <command>net rpc vampire</command> Process</imagedescription>
 183                         <imagefile scale="80">ch8-migration</imagefile>
 184                 </image>
 185
 186                 <para>
 187                 In any case, the migration process involves the following steps:
 188                 </para>
 189
 190                 <itemizedlist>
 191                         <listitem><para>
 192                         Prepare the target Samba-3 server. This involves configuring Samba-3 for
 193                         migration to either a tdbsam or an ldapsam backend.
 194                         </para></listitem>
 195
 196           <listitem><para><indexterm>
 197                 <primary>uppercase</primary>
 198               </indexterm><indexterm>
 199                 <primary>Posix</primary>
 200               </indexterm><indexterm>
 201                 <primary>lower-case</primary>
 202               </indexterm>
 203                         Clean up the source NT4 PDC. Delete all accounts that need not be migrated.
 204                         Delete all files that should not be migrated. Where possible, change NT Group
 205                         names so there are no spaces or uppercase characters. This is important if
 206                         the target UNIX host insists on Posix compliant all lower-case user and group
 207                         names.
 208                         </para></listitem>
 209
 210                         <listitem><para>
 211                         Step through the migration process.
 212                         </para></listitem>
 213
 214           <listitem><para><indexterm>
 215                 <primary>PDC</primary>
 216               </indexterm>
 217                         Remove the NT4 PDC from the network.
 218                         </para></listitem>
 219
 220                         <listitem><para>
 221                         Upgrade the Samba-3 server from a BDC to a PDC, and validate all account
 222                         information.
 223                         </para></listitem>
 224                 </itemizedlist>
 225
 226         <para><indexterm>
 227             <primary>merge</primary>
 228           </indexterm><indexterm>
 229             <primary>passdb.tdb</primary>
 230           </indexterm>
 231                 If you are wanting to merge multiple NT4 Domain account databases into one Samba Domain,
 232                 you must now dump the contents of the first migration and edit it as appropriate. Now clean
 233                 out (remove) the tdbsam backend file (<filename>passdb.tdb</filename>), or the LDAP database
 234                 files. You must start each migration with a new database into which you merge your NT4
 235                 domains.
 236                 </para>
 237
 238         <para><indexterm>
 239             <primary>dump</primary>
 240           </indexterm>
 241                 At this point, you are ready to perform the second migration following the same steps as
 242                 for the first. In other words, dump the database, edit it, and then you may merge the
 243                 dump for the first and second migrations.
 244                 </para>
 245
 246         <para><indexterm>
 247             <primary>LDAP</primary>
 248           </indexterm><indexterm>
 249             <primary>migrate</primary>
 250           </indexterm><indexterm>
 251             <primary>Domain SID</primary>
 252           </indexterm>
 253                 You must be careful. If you choose to migrate to an LDAP backend, your dump file
 254                 now contains the full account information, including the Domain SID. The Domain SID for each
 255                 of the two NT4 Domains will be different. You must choose one, and change the Domain
 256                 portion of the account SIDs so that all are the same.
 257                 </para>
 258
 259         <para><indexterm>
 260             <primary>passdb.tdb</primary>
 261           </indexterm><indexterm>
 262             <primary>/etc/passwd</primary>
 263           </indexterm><indexterm>
 264             <primary>merged</primary>
 265           </indexterm><indexterm>
 266             <primary>logon script</primary>
 267           </indexterm><indexterm>
 268             <primary>logon hours</primary>
 269           </indexterm><indexterm>
 270             <primary>logon machines</primary>
 271           </indexterm><indexterm>
 272             <primary>profile path</primary>
 273           </indexterm><indexterm>
 274             <primary>smbpasswd</primary>
 275           </indexterm><indexterm>
 276             <primary>tdbsam</primary>
 277           </indexterm><indexterm>
 278             <primary>LDAP backend</primary>
 279           </indexterm><indexterm>
 280             <primary>export</primary>
 281           </indexterm><indexterm>
 282             <primary>import</primary>
 283           </indexterm>
 284                 If you choose to use a tdbsam (<filename>passdb.tdb</filename>) backend file, your best choice
 285                 is to use <command>pdbedit</command> to export the contents of the tdbsam file into an
 286                 smbpasswd data file. This automatically strips out all Domain specific information,
 287                 such as logon hours, logon machines, logon script, profile path, as well as the Domain SID.
 288                 The resulting file can be easily merged with other migration attempts (each of which must start
 289                 with a clean file). It should also be noted that all users that end up in the merged smbpasswd
 290                 file must have an account in <filename>/etc/passwd</filename>. The resulting smbpasswd file
 291                 may be exported/imported into either a tdbsam (<filename>passdb.tdb</filename>), or else into
 292                 an LDAP backend.
 293                 </para>
 294
 295                 <image id="NT4DUM">
 296                         <imagedescription>View of Accounts in NT4 Domain User Manager</imagedescription>
 297                         <imagefile scale="50">UserMgrNT4</imagefile>
 298                 </image>
 299
 300         </sect2>
 301
 302
 303         <sect2>
 304                 <title>Political Issues</title>
 305
 306                 <para>
 307                 The merging of multiple Windows NT4 style Domains into a single LDAP-backend-based Samba-3
 308                 Domain may be seen by those who had power over them as a loss of prestige or a loss of
 309                 power. The imposition of a single Domain may even be seen as a threat. So in migrating and
 310                 merging account databases, be consciously aware of the political fall-out in which you
 311                 may find yourself entangled when key staff feel a loss of prestige.
 312                 </para>
 313
 314                 <para>
 315                 The best advice that can be given to those who set out to merge NT4 Domains into one single
 316                 Samba-3 Domain is to promote (sell) the action as one that reduces costs and delivers
 317                 greater network interoperability and manageability.
 318                 </para>
 319
 320         </sect2>
 321
 322 </sect1>
 323
 324 <sect1>
 325         <title>Implementation</title>
 326
 327         <para>
 328         You can present here the steps and example output for two NT4 to Samba-3 Domain migrations. The
 329         first uses an LDAP-based backend, and the second uses a tdbsam backend. In each case the
 330         scripts you specify in the &smb.conf; file for the <parameter>add user script</parameter>
 331         collection of parameters are used to effect the addition of accounts into the passdb backend.
 332         </para>
 333
 334         <sect2>
 335         <title>NT4 Migration Using LDAP Backend</title>
 336
 337         <para>
 338         In this instance, you migrate an NT4 PDC to an LDAP backend. The accounts you are about
 339         to migrate are shown in <link linkend="NT4DUM"/>. In this example you make use of the
 340         smbldap-tools scripts to add the accounts that are migrated into the ldapsam passdb backend.
 341         Four scripts are essential to the migration process. There are other scripts that will be required
 342         for daily management, but these are not critical to migration. The critical scripts are dependant
 343         on which passdb backend is being used. Refer to <link linkend="ch8-vampire"/> to see which scripts
 344         must be provided so that the migration process can complete.
 345         </para>
 346
 347         <para>
 348         Do verify that you have correctly specified in the &smb.conf; file the scripts, and arguments
 349         that should be passed to them, before attempting to perform the account migration.
 350         </para>
 351
 352         <table id="ch8-vampire">
 353                 <title>Samba &smb.conf; Scripts Essential to Migration</title>
 354                 <tgroup cols="3">
 355                         <colspec align="left"/>
 356                         <colspec align="center"/>
 357                         <colspec align="center"/>
 358                         <thead>
 359                                 <row>
 360                                         <entry>Entity</entry>
 361                                         <entry>ldapsam Script</entry>
 362                                         <entry>tdbsam Script</entry>
 363                                 </row>
 364                         </thead>
 365                         <tbody>
 366                                 <row>
 367                                         <entry>Add User Accounts</entry>
 368                                         <entry>smbldap-useradd.pl</entry>
 369                                         <entry>useradd</entry>
 370                                 </row>
 371                                 <row>
 372                                         <entry>Delete User Accounts</entry>
 373                                         <entry>smbldap-userdel.pl</entry>
 374                                         <entry>userdel</entry>
 375                                 </row>
 376                                 <row>
 377                                         <entry>Add Group Accounts</entry>
 378                                         <entry>smbldap-groupadd.pl</entry>
 379                                         <entry>groupadd</entry>
 380                                 </row>
 381                                 <row>
 382                                         <entry>Delete Group Accounts</entry>
 383                                         <entry>smbldap-groupdel.pl</entry>
 384                                         <entry>groupdel</entry>
 385                                 </row>
 386                                 <row>
 387                                         <entry>Add User to Group</entry>
 388                                         <entry>smbldap-groupmod.pl</entry>
 389                                         <entry>usermod (See Note)</entry>
 390                                 </row>
 391                                 <row>
 392                                         <entry>Add Machine Accounts</entry>
 393                                         <entry>smbldap-useradd.pl</entry>
 394                                         <entry>useradd</entry>
 395                                 </row>
 396                         </tbody>
 397                 </tgroup>
 398         </table>
 399
 400         <note><para>
 401         The UNIX/Linux <command>usermod</command> utility does not permit simple user addition to (or deletion
 402         of users from) groups. This is a feature provided by the smbldap-tools scripts. If you want this
 403         capability you will need to create your own tool to do this. Alternately, you can search the web
 404         to locate a utility called <command>groupmem</command> (by George Kraft) that provides this functionality.
 405         The <command>groupmem</command> utility was contributed to the shadow package but has not surfaced
 406         in the formal commands provided by Linux distributions (March 2004).
 407         </para></note>
 408
 409         <para>
 410         Before starting the migration, all dead accounts were removed using the User Manager for Domains.
 411         </para>
 412
 413         <procedure>
 414                 <step><para>
 415                 Install and configure the Samba-3 server precisely as shown in Chapter 6 for the server
 416                 called <constant>MASSIVE</constant>. The Domain name <constant>MEGANET</constant> must
 417                 match that of the NT4 Domain from which you are about to migrate. Do not execute any Samba
 418                 executables.
 419                 </para></step>
 420
 421           <step><para><indexterm>
 422                 <primary>domain master</primary>
 423               </indexterm><indexterm>
 424                 <primary>BDC</primary>
 425               </indexterm>
 426                 Edit the &smb.conf; file to temporarily change the parameter
 427                 <smbconfoption><name>domain master</name><value>No</value></smbconfoption> so
 428                 the Samba server functions as a BDC for the purpose of migration.
 429                 </para></step>
 430
 431           <step><para><indexterm>
 432                 <primary>preload.LDIF</primary>
 433               </indexterm>
 434                 Create a file called <filename>preload.LDIF</filename> as shown in <link linkend="ch8-LDIF"/>.
 435                 </para></step>
 436
 437           <step><para><indexterm>
 438                 <primary>slapadd</primary>
 439               </indexterm>
 440                 Preload the LDAP database so it is ready to receive the information from the NT4 PDC.
 441                 This pre-loads the LDAP directory with the top-level information, as well as the
 442                 top level containers for user, group, computer, and domain account data. Execute the
 443                 instruction shown here:
 444 <screen>
 445 &rootprompt; slapadd -v -l preload.LDIF
 446 added: "dc=abmas,dc=biz" (00000001)
 447 added: "cn=Manager,dc=abmas,dc=biz" (00000002)
 448 added: "ou=People,dc=abmas,dc=biz" (00000003)
 449 added: "ou=Computers,dc=abmas,dc=biz" (00000004)
 450 added: "ou=Groups,dc=abmas,dc=biz" (00000005)
 451 added: "ou=Idmap,dc=abmas,dc=biz" (00000006)
 452 added: "ou=Domains,dc=abmas,dc=biz" (00000007)
 453 </screen>
 454                 </para></step>
 455
 456                 <step><para>
 457                 Start the LDAP server.
 458                 </para></step>
 459
 460           <step><para><indexterm>
 461                 <primary>ping</primary>
 462               </indexterm>
 463                 Verify that the NT4 PDC can be reached:
 464 <screen>
 465 &rootprompt; ping nt4s
 466 PING nt4s.abmas.biz (192.168.2.250) 56(84) bytes of data.
 467 64 bytes from NT4S (192.168.2.250): icmp_seq=1 ttl=128 time=10.2 ms
 468 64 bytes from NT4S (192.168.2.250): icmp_seq=2 ttl=128 time=0.518 ms
 469 64 bytes from NT4S (192.168.2.250): icmp_seq=3 ttl=128 time=0.578 ms
 470
 471 --- nt4s.abmas.biz ping statistics ---
 472 3 packets transmitted, 3 received, 0% packet loss, time 2003ms
 473 rtt min/avg/max/mdev = 0.518/3.773/10.223/4.560 ms
 474 </screen>
 475                 It can. Great.
 476                 </para></step>
 477
 478           <step><para><indexterm>
 479                 <primary>smbclient</primary>
 480               </indexterm>
 481                 Validate that the resources on the NT4 PDC can be listed:
 482 <screen>
 483 &rootprompt; smbclient -L nt4s -UAdministrator%not24get
 484
 485         Sharename      Type      Comment
 486         ---------      ----      -------
 487         NETLOGON       Disk      Logon server share
 488         IPC$           IPC       Remote IPC
 489         UserProfiles   Disk      All Network User Profiles
 490
 491         Server               Comment
 492         ---------            -------
 493         NT4S
 494
 495         Workgroup            Master
 496         ---------            -------
 497         MEGANET              NT4S
 498 </screen>
 499                 This looks good.
 500                 </para></step>
 501
 502           <step><para><indexterm>
 503                 <primary>Domain SID</primary>
 504               </indexterm><indexterm>
 505                 <primary>net</primary>
 506                 <secondary>rpc</secondary>
 507                 <tertiary>getsid</tertiary>
 508               </indexterm>
 509                 At this point, it is necessary to fetch the Domain SID from the NT4 PDC and
 510                 apply that to the Samba-3 BDC (soon to be PDC):
 511 <screen>
 512 &rootprompt; net rpc getsid -S NT4S -W MEGANET
 513 Storing SID S-1-5-21-1988699175-926296742-1295600288 for
 514                               Domain MEGANET in secrets.tdb
 515 </screen>
 516                 Done.
 517                 </para></step>
 518
 519           <step><para><indexterm>
 520                 <primary>secrets.tdb</primary>
 521               </indexterm><indexterm>
 522                 <primary>validate</primary>
 523               </indexterm><indexterm>
 524                 <primary>tdbdump</primary>
 525               </indexterm>
 526                 At this point, you can validate that the information is correct in the
 527                 <filename>secrets.tdb</filename> file, as shown here:
 528 <screen>
 529 &rootprompt; tdbdump /etc/samba/secrets.tdb
 530 {
 531 key = "SECRETS/SID/MASSIVE"
 532 data = "\01\04\00\00\00\00\00\05\15\00\00\00'$\89v\A6*67\A0J9M\
 533 00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
 534 00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00"
 535 }
 536 {
 537 key = "SECRETS/LDAP_BIND_PW/cn=Manager,dc=abmas,dc=biz"
 538 data = "not24get\00"
 539 }
 540 </screen>
 541                 This has returned the information expected.
 542                 </para></step>
 543
 544 <note><para>
 545 The <command>tdbdump</command> utility is a utility that you can build from the Samba source
 546 code tree. Not all Linux binary distributions include this tool. If it is missing from your
 547 Linux distribution you will need to build this yourself, or else for-go its use.
 548 </para></note>
 549
 550           <step><para><indexterm>
 551                 <primary>net</primary>
 552                 <secondary>rpc</secondary>
 553                 <tertiary>join</tertiary>
 554               </indexterm>
 555                 We are ready to join the NT4 Domain as a BDC by executing the following:
 556 <screen>
 557 &rootprompt; net rpc join -S NT4S -W MEGANET -U Administrator%not24get
 558 Joined domain MEGANET.
 559 </screen>
 560                 Done.
 561                 </para></step>
 562
 563           <step><para><indexterm>
 564                 <primary>net</primary>
 565                 <secondary>rpc</secondary>
 566                 <tertiary>vampire</tertiary>
 567               </indexterm>
 568                 The Samba-3 BDC is now ready to receive the NT4 PDC accounts database, as shown here:
 569 <screen>
 570 &rootprompt; net rpc vampire -S NT4S
 571 Fetching DOMAIN database
 572 SAM_DELTA_DOMAIN_INFO not handled
 573 Creating account: Administrator
 574 Creating account: Guest
 575 Creating account: NT4S$
 576 Creating account: massive$
 577 Creating account: barryf
 578 Creating account: gdaison
 579 Creating account: atrikhoffer
 580 Creating account: hramsbotham
 581 Creating account: fsellerby
 582 Creating account: jrhapsody
 583 Group members of Domain Admins:
 584 Group members of Domain Users: NT4S$(primary),massive$(primary),
 585 Group members of Domain Guests: nobody(primary),
 586 Group members of rubberboot:
 587 Group members of engineers:
 588 Group members of accounting:
 589 Group members of catalyst:
 590 Group members of shipping:
 591 Group members of receiving:
 592 Group members of marketiod:
 593 Group members of sales:
 594 Fetching BUILTIN database
 595 SAM_DELTA_DOMAIN_INFO not handled
 596 </screen>
 597                 </para></step>
 598
 599           <step><para><indexterm>
 600                 <primary>domain master</primary>
 601               </indexterm><indexterm>
 602                 <primary>PDC</primary>
 603               </indexterm>
 604                 Edit the &smb.conf; file to  reset the parameter
 605                 <smbconfoption><name>domain master</name><value>Yes</value></smbconfoption> so that
 606                 the Samba server functions as a PDC for the purpose of migration.
 607                 </para></step>
 608         </procedure>
 609
 610 <example id ="ch8-LDIF">
 611 <title>LDAP Preload LDIF file &smbmdash; <filename>preload.LDIF</filename></title>
 612 <screen>
 613 dn: dc=abmas,dc=biz
 614 objectClass: dcObject
 615 objectClass: organization
 616 dc: abmas
 617 o: Abmas Demo
 618 description: POSIX and Samba LDAP Identity Database
 619 structuralObjectClass: organization
 620
 621 dn: cn=Manager,dc=abmas,dc=biz
 622 objectClass: organizationalRole
 623 cn: Manager
 624 description: Directory Manager
 625 structuralObjectClass: organizationalRole
 626
 627 dn: ou=People,dc=abmas,dc=biz
 628 objectClass: top
 629 objectClass: organizationalUnit
 630 ou: People
 631 structuralObjectClass: organizationalUnit
 632
 633 dn: ou=Groups,dc=abmas,dc=biz
 634 objectClass: top
 635 objectClass: organizationalUnit
 636 ou: Groups
 637 structuralObjectClass: organizationalUnit
 638
 639 dn: ou=Idmap,dc=abmas,dc=biz
 640 objectClass: top
 641 objectClass: organizationalUnit
 642 ou: Idmap
 643 structuralObjectClass: organizationalUnit
 644
 645 dn: ou=Domains,dc=abmas,dc=biz
 646 objectClass: organizationalUnit
 647 ou: Domains
 648 structuralObjectClass: organizationalUnit
 649 </screen>
 650 </example>
 651
 652         </sect2>
 653
 654         <sect2>
 655         <title>NT4 Migration Using tdbsam Backend</title>
 656
 657         <para>
 658         In this example, you have chosen to change the Domain name of the NT4 server from
 659         <constant>DRUGPREP</constant> to <constant>MEGANET</constant> prior to the use
 660         of the vampire (migration) tool. This migration process makes use of Linux system tools
 661         (like <command>useradd</command>) to add the accounts that are migrated into the
 662         UNIX/Linux <filename>/etc/passwd</filename>, and <filename>/etc/group</filename>
 663         databases. These entries must therefore be present, and correct options specified,
 664         in your &smb.conf; file or else the migration does not work as it should.
 665         </para>
 666
 667         <procedure>
 668                 <step><para>
 669                 Prepare a Samba-3 server precisely per the instructions shown in Chapter 5.
 670                 Set the workgroup name to <constant>MEGANET</constant>.
 671                 </para></step>
 672
 673           <step><para><indexterm>
 674                 <primary>domain master</primary>
 675               </indexterm><indexterm>
 676                 <primary>BDC</primary>
 677               </indexterm>
 678                 Edit the &smb.conf; file to temporarily change the parameter
 679                 <smbconfoption><name>domain master</name><value>No</value></smbconfoption> so
 680                 the Samba server functions as a BDC for the purpose of migration.
 681                 </para></step>
 682
 683                 <step><para>
 684                 Start Samba as you have done previously.
 685                 </para></step>
 686
 687           <step><para><indexterm>
 688                 <primary>net</primary>
 689                 <secondary>rpc</secondary>
 690                 <tertiary>join</tertiary>
 691               </indexterm>
 692                 Join the NT4 Domain as a BDC, as shown here:
 693 <screen>
 694 &rootprompt; net rpc join -S oldnt4pdc -W MEGANET -UAdministrator%not24get
 695 Joined domain MEGANET.
 696 </screen>
 697                 </para></step>
 698
 699                 <step><para><indexterm>
 700                 <primary>net</primary>
 701                 <secondary>rpc</secondary>
 702                 <tertiary>vampire</tertiary>
 703               </indexterm>
 704                 You may vampire the accounts from the NT4 PDC by executing the command, as shown here:
 705 <screen>
 706 &rootprompt; net rpc vampire -S oldnt4pdc -U Administrator%not24get
 707 Fetching DOMAIN database
 708 SAM_DELTA_DOMAIN_INFO not handled
 709 Creating unix group: 'Domain Admins'
 710 Creating unix group: 'Domain Users'
 711 Creating unix group: 'Domain Guests'
 712 Creating unix group: 'Engineers'
 713 Creating unix group: 'Marketoids'
 714 Creating account: Administrator
 715 Creating account: Guest
 716 Creating account: oldnt4pdc$
 717 Creating account: jacko
 718 Creating account: maryk
 719 Creating account: bridge
 720 Creating account: sharpec
 721 Creating account: jimbo
 722 Creating account: dhenwick
 723 Creating account: dork
 724 Creating account: blue
 725 Creating account: billw
 726 Creating account: massive$
 727 Group members of Engineers: Administrator,
 728                  sharpec(primary),bridge,billw(primary),dhenwick
 729 Group members of Marketoids: Administrator,jacko(primary),
 730                 maryk(primary),jimbo,blue(primary),dork(primary)
 731 Creating unix group: 'Gnomes'
 732 Fetching BUILTIN database
 733 SAM_DELTA_DOMAIN_INFO not handled
 734 Creating unix group: 'Account Operators'
 735 Creating unix group: 'Administrators'
 736 Creating unix group: 'Backup Operators'
 737 Creating unix group: 'Guests'
 738 Creating unix group: 'Print Operators'
 739 Creating unix group: 'Replicator'
 740 Creating unix group: 'Server Operators'
 741 Creating unix group: 'Users'
 742 </screen>
 743                 </para></step>
 744
 745           <step><para><indexterm>
 746                 <primary>pdbedit</primary>
 747               </indexterm>
 748                 At this point, we can validate our migration. Let's look at the accounts
 749                 in the form as they would be seen in a smbpasswd file. This achieves that:
 750 <screen>
 751 &rootprompt; pdbedit -Lw
 752 Administrator:505:84B0D8E14D158FF8417EAF50CFAC29C3:
 753      AF6DD3FD4E2EA8BDE1695A3F05EFBF52:[UX         ]:LCT-3DF7AA9F:
 754 jimbo:512:6E9A2A51F64A1BD5C187B8085FE1D9DF:
 755      CDF7E305E639966E489A0CEFB95EE5E0:[UX         ]:LCT-3E9362BC:
 756 sharpec:511:E4301A7CD8FDD1EC6BBF9BC19CDF8151:
 757      7000255938831D5B948C95C1931534C5:[UX         ]:LCT-3E8B42C4:
 758 dhenwick:513:DCD8886141E3F892AAD3B435B51404EE:
 759      2DB36465949CB938DD98C312EFDC2639:[UX         ]:LCT-3E939F41:
 760 bridge:510:3FE6873A43101B46417EAF50CFAC29C3:
 761      891741F481AF111B4CAA09A94016BD01:[UX         ]:LCT-3E8B4291:
 762 blue:515:256D41D2559BB3D2AAD3B435B51404EE:
 763      9CCADDA4F7D281DD0FAD321478C6F971:[UX         ]:LCT-3E939FDC:
 764 diamond$:517:6C8E7B64EDCDBC4218B6345447A4454B:
 765      3323AC63C666CFAACB60C13F65D54E9A:[S          ]:LCT-00000000:
 766 oldnt4pdc$:507:3E39430CDCABB5B09ED320D0448AE568:
 767      95DBAF885854A919C7C7E671060478B9:[S          ]:LCT-3DF7AA9F:
 768 Guest:506:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
 769      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:[DUX        ]:LCT-3E93A008:
 770 billw:516:85380CA7C21B6EBE168C8150662AF11B:
 771      5D7478508293709937E55FB5FBA14C17:[UX         ]:LCT-3FED7CA1:
 772 dork:514:78C70DDEC35A35B5AAD3B435B51404EE:
 773      0AD886E015AC595EC0AF40E6C9689E1A:[UX         ]:LCT-3E939F9A:
 774 jacko:508:BC472F3BF9A0A5F63832C92FC614B7D1:
 775      0C6822AAF85E86600A40DC73E40D06D5:[UX         ]:LCT-3E8B4242:
 776 maryk:509:3636AB7E12EBE79AB79AE2610DD89D4C:
 777      CF271B744F7A55AFDA277FF88D80C527:[UX         ]:LCT-3E8B4270:
 778 </screen>
 779                 </para></step>
 780
 781                 <step><para><indexterm>
 782                 <primary>pdbedit</primary>
 783               </indexterm>
 784                 An expanded view of a user account entry shows more of what was
 785                 obtained from the NT4 PDC:
 786 <screen>
 787 sleeth:~ # pdbedit -Lv maryk
 788 Unix username:        maryk
 789 NT username:          maryk
 790 Account Flags:        [UX         ]
 791 User SID:             S-1-5-21-5672968813-926296742-3245673225-1003
 792 Primary Group SID:    S-1-5-21-5672968813-926296742-3245673225-1007
 793 Full Name:            Mary Kathleen
 794 Home Directory:       \\diamond\maryk
 795 HomeDir Drive:        X:
 796 Logon Script:         scripts\logon.bat
 797 Profile Path:         \\diamond\profiles\maryk
 798 Domain:               MEGANET
 799 Account desc:         Peace Maker
 800 Workstations:
 801 Munged dial:
 802 Logon time:           0
 803 Logoff time:          Mon, 18 Jan 2038 20:14:07 GMT
 804 Kickoff time:         Mon, 18 Jan 2038 20:14:07 GMT
 805 Password last set:    Wed, 02 Apr 2003 13:05:04 GMT
 806 Password can change:  0
 807 Password must change: Mon, 18 Jan 2038 20:14:07 GMT
 808 </screen>
 809                 </para></step>
 810
 811           <step><para><indexterm>
 812                 <primary>net</primary>
 813                 <secondary>group</secondary>
 814               </indexterm>
 815                 And this command lists the long names of the groups that have been
 816                 imported (vampired) from the NT4 PDC:
 817 <screen>
 818 &rootprompt; net group -l -Uroot%not24get -Smassive
 819
 820 Group name            Comment
 821 -----------------------------
 822 Engineers             Snake Oil Engineers
 823 Marketoids            Untrustworthy Hype Vendors
 824 Gnomes                Plain Vanilla Garden Gnomes
 825 Replicator            Supports file replication in a domain
 826 Guests                Users granted guest access to the computer/domain
 827 Administrators        Members can fully administer the computer/domain
 828 Users                 Ordinary users
 829 </screen>
 830                 Everything looks well and in order.
 831                 </para></step>
 832
 833           <step><para><indexterm>
 834                 <primary>domain master</primary>
 835               </indexterm><indexterm>
 836                 <primary>PDC</primary>
 837               </indexterm>
 838                 Edit the &smb.conf; file to  reset the parameter
 839                 <smbconfoption><name>domain master</name><value>Yes</value></smbconfoption> so
 840                 the Samba server functions as a PDC for the purpose of migration.
 841                 </para></step>
 842         </procedure>
 843         </sect2>
 844
 845         <sect2>
 846                 <title>Key Points Learned</title>
 847
 848                 <para>
 849                 Migration of an NT4 PDC database to a Samba-3 PDC is possible.
 850                 </para>
 851
 852                 <itemizedlist>
 853                         <listitem><para>
 854                         An LDAP backend is a suitable vehicle for NT4 migrations.
 855                         </para></listitem>
 856
 857                         <listitem><para>
 858                         A tdbsam backend can be used to perform a migration.
 859                         </para></listitem>
 860
 861                         <listitem><para>
 862                         Multiple NT4 Domains can be merged into a single Samba-3
 863                         Domain.
 864                         </para></listitem>
 865
 866                         <listitem><para>
 867                         The net Samba-3 Domain most likely requires some
 868                         administration and updating before going live.
 869                         </para></listitem>
 870                 </itemizedlist>
 871
 872         </sect2>
 873
 874 </sect1>
 875
 876 <sect1>
 877         <title>Questions and Answers</title>
 878
 879         <para>
 880         </para>
 881
 882         <qandaset defaultlabel="chap08qa" type="number">
 883         <qandaentry>
 884         <question>
 885
 886             <para><indexterm>
 887                 <primary>clean database</primary>
 888               </indexterm>
 889                 Why must I start each migration with a clean database?
 890                 </para>
 891
 892         </question>
 893         <answer>
 894
 895             <para><indexterm>
 896                 <primary>merge</primary>
 897               </indexterm>
 898                 This is a recommendation that permits the data from each NT4 Domain to
 899                 be kept separate until you are ready to merge them. Also, if you do not do this,
 900                 you may find errors due to users or groups from multiple Domains having the
 901                 same name, but different SIDs. It is better to permit each migration to complete
 902                 without undue errors and then to handle the merging of vampired data under
 903                 proper supervision.
 904                 </para>
 905
 906         </answer>
 907         </qandaentry>
 908
 909         <qandaentry>
 910         <question>
 911
 912             <para><indexterm>
 913                 <primary>Domain SID</primary>
 914               </indexterm>
 915                 Is it possible to set my Domain SID to anything I like?
 916                 </para>
 917
 918         </question>
 919         <answer>
 920
 921             <para><indexterm>
 922                 <primary>auto-generated SID</primary>
 923               </indexterm><indexterm>
 924                 <primary>SID</primary>
 925               </indexterm><indexterm>
 926                 <primary>Domain SID</primary>
 927               </indexterm>
 928                 Yes, so long as the SID you create has the same structure as an auto-generated SID.
 929                 The typical SID looks like this: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX, where
 930                 the XXXXXXXXXX can be any number with from 6 to 10 digits. On the other hand, why
 931                 would you really want to create your own SID? I cannot think of a good reason.
 932                 You may want to set the SID to one that is already in use somewhere on your network,
 933                 but that is a little different from straight out creating your own Domain SID.
 934                 </para>
 935
 936         </answer>
 937         </qandaentry>
 938
 939         <qandaentry>
 940         <question>
 941
 942             <para><indexterm>
 943                 <primary>/etc/passwd</primary>
 944               </indexterm><indexterm>
 945                 <primary>/etc/group</primary>
 946               </indexterm><indexterm>
 947                 <primary>tdbsam</primary>
 948               </indexterm><indexterm>
 949                 <primary>passdb backend</primary>
 950               </indexterm><indexterm>
 951                 <primary>accounts</primary>
 952                 <secondary>user</secondary>
 953               </indexterm><indexterm>
 954                 <primary>accounts</primary>
 955                 <secondary>group</secondary>
 956               </indexterm><indexterm>
 957                 <primary>accounts</primary>
 958                 <secondary>Domain</secondary>
 959               </indexterm>
 960                 When using a tdbsam passdb backend, why must I have all Domain user and group accounts
 961                 in <filename>/etc/passwd</filename> and <filename>/etc/group</filename>?
 962                 </para>
 963
 964         </question>
 965         <answer>
 966
 967             <para><indexterm>
 968                 <primary>UID</primary>
 969               </indexterm><indexterm>
 970                 <primary>GID</primary>
 971               </indexterm><indexterm>
 972                 <primary>smbpasswd</primary>
 973               </indexterm><indexterm>
 974                 <primary>/etc/passwd</primary>
 975               </indexterm><indexterm>
 976                 <primary>Posix</primary>
 977               </indexterm><indexterm>
 978                 <primary>LDAP database</primary>
 979               </indexterm>
 980                 Samba-3 must be able to tie all user and group account SIDs to a UNIX UID or GID. Samba
 981                 does not fabricate the UNIX IDs from thin air, but rather requires them to be located
 982                 in a suitable place.
 983                 </para>
 984
 985                 <para>
 986                 When migrating a <filename>smbpasswd</filename> file to an LDAP backend, the
 987                 UID of each account is taken together with the account information in the
 988                 <filename>/etc/passwd</filename> and both sets of data are used to create the account
 989                 entrt in the LDAP database.
 990                 </para>
 991
 992                 <para>
 993                 If you elect to create the Posix account also, the entire UNIX account is copied to the
 994                 LDAP backend. The same occurs with NT groups and UNIX groups. At the conclusion of
 995                 migration to the LDAP database, the accounts may be removed from the UNIX database files.
 996                 In short then, all UNIX and Windows networking accounts, both in tdbsam as well as in
 997                 LDAP, require UIDs/GIDs.
 998                 </para>
 999
1000         </answer>
1001         </qandaentry>
1002
1003         <qandaentry>
1004         <question>
1005
1006             <para><indexterm>
1007                 <primary>validate</primary>
1008               </indexterm><indexterm>
1009                 <primary>connectivity</primary>
1010               </indexterm><indexterm>
1011                 <primary>migration</primary>
1012               </indexterm>
1013                 Why did you validate connectivity before attempting migration?
1014                 </para>
1015
1016         </question>
1017         <answer>
1018
1019                 <para>
1020                 Access validation before attempting to migrate NT4 Domain accounts helps to pin-point
1021                 potential problems that may otherwise affect or impede account migration. I am always
1022                 mindful of the 4P's of migration &smbmdash; Planning Prevents Poor Performance.
1023                 </para>
1024
1025         </answer>
1026         </qandaentry>
1027
1028         <qandaentry>
1029         <question>
1030
1031                 <para>
1032                 How would you merge 10 tdbsam-based domains into an LDAP database?
1033                 </para>
1034
1035         </question>
1036         <answer>
1037
1038             <para><indexterm>
1039                 <primary>risk</primary>
1040               </indexterm><indexterm>
1041                 <primary>dump</primary>
1042               </indexterm><indexterm>
1043                 <primary>tdbsam</primary>
1044               </indexterm><indexterm>
1045                 <primary>Samba Domain</primary>
1046               </indexterm><indexterm>
1047                 <primary>UID</primary>
1048               </indexterm><indexterm>
1049                 <primary>GID</primary>
1050               </indexterm><indexterm>
1051                 <primary>pdbedit</primary>
1052               </indexterm><indexterm>
1053                 <primary>transfer</primary>
1054               </indexterm><indexterm>
1055                 <primary>smbpasswd</primary>
1056               </indexterm><indexterm>
1057                 <primary>LDAP</primary>
1058               </indexterm><indexterm>
1059                 <primary>tool</primary>
1060               </indexterm>
1061                 If you have 10 tdbsam Samba Domains, there is considerable risk that there are a number of
1062                 accounts that have the same UNIX identifier (UID/GID). This means that you almost
1063                 certainly have to edit a lot of data. It would be easiest to dump each database in smbpasswd
1064                 file format and then manually edit all records to ensure that each has a unique UID. Each
1065                 file can then be imported a number of ways. You can use the <command>pdbedit</command> tool,
1066                 to affect a transfer from the smbpasswd file to LDAP, or you can migrate them en masse to
1067                 tdbsam and then to LDAP. The final choice is yours. Just remember to verify all accounts that
1068                 you have migrated before handing over access to a user. After all, too many users with a bad
1069                 migration experience may threaten your career.
1070                 </para>
1071
1072         </answer>
1073         </qandaentry>
1074
1075         <qandaentry>
1076         <question>
1077
1078             <para><indexterm>
1079                 <primary>machine accounts</primary>
1080               </indexterm><indexterm>
1081                 <primary>accounts</primary>
1082                 <secondary>machine</secondary>
1083               </indexterm>
1084                 I want to change my Domain name after I migrate all accounts from an NT4 Domain to a
1085                 Samba-3 Domain.  Does it make any sense to migrate the machine accounts in that case?
1086                 </para>
1087
1088         </question>
1089         <answer>
1090
1091             <para><indexterm>
1092                 <primary>registry</primary>
1093               </indexterm><indexterm>
1094                 <primary>un-join</primary>
1095               </indexterm><indexterm>
1096                 <primary>rejoin</primary>
1097               </indexterm><indexterm>
1098                 <primary>tattooing</primary>
1099               </indexterm>
1100                 I would recommend not. The machine accounts should still work, but there are registry entries
1101                 on each Windows NT4 and upward client that have a tattoo of the old domain name. If you
1102                 un-join the domain and then rejoin the newly renamed Samba-3 Domain, you can be certain to avoid
1103                 this tattooing effect.
1104                 </para>
1105
1106         </answer>
1107         </qandaentry>
1108
1109         <qandaentry>
1110         <question>
1111
1112             <para><indexterm>
1113                 <primary>multiple group mappings</primary>
1114               </indexterm>
1115                 After merging multiple NT4 Domains into a Samba-3 Domain, I lost all multiple group mappings. Why?
1116                 </para>
1117
1118         </question>
1119         <answer>
1120
1121             <para><indexterm>
1122                 <primary>/etc/passwd</primary>
1123               </indexterm><indexterm>
1124                 <primary>/etc/group</primary>
1125               </indexterm>
1126                 Samba-3 currently does not implement multiple group membership internally. If you use the Windows
1127                 NT4 Domain User Manager to manage accounts and you have an LDAP backend, the multiple group
1128                 membership is stored in the Posix groups area. If you use either tdbsam or smbpasswd backend,
1129                 then multiple group membership is handled through the UNIX groups file. When you dump the user
1130                 accounts no group account information is provided. When you edit (change) UIDs and GIDs in each
1131                 file to which you migrated the NT4 Domain data, do not forget to edit the UNIX <filename>/etc/passwd</filename>
1132                 and <filename>/etc/group</filename> information also. That is where the multiple group information
1133                 is most closely at your fingertips.
1134                 </para>
1135
1136         </answer>
1137         </qandaentry>
1138
1139         <qandaentry>
1140         <question>
1141
1142                 <para>
1143                 How can I reset group membership after loading the account information into the LDAP database?
1144                 </para>
1145
1146         </question>
1147         <answer>
1148
1149             <para><indexterm>
1150                 <primary>SRVTOOLS.EXE</primary>
1151               </indexterm>
1152                 You can use the NT4 Domain User Manager that can be downloaded from the Microsoft Web site. The
1153                 installation file is called <filename>SRVTOOLS.EXE</filename>.
1154                 </para>
1155
1156         </answer>
1157         </qandaentry>
1158
1159         <qandaentry>
1160         <question>
1161
1162             <para><indexterm>
1163                 <primary>group names</primary>
1164               </indexterm>
1165                 What are the limits or constraints that apply to group names?
1166                 </para>
1167
1168         </question>
1169         <answer>
1170
1171             <para><indexterm>
1172                 <primary>limit</primary>
1173               </indexterm><indexterm>
1174                 <primary>shadow-utils</primary>
1175               </indexterm><indexterm>
1176                 <primary>groupadd</primary>
1177               </indexterm><indexterm>
1178                 <primary>groupdel</primary>
1179               </indexterm><indexterm>
1180                 <primary>groupmod</primary>
1181               </indexterm><indexterm>
1182                 <primary>account names</primary>
1183               </indexterm>
1184                 A Windows 200x group name can be up to 254 characters long, while in Windows NT4 the group
1185                 name is limited to 20 characters. Most UNIX systems limit this to 32 characters. Windows
1186                 groups can contain upper- and lower-case characters, as well as spaces.
1187                 Many UNIX system do not permit the use of upper-case characters, and some do not permit the
1188                 space character either. A number of systems (i.e., Linux) work fine with both upper-case
1189                 and space characters in group names, but the shadow-utils package that provides the group
1190                 control functions (<command>groupadd, groupmod, groupdel</command>, and so on) do not permit them.
1191                 Also, a number of UNIX systems management tools enforce their own particular interpretation
1192                 of the Posix standards, and likewise do not permit upper-case or space characters in group
1193                 or user account names. You have to experiment with your system to find what its
1194                 peculiarities are.
1195                 </para>
1196
1197         </answer>
1198         </qandaentry>
1199
1200         <qandaentry>
1201         <question>
1202
1203             <para><indexterm>
1204                 <primary>vampire</primary>
1205               </indexterm>
1206                 My Windows NT4 PDC has 323,000 user accounts. How long will it take to migrate them to a Samba-3
1207                 LDAP backend system using the vampire process?
1208                 </para>
1209
1210         </question>
1211         <answer>
1212
1213                 <para>
1214                 UNIX UIDs and GIDs on most UNIX systems use an unsigned short or an unsigned integer. Recent Linux
1215                 kernels support at least a much larger number. On systems that have a 16-bit constraint on UID/GIDs,
1216                 you would not be able to migrate 323,000 accounts because this number can not fit into a 16-bit unsigned
1217                 integer. UNIX/Linux systems that have a 32-bit UID/GID can easily handle this number of accounts.
1218                 Please check this carefully before you attempt to effect a migration using the vampire process.
1219                 </para>
1220
1221             <para><indexterm>
1222                 <primary>Migration speed</primary>
1223               </indexterm>
1224                 Migration speed depends much on the processor speed, the network speed, disk I/O capability, and
1225                 LDAP update overheads. On a dual processor AMD MP1600+ with 1 GB memory, that was mirroring LDAP
1226                 to a second identical system over 1 gigabit ethernet, I was able to migrate around 180 user accounts
1227                 per minute. Migration would obviously go much faster if LDAP mirroring is turned off during the migration.
1228                 </para>
1229
1230         </answer>
1231         </qandaentry>
1232
1233         </qandaset>
1234
1235 </sect1>
1236
1237 </chapter>
1238