docs/docbook/projdoc/NT4Migration.sgml

   1 <chapter id="NT4Migration">
   2 <chapterinfo>
   3         &author.jht;
   4         <pubdate>April 3, 2003</pubdate>
   5 </chapterinfo>
   6
   7 <title>Migration from NT4 PDC to Samba-3 PDC</title>
   8
   9 <para>
  10 This is a rough guide to assist those wishing to migrate from NT4 domain control to
  11 Samba-3 based domain control.
  12 </para>
  13
  14 <sect1>
  15 <title>Planning and Getting Started</title>
  16
  17 <para>
  18 In the IT world there is often a saying that all problems are encountered because of
  19 poor planning. The corrollary to this saying is that not all problems can be anticpated
  20 and planned for. Then again, good planning will anticpate most show stopper type situations.
  21 </para>
  22
  23 <para>
  24 Those wishing to migrate from MS Windows NT4 domain control to a Samba-3 domain control
  25 environment would do well to develop a detailed migration plan. So here are a few pointers to
  26 help migration get under way.
  27 </para>
  28
  29 <sect2>
  30 <title>Objectives</title>
  31
  32 <para>
  33 The key objective for most organisations will be to make the migration from MS Windows NT4
  34 to Samba-3 domain control as painless as possible. One of the challenges you may experience
  35 in your migration process may well be one of convincing management that the new environment
  36 should remain in place. Many who have introduced open source technologies have experienced
  37 pressure to return to a Microsoft based platform solution at the first sign of trouble.
  38 </para>
  39
  40 <para>
  41 It is strongly advised that before attempting a migration to a Samba-3 controlled network
  42 that every possible effort be made to gain all-round commitment to the change. Firstly, you
  43 should know precisely <emphasis>why</emphasis> the change is important for the organisation.
  44 Possible motivations to make a change include:
  45 </para>
  46
  47 <itemizedlist>
  48 <listitem>
  49     <para>Improve network manageability</para>
  50 </listitem>
  51 <listitem>
  52     <para>Obtain better user level functionality</para>
  53 </listitem>
  54 <listitem>
  55     <para>Reduce network operating costs</para>
  56 </listitem>
  57 <listitem>
  58     <para>Reduce exposure caused by Microsoft withdrawal of NT4 support</para>
  59 </listitem>
  60 <listitem>
  61     <para>Avoid MS License 6 implications</para>
  62 </listitem>
  63 <listitem>
  64     <para>Reduce organisation's dependency on Microsoft</para>
  65 </listitem>
  66 </itemizedlist>
  67
  68 <para>
  69 It is vital that it be well recognised that Samba-3 is NOT MS Windows NT4. Samba-3 offers
  70 an alternative solution that is both different from MS Windows NT4 and that offers some
  71 advantages compared with it. It should also be recognised that Samba-3 lacks many of the
  72 features that Microsoft has promoted as core values in migration from MS Windows NT4 to
  73 MS Windows 2000 and beyond (with or without Active Directory services).
  74 </para>
  75
  76 <para>
  77 What are the features that Samba-3 can NOT provide?
  78 </para>
  79
  80 <itemizedlist>
  81 <listitem>
  82         <para>Active Directory Server<para>
  83 </listitem>
  84 <listitem>
  85         <para>Group Policy Objects (in Active Direcrtory)<para>
  86 </listitem>
  87 <listitem>
  88         <para>Machine Policy objects<para>
  89 </listitem>
  90 <listitem>
  91         <para>Logon Scripts in Active Directorty<para>
  92 </listitem>
  93 <listitem>
  94         <para>Software Application and Access Controls in Active Directory<para>
  95 </listitem>
  96 </itemizedlist>
  97
  98 <para>
  99 The features that Samba-3 DOES provide and that may be of compelling interest to your site
 100 includes:
 101 </para>
 102
 103 <itemizedlist>
 104 <listitem>
 105         <para>Lower Cost of Ownership</para>
 106 </listitem>
 107 <listitem>
 108         <para>Global availability of support with no strings attached</para>
 109 </listitem>
 110 <listitem>
 111         <para>Dynamic SMB Servers (ie:Can run more than one server per Unix/Linux system)</para>
 112 </listitem>
 113 <listitem>
 114         <para>Creation of on-the-fly logon scripts</para>
 115 </listitem>
 116 <listitem>
 117         <para>Creation of on-the-fly Policy Files</para>
 118 </listitem>
 119 <listitem>
 120         <para>Greater Stability, Reliability, Performance and Availability</para>
 121 </listitem>
 122 <listitem>
 123         <para>Manageability via an ssh connection</para>
 124 </listitem>
 125 <listitem>
 126         <para>Flexible choices of back-end authentication technologies (tdbsam, ldapsam, mysqlsam)</para>
 127 </listitem>
 128 <listitem>
 129         <para>Ability to implement a full single-signon architecture</para>
 130 </listitem>
 131 <listitem>
 132         <para>Ability to distribute authentication systems for absolute minimum wide are network bandwidth demand</para>
 133 </listitem>
 134 </itemizedlist>
 135
 136 <para>
 137 Before migrating a network from MS Windows NT4 to Samba-3 it is vital that all necessary factors are
 138 considered. Users should be educated about changes they may experience so that the change will be a
 139 welcome one and not become an obstacle to the work they need to do. The following are some of the
 140 factors that will go into a successful migration:
 141 </para>
 142
 143 <sect3>
 144 <title>Domain Layout</title>
 145
 146 <para>
 147 Samba-3 can be configured as a domain controller, a back-up domain controller (probably best called
 148 a secondary controller), a domain member, or as a stand-alone server. The Windows network security
 149 domain context should be sized and scoped before implementation. Particular attention needs to be
 150 paid to the location of the primary domain controller (PDC) as well as backup controllers (BDCs).
 151 It should be noted that one way in which Samba-3 differs from Microsoft technology is that if one
 152 chooses to use an LDAP authentication backend then the same database can be used by several different
 153 domains. This means that in a complex organisation there can be a single LDAP database, that itself
 154 can be distributed, that can simultaneously serve multiple domains (that can also be widely distributed).
 155 </para>
 156
 157 <para>
 158 It is recommended that from a design perspective, the number of users per server, as well as the number
 159 of servers, per domain should be scaled according to needs and should also consider server capacity
 160 and network bandwidth.
 161 </para>
 162
 163 <para>
 164 A physical network segment may house several domains, each of which may span multiple network segments.
 165 Where domains span routed network segments it is most advisable to consider and test the performance
 166 implications of the design and layout of a network. A Centrally located domain controller that is being
 167 designed to serve mulitple routed network segments may result in severe performance problems if the
 168 response time (eg: ping timing) between the remote segment and the PDC is more than 100 ms. In situations
 169 where the delay is too long it is highly recommended to locate a backup controller (BDC) to serve as
 170 the local authentication and access control server.
 171 </para>
 172 </sect3>
 173
 174 <sect3>
 175 <title>Server Share and Directory Layout</title>
 176
 177 <para>
 178 There are few cardinal rules to effective network design that can be broken with impunity.
 179 The most important rule of effective network management is that simplicity is king in every
 180 well controlled network. Every part of the infrastructure must be managed, the more complex
 181 it is, the greater will be the demand of keeping systems secure and functional.
 182 </para>
 183
 184 <para>
 185 The nature of the data that must be stored needs to be born in mind when deciding how many
 186 shares must be created. The physical disk space layout should also be taken into account
 187 when designing where share points will be created. Keep in mind that all data needs to be
 188 backed up, thus the simpler the disk layout the easier it will be to keep track of what must
 189 be backed up to tape or other off-line storage medium. Always plan and implement for minimum
 190 maintenance. Leave nothing to chance in your design, above all, do not leave backups to chance:
 191 Backup and test, validate every backup, create a disaster recovery plan and prove that it works.
 192 </para>
 193
 194 <para>
 195 Users should be grouped according to data access control needs. File and directory access
 196 is best controlled via group permissions and the use of the "sticky bit" on group controlled
 197 directories may substantially avoid file access complaints from samba share users.
 198 </para>
 199
 200 <para>
 201 Many network administrators who are new to the game will attempt to use elaborate techniques
 202 to set access controls, on files, directories, shares, as well as in share definitions.
 203 There is the ever present danger that that administrator's successor will not understand the
 204 complex mess that has been inherited. Remember, apparent job security through complex design
 205 and implementation may ultimately cause loss of operations and downtime to users as the new
 206 administrator learns to untangle your web. Keep access controls simple and effective and
 207 make sure that users will never be interrupted by the stupidity of complexity.
 208 </para>
 209 </sect3>
 210
 211 <sect3>
 212 <title>Logon Scripts</title>
 213
 214 <para>
 215 Please refer to the section of this document on Advanced Network Adminsitration for information
 216 regarding the network logon script options for Samba-3. Logon scripts can help to ensure that
 217 all users gain share and printer connections they need.
 218 </para>
 219
 220 <para>
 221 Logon scripts can be created on-the-fly so that all commands executed are specific to the
 222 rights and privilidges granted to the user. The preferred controls should be affected through
 223 group membership so that group information can be used to custom create a logong script using
 224 the <filename>root preexec</filename> parameters to the <filename>NETLOGON</filename> share.
 225 </para>
 226
 227 <para>
 228 Some sites prefer to use a tool such as <filename>kixstart</filename> to establish a controlled
 229 user environment. In any case you may wish to do a google search for logon script process controls.
 230 In particular, you may wish to explore the use of the Microsoft knowledgebase article KB189105 that
 231 deals with how to add printers without user intervention via the logon script process.
 232 </para>
 233 </sect3>
 234
 235 <sect3>
 236 <title>Profile Migration/Creation</title>
 237
 238 <para>
 239 User and Group Profiles may be migrated using the tools described in the section titled Desktop Profile
 240 Management.
 241 </para>
 242
 243 <para>
 244 Profiles may also be managed using the Samba-3 tool <filename>profiles</filename>. This tool allows
 245 the MS Windows NT style security identifiers (SIDs) that are stored inside the profile NTuser.DAT file
 246 to be changed to the SID of the Samba-3 domain.
 247 </para>
 248 </sect3>
 249
 250 <sect3>
 251 <title>User and Group Accounts</title>
 252
 253 <para>
 254 It is possible to migrate all account settings from an MS Windows NT4 domain to Samba-3. Before
 255 attempting to migrate user and group accounts it is STRONGLY advised to create in Samba-3 the
 256 groups that are present on the MS Windows NT4 domain <emphasis>AND</emphasis> to connect these to
 257 suitable Unix/Linux groups. Following this simple advice will mean that all user and group attributes
 258 should migrate painlessly.
 259 </para>
 260 </sect3>
 261
 262 </sect2>
 263
 264 <sect2>
 265 <title>Steps In Migration Process</title>
 266
 267 <para>
 268 The approximate migration process is described below.
 269 </para>
 270
 271 <itemizedlist>
 272 <listitem><para>
 273 You will have an NT4 PDC that has the users, groups, policies and profiles to be migrated
 274 </para></listitem>
 275
 276 <listitem><para>
 277 Samba-3 set up as a DC with netlogon share, profile share, etc.
 278 </para></listitem>
 279 </itemizedlist>
 280
 281 <procedure><title>The Account Migration Process</title>
 282         <step><para>Create a BDC account for the samba server using NT Server Manager</para>
 283                 <substeps><step><para>Samba must NOT be running</para></step></substeps></step>
 284
 285         <step>
 286         <para>rpcclient NT4PDC -U Administrator%passwd</para>
 287                 <substeps><step><para>lsaquery</para></step>
 288                           <step><para>Note the SID returned</para></step>
 289                 </substeps>
 290         </step>
 291
 292         <step><para>net getsid -S NT4PDC -w DOMNAME -U Administrator%passwd</para>
 293                 <substeps><step><para>Note the SID</para></step></substeps>
 294         </step>
 295
 296         <step><para>net getlocalsid</para>
 297                 <substeps>
 298                 <step><para>Note the SID, now check that all three SIDS reported are the same!</para></step>
 299                 </substeps>
 300         </step>
 301
 302         <step><para>net rpc join -S NT4PDC -w DOMNAME -U Administrator%passwd</para></step>
 303
 304         <step><para>net rpc vampire -S NT4PDC -U administrator%passwd</para></step>
 305
 306         <step><para>pdbedit -l</para>
 307                 <substeps><step><para>Note - did the users migrate?</para></step></substeps>
 308         </step>
 309
 310         <step><para>initGrps.sh DOMNAME</para></step>
 311
 312         <step><para>smbgroupedit -v</para>
 313                 <substeps><step><para>Now check that all groups are recognised</para></step></substeps>
 314         </step>
 315
 316         <step><para>net rpc campire -S NT4PDC -U administrator%passwd</para></step>
 317
 318         <step><para>pdbedit -lv</para>
 319                 <substeps><step>
 320                         <para>Note - check that all group membership has been migrated</para>
 321                 </step></substeps>
 322         </step>
 323 </procedure>
 324
 325 <para>
 326 Now it is time to migrate all the profiles, then migrate all policy files.
 327 More later.
 328 </para>
 329
 330 </sect2>
 331 </sect1>
 332
 333 <sect1>
 334 <title>Migration Options</title>
 335
 336 <para>
 337 Based on feedback from many sites as well as from actual installation and maintenance
 338 experience sites that wish to migrate from MS Windows NT4 Domain Control to a Samba
 339 based solution fit into three basic categories.
 340 </para>
 341
 342 <table frame="all"><title>The 3 Major Site Types</title>
 343 <tgroup cols="2" align="center">
 344         <thead>
 345         <row><entry align="center">Number of Users</entry><entry>Description</entry></row>
 346         </thead>
 347         <tbody>
 348         <row><entry align="center">&lt 50</entry><entry><para>Want simple conversion with NO pain</para></entry></row>
 349         <row><entry align="center">50 - 250</entry><entry><para>Want new features, can manage some in-house complexity</para></entry></row>
 350         <row><entry align="center">&gt 250</entry><entry><para>Solution/Implementation MUST scale well, complex needs. Cross departmental decision process. Local expertise in most areas</para></entry></row>
 351         </tbody>
 352 </tgroup>
 353 </table>
 354
 355 <sect2>
 356 <title>Planning for Success</title>
 357
 358 <para>
 359 There are three basic choices for sites that intend to migrate from MS Windwows NT4
 360 to Samba-3.
 361 </para>
 362
 363 <itemizedlist>
 364         <listitem><para>
 365         Simple Conversion (total replacement)
 366         </para></listitem>
 367
 368         <listitem><para>
 369         Upgraded Conversion (could be one of integration)
 370         </para></listitem>
 371
 372         <listitem><para>
 373         Complete Redesign (completely new solution)
 374         </para></listitem>
 375 </itemizedlist>
 376
 377 <para>
 378 No matter what choice you make, the following rules will minimise down-stream problems:
 379 </para>
 380
 381 <itemizedlist>
 382         <listitem><para>
 383         Take sufficient time
 384         </para></listitem>
 385
 386         <listitem><para>
 387         Avoid Panic
 388         </para></listitem>
 389
 390         <listitem><para>
 391         Test ALL assumptions
 392         </para></listitem>
 393
 394         <listitem><para>
 395         Test full roll-out program, including workstation deployment
 396         </para></listitem>
 397 </itemizedlist>
 398
 399 <table frame="top"><title>Nature of the Conversion Choices</title>
 400 <tgroup cols="3" align="center">
 401         <thead>
 402         <row><entry>Simple</entry><entry>Upgraded</entry><entry>Redesign</entry></row>
 403         </thead>
 404         <tbody>
 405         <row>
 406         <entry><para>Make use of minimal OS specific features</para></entry>
 407         <entry><para>Translate NT4 features to new host OS features</para></entry>
 408         <entry><para>Decide:</para></entry>
 409         </row>
 410         <row>
 411         <entry><para>Suck all accounts from NT4 into Samba-3</para></entry>
 412         <entry><para>Copy and improve:</para></entry>
 413         <entry><para>Authentication Regime (database location and access)</para></entry>
 414         </row>
 415         <row>
 416         <entry><para>Make least number of operational changes</para></entry>
 417         <entry><para>Make progressive improvements</para></entry>
 418         <entry><para>Desktop Management Methods</para></entry>
 419         </row>
 420         <row>
 421         <entry><para>Take least amount of time to migrate</para></entry>
 422         <entry><para>Minimise user impact</para></entry>
 423         <entry><para>Better Control of Desktops / Users</para></entry>
 424         </row>
 425         <row>
 426         <entry><para>Live versus Isolated Conversion</para></entry>
 427         <entry><para>Maximise functionality</para></entry>
 428         <entry><para>Identify Needs for: Manageability, Scalability, Security, Availability</para></entry>
 429         </row>
 430         <row>
 431         <entry><para>Integrate Samba-3 then migrate while users are active, then Change of control (ie: swap out)</para></entry>
 432         <entry><para>Take advantage of lower maintenance opportunity</para></entry>
 433         <entry><para></para></entry>
 434         </row>
 435         </tbody>
 436 </tgroup>
 437 </table>
 438 </sect2>
 439
 440 <sect2>
 441 <title>Samba Implementation Choices</title>
 442
 443 <para><programlisting>
 444 Authentication database back end
 445         Winbind (external Samba or NT4/200x server)
 446         Can use pam_mkhomedir.so to auto-create home dirs
 447         External server could use Active Directory or NT4 Domain
 448 Database type
 449         smbpasswd, tdbsam, ldapsam, MySQLsam
 450                 With local accounts or with No Unix Accounts (NUA option)
 451 Access Control Points
 452         On the Share itself (Use NT4 Server Manager)
 453         On the file system
 454         Unix permissions on files and directories
 455         Posix ACLs enablement in file system?
 456         Through Samba share parameters
 457                 Not recommended - except as only resort
 458 Policies (migrate or create new ones)
 459         Group Policy Editor (NT4)
 460         Watch out for Tattoo effect
 461 User and Group Profiles
 462         Platform specific so use platform tool to change from a Local to a Roaming profile
 463         Can use new profiles tool to change SIDs (NTUser.DAT)
 464 Logon Scripts (Know how they work)
 465 User and Group mapping to Unix/Linux
 466         username map facility may be needed
 467         Use smbgroupedit to connect NT4 groups to Unix groups
 468         Use pdbedit to set/change user configuration
 469 NOTE:
 470 If migrating to LDAP back end it may be easier to dump initial LDAP database to LDIF, then edit, then reload into LDAP
 471         OS specific scripts / programs may be needed
 472                 Add / delete Users
 473                         Note OS limits on size of name (Linux 8 chars)
 474                                 NT4 up to 254 chars
 475                 Add / delete machines
 476                         Applied only to domain members (note up to 16 chars)
 477                 Add / delete Groups
 478                         Note OS limits on size and nature
 479                                 Linux limit is 16 char, no spaces and no upper case chars (groupadd)
 480
 481 Migration Tools
 482         Domain Control (NT4 Style)
 483         Profiles, Policies, Access Controls, Security
 484 Migration Tools
 485         Samba: net, rpcclient, smbpasswd, pdbedit, smbgroupedit, profiles
 486         Windows: NT4 Domain User Manager, Server Manager (NEXUS)
 487 Authentication
 488         New SAM back end (smbpasswd, tdbsam, ldapsam, mysqlsam)
 489                 With of without Unix Accounts (NUA)
 490 </programlisting>
 491 </para>
 492
 493 </sect1>
 494
 495 <sect1>
 496 <title>Migration Options</title>
 497
 498 <para>
 499 There are 3 major Site Types:
 500 </para>
 501
 502 <para><programlisting>
 503 <= 50 Users
 504 Want simple conversion with NO pain
 505 50 - 250 Users
 506 Want new features, can manage some in-house complexity
 507 Large Scale Sites
 508 Solution / Implementation MUST scale well, complex needs
 509 Cross departmental decision process
 510 Local expertise in most areas
 511 Planning for Success
 512 Decide which approach is needed - 3 Choices
 513 Simple Conversion (total replacement)
 514 Upgraded Conversion (could be one of integration)
 515 Complete Redesign (completely new solution)
 516 Take sufficient time
 517 Avoid Panic
 518 Test ALL assumptions
 519 Test full roll-out program, including workstation deployment
 520 Simple Conversion
 521 Make use of minimal OS specific features
 522 Can use No Unix Accounts Option
 523 Suck all accounts from NT4 into Samba-3
 524 Make least number of operational changes
 525 Take least amount of time to migrate
 526 Live versus Isolated Conversion
 527 Integrate Samba-3 then migrate while users are active
 528 Change of control (ie: swap out)
 529 Upgraded Conversion
 530 Translate NT4 features to new host OS features
 531 Copy and improve
 532 Old environment to Samba-3
 533 Make progressive improvements
 534 Minimise user impact
 535 Macimise functionality
 536 Take advantage of lower maintenance opportunity
 537 Complete Network Redesign
 538 Decide
 539 Authentication Regime (database locate and access)
 540 Desktop Management Methods
 541 Better Control of Desktops / Users
 542 Identify Needs for:
 543 Manageability, Scalability, Security, Availability
 544 Samba Implementation Choices
 545 Authentication database back end
 546 Winbind (external Samba or NT4/200x server)
 547 Can use pam_mkhomedir.so to auto-create home dirs
 548 External server could use Active Directory or NT4 Domain
 549 Database type
 550 smbpasswd, tdbsam, ldapsam, MySQLsam
 551 With local accounts or with No Unix Accounts (NUA option)
 552 Samba Implementation Choice - II
 553 Access Control Points
 554 On the Share itself (Use NT4 Server Manager)
 555 On the file system
 556 Unix permissions on files and directories
 557 Posix ACLs enablement in file system?
 558 Through Samba share parameters
 559 Not recommended - except as only resort
 560 Samba Implementation Choice - III
 561 Policies (migrate or create new ones)
 562 Group Policy Editor (NT4)
 563 Watch out for Tattoo effect
 564 User and Group Profiles
 565 Platform specific so use platform tool to change from a Local to a Roaming profile
 566 Can use new profiles tool to change SIDs (NTUser.DAT)
 567 Logon Scripts (Know how they work)
 568 Samba Implementation Choices - IV
 569 User and Group mapping to Unix/Linux
 570 username map facility may be needed
 571 Use smbgroupedit to connect NT4 groups to Unix groups
 572 Use pdbedit to set/change user configuration
 573 NOTE:
 574 If migrating to LDAP back end it may be easier to dump initial LDAP database to LDIF, then edit, then reload into LDAP
 575 Samba Implementation Choices - V
 576 OS specific scripts / programs may be needed
 577 Add / delete Users
 578 Note OS limits on size of name (Linux 8 chars)
 579 NT4 up to 254 chars
 580 Add / delete machines
 581 Applied only to domain members (note up to 16 chars)
 582 Add / delete Groups
 583 Note OS limits on size and nature
 584 Linux limit is 16 char, no spaces and no upper case chars (groupadd)
 585 Migration Tools
 586 Domain Control (NT4 Style)
 587 Profiles, Policies, Access Controls, Security
 588 Migration Tools
 589 Samba: net, rpcclient, smbpasswd, pdbedit, smbgroupedit, profiles
 590 Windows: NT4 Domain User Manager, Server Manager (NEXUS)
 591 Authentication
 592 New SAM back end (smbpasswd, tdbsam, ldapsam, mysqlsam)
 593 With of without Unix Accounts (NUA)
 594 <programlisting></para>
 595
 596 </sect1>
 597
 598 <sect1>
 599 <title>Managing Samba-3 Domain Control</title>
 600
 601 <para>
 602 Lots of blah blah here.
 603 </para>
 604
 605 </sect1>
 606 </chapter>