diff options
Diffstat (limited to 'docs/htmldocs/NT4Migration.html')
| -rw-r--r-- | docs/htmldocs/NT4Migration.html | 203 |
1 files changed, 0 insertions, 203 deletions
diff --git a/docs/htmldocs/NT4Migration.html b/docs/htmldocs/NT4Migration.html deleted file mode 100644 index 0d7dbce2ed..0000000000 --- a/docs/htmldocs/NT4Migration.html +++ /dev/null @@ -1,203 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 31. Migration from NT4 PDC to Samba-3 PDC</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="migration.html" title="Part IV. Migration and Updating"><link rel="previous" href="upgrading-to-3.0.html" title="Chapter 30. Upgrading from Samba-2.x to Samba-3.0.0"><link rel="next" href="SWAT.html" title="Chapter 32. SWAT - The Samba Web Administration Tool"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 31. Migration from NT4 PDC to Samba-3 PDC</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="upgrading-to-3.0.html">Prev</a> </td><th width="60%" align="center">Part IV. Migration and Updating</th><td width="20%" align="right"> <a accesskey="n" href="SWAT.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="NT4Migration"></a>Chapter 31. Migration from NT4 PDC to Samba-3 PDC</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></tt></p></div></div></div></div><div><p class="pubdate">April 3, 2003</p></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="NT4Migration.html#id3000463">Planning and Getting Started</a></dt><dd><dl><dt><a href="NT4Migration.html#id3000487">Objectives</a></dt><dt><a href="NT4Migration.html#id2999415">Steps In Migration Process</a></dt></dl></dd><dt><a href="NT4Migration.html#id3001632">Migration Options</a></dt><dd><dl><dt><a href="NT4Migration.html#id3001713">Planning for Success</a></dt><dt><a href="NT4Migration.html#id3001954">Samba Implementation Choices</a></dt></dl></dd></dl></div><p> -This is a rough guide to assist those wishing to migrate from NT4 domain control to -Samba-3 based domain control. -</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id3000463"></a>Planning and Getting Started</h2></div></div><div></div></div><p> -In the IT world there is often a saying that all problems are encountered because of -poor planning. The corollary to this saying is that not all problems can be anticipated -and planned for. Then again, good planning will anticipate most show stopper type situations. -</p><p> -Those wishing to migrate from MS Windows NT4 domain control to a Samba-3 domain control -environment would do well to develop a detailed migration plan. So here are a few pointers to -help migration get under way. -</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id3000487"></a>Objectives</h3></div></div><div></div></div><p> -The key objective for most organisations will be to make the migration from MS Windows NT4 -to Samba-3 domain control as painless as possible. One of the challenges you may experience -in your migration process may well be one of convincing management that the new environment -should remain in place. Many who have introduced open source technologies have experienced -pressure to return to a Microsoft based platform solution at the first sign of trouble. -</p><p> -It is strongly advised that before attempting a migration to a Samba-3 controlled network -that every possible effort be made to gain all-round commitment to the change. Firstly, you -should know precisely <span class="emphasis"><em>why</em></span> the change is important for the organisation. -Possible motivations to make a change include: -</p><table class="simplelist" border="0" summary="Simple list"><tr><td>Improve network manageability</td></tr><tr><td>Obtain better user level functionality</td></tr><tr><td>Reduce network operating costs</td></tr><tr><td>Reduce exposure caused by Microsoft withdrawal of NT4 support</td></tr><tr><td>Avoid MS License 6 implications</td></tr><tr><td>Reduce organisation's dependency on Microsoft</td></tr></table><p> -It is vital that it be well recognised that Samba-3 is NOT MS Windows NT4. Samba-3 offers -an alternative solution that is both different from MS Windows NT4 and that offers some -advantages compared with it. It should also be recognised that Samba-3 lacks many of the -features that Microsoft has promoted as core values in migration from MS Windows NT4 to -MS Windows 2000 and beyond (with or without Active Directory services). -</p><p> -What are the features that Samba-3 can NOT provide? -</p><table class="simplelist" border="0" summary="Simple list"><tr><td>Active Directory Server</td></tr><tr><td>Group Policy Objects (in Active Directory)</td></tr><tr><td>Machine Policy objects</td></tr><tr><td>Logon Scripts in Active Directory</td></tr><tr><td>Software Application and Access Controls in Active Directory</td></tr></table><p> -The features that Samba-3 DOES provide and that may be of compelling interest to your site -includes: -</p><table class="simplelist" border="0" summary="Simple list"><tr><td>Lower Cost of Ownership</td></tr><tr><td>Global availability of support with no strings attached</td></tr><tr><td>Dynamic SMB Servers (ie:Can run more than one server per Unix/Linux system)</td></tr><tr><td>Creation of on-the-fly logon scripts</td></tr><tr><td>Creation of on-the-fly Policy Files</td></tr><tr><td>Greater Stability, Reliability, Performance and Availability</td></tr><tr><td>Manageability via an ssh connection</td></tr><tr><td>Flexible choices of back-end authentication technologies (tdbsam, ldapsam, mysqlsam)</td></tr><tr><td>Ability to implement a full single-sign-on architecture</td></tr><tr><td>Ability to distribute authentication systems for absolute minimum wide area network bandwidth demand</td></tr></table><p> -Before migrating a network from MS Windows NT4 to Samba-3 it is vital that all necessary factors are -considered. Users should be educated about changes they may experience so that the change will be a -welcome one and not become an obstacle to the work they need to do. The following are some of the -factors that will go into a successful migration: -</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2999189"></a>Domain Layout</h4></div></div><div></div></div><p> -Samba-3 can be configured as a domain controller, a back-up domain controller (probably best called -a secondary controller), a domain member, or as a stand-alone server. The Windows network security -domain context should be sized and scoped before implementation. Particular attention needs to be -paid to the location of the primary domain controller (PDC) as well as backup controllers (BDCs). -It should be noted that one way in which Samba-3 differs from Microsoft technology is that if one -chooses to use an LDAP authentication backend then the same database can be used by several different -domains. This means that in a complex organisation there can be a single LDAP database, that itself -can be distributed, that can simultaneously serve multiple domains (that can also be widely distributed). -</p><p> -It is recommended that from a design perspective, the number of users per server, as well as the number -of servers, per domain should be scaled according to needs and should also consider server capacity -and network bandwidth. -</p><p> -A physical network segment may house several domains, each of which may span multiple network segments. -Where domains span routed network segments it is most advisable to consider and test the performance -implications of the design and layout of a network. A Centrally located domain controller that is being -designed to serve multiple routed network segments may result in severe performance problems if the -response time (eg: ping timing) between the remote segment and the PDC is more than 100 ms. In situations -where the delay is too long it is highly recommended to locate a backup controller (BDC) to serve as -the local authentication and access control server. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2999243"></a>Server Share and Directory Layout</h4></div></div><div></div></div><p> -There are few cardinal rules to effective network design that can be broken with impunity. -The most important rule of effective network management is that simplicity is king in every -well controlled network. Every part of the infrastructure must be managed, the more complex -it is, the greater will be the demand of keeping systems secure and functional. -</p><p> -The nature of the data that must be stored needs to be born in mind when deciding how many -shares must be created. The physical disk space layout should also be taken into account -when designing where share points will be created. Keep in mind that all data needs to be -backed up, thus the simpler the disk layout the easier it will be to keep track of what must -be backed up to tape or other off-line storage medium. Always plan and implement for minimum -maintenance. Leave nothing to chance in your design, above all, do not leave backups to chance: -Backup and test, validate every backup, create a disaster recovery plan and prove that it works. -</p><p> -Users should be grouped according to data access control needs. File and directory access -is best controlled via group permissions and the use of the "sticky bit" on group controlled -directories may substantially avoid file access complaints from samba share users. -</p><p> -Many network administrators who are new to the game will attempt to use elaborate techniques -to set access controls, on files, directories, shares, as well as in share definitions. -There is the ever present danger that that administrator's successor will not understand the -complex mess that has been inherited. Remember, apparent job security through complex design -and implementation may ultimately cause loss of operations and downtime to users as the new -administrator learns to untangle your web. Keep access controls simple and effective and -make sure that users will never be interrupted by the stupidity of complexity. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2999304"></a>Logon Scripts</h4></div></div><div></div></div><p> -Please refer to the section of this document on Advanced Network Administration for information -regarding the network logon script options for Samba-3. Logon scripts can help to ensure that -all users gain share and printer connections they need. -</p><p> -Logon scripts can be created on-the-fly so that all commands executed are specific to the -rights and privileges granted to the user. The preferred controls should be affected through -group membership so that group information can be used to custom create a logon script using -the <i class="parameter"><tt>root preexec</tt></i> parameters to the <tt class="filename">NETLOGON</tt> share. -</p><p> -Some sites prefer to use a tool such as <b class="command">kixstart</b> to establish a controlled -user environment. In any case you may wish to do a google search for logon script process controls. -In particular, you may wish to explore the use of the Microsoft knowledgebase article KB189105 that -deals with how to add printers without user intervention via the logon script process. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2999361"></a>Profile Migration/Creation</h4></div></div><div></div></div><p> -User and Group Profiles may be migrated using the tools described in the section titled Desktop Profile -Management. -</p><p> -Profiles may also be managed using the Samba-3 tool <b class="command">profiles</b>. This tool allows -the MS Windows NT style security identifiers (SIDs) that are stored inside the profile NTuser.DAT file -to be changed to the SID of the Samba-3 domain. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2999390"></a>User and Group Accounts</h4></div></div><div></div></div><p> -It is possible to migrate all account settings from an MS Windows NT4 domain to Samba-3. Before -attempting to migrate user and group accounts it is STRONGLY advised to create in Samba-3 the -groups that are present on the MS Windows NT4 domain <span class="emphasis"><em>AND</em></span> to connect these to -suitable Unix/Linux groups. Following this simple advice will mean that all user and group attributes -should migrate painlessly. -</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2999415"></a>Steps In Migration Process</h3></div></div><div></div></div><p> -The approximate migration process is described below. -</p><div class="itemizedlist"><ul type="disc"><li><p> -You will have an NT4 PDC that has the users, groups, policies and profiles to be migrated -</p></li><li><p> -Samba-3 set up as a DC with netlogon share, profile share, etc. -</p></li></ul></div><div class="procedure"><p class="title"><b>Procedure 31.1. The Account Migration Process</b></p><ol type="1"><li><p>Create a BDC account for the samba server using NT Server Manager</p><ol type="a"><li><p>Samba must NOT be running</p></li></ol></li><li><p><b class="userinput"><tt>rpcclient <i class="replaceable"><tt>NT4PDC</tt></i> -U Administrator%<i class="replaceable"><tt>passwd</tt></i></tt></b></p><ol type="a"><li><p>lsaquery</p></li><li><p>Note the SID returned</p></li></ol></li><li><p><b class="userinput"><tt>net getsid -S <i class="replaceable"><tt>NT4PDC</tt></i> -w <i class="replaceable"><tt>DOMNAME</tt></i> -U Administrator%<i class="replaceable"><tt>passwd</tt></i></tt></b></p><ol type="a"><li><p>Note the SID</p></li></ol></li><li><p><b class="userinput"><tt>net getlocalsid</tt></b></p><ol type="a"><li><p>Note the SID, now check that all three SIDS reported are the same!</p></li></ol></li><li><p><b class="userinput"><tt>net rpc join -S <i class="replaceable"><tt>NT4PDC</tt></i> -w <i class="replaceable"><tt>DOMNAME</tt></i> -U Administrator%<i class="replaceable"><tt>passwd</tt></i></tt></b></p></li><li><p><b class="userinput"><tt>net rpc vampire -S <i class="replaceable"><tt>NT4PDC</tt></i> -U administrator%<i class="replaceable"><tt>passwd</tt></i></tt></b></p></li><li><p><b class="userinput"><tt>pdbedit -L</tt></b></p><ol type="a"><li><p>Note - did the users migrate?</p></li></ol></li><li><p><b class="userinput"><tt>initGrps.sh <i class="replaceable"><tt>DOMNAME</tt></i></tt></b></p></li><li><p><b class="userinput"><tt>net groupmap list</tt></b></p><ol type="a"><li><p>Now check that all groups are recognised</p></li></ol></li><li><p><b class="userinput"><tt>net rpc vampire -S <i class="replaceable"><tt>NT4PDC</tt></i> -U administrator%<i class="replaceable"><tt>passwd</tt></i></tt></b></p></li><li><p><b class="userinput"><tt>pdbedit -Lv</tt></b></p><ol type="a"><li><p>Note - check that all group membership has been migrated</p></li></ol></li></ol></div><p> -Now it is time to migrate all the profiles, then migrate all policy files. -More later. -</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id3001632"></a>Migration Options</h2></div></div><div></div></div><p> -Based on feedback from many sites as well as from actual installation and maintenance -experience sites that wish to migrate from MS Windows NT4 Domain Control to a Samba -based solution fit into three basic categories. -</p><div class="table"><a name="id3001647"></a><p class="title"><b>Table 31.1. The 3 Major Site Types</b></p><table summary="The 3 Major Site Types" border="1"><colgroup><col><col></colgroup><thead><tr><th>Number of Users</th><th>Description</th></tr></thead><tbody><tr><td>< 50</td><td><p>Want simple conversion with NO pain</p></td></tr><tr><td>50 - 250</td><td><p>Want new features, can manage some in-house complexity</p></td></tr><tr><td>> 250</td><td><p>Solution/Implementation MUST scale well, complex needs. Cross departmental decision process. Local expertise in most areas</p></td></tr></tbody></table></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id3001713"></a>Planning for Success</h3></div></div><div></div></div><p> -There are three basic choices for sites that intend to migrate from MS Windows NT4 -to Samba-3. -</p><div class="itemizedlist"><ul type="disc"><li><p> - Simple Conversion (total replacement) - </p></li><li><p> - Upgraded Conversion (could be one of integration) - </p></li><li><p> - Complete Redesign (completely new solution) - </p></li></ul></div><p> -No matter what choice you make, the following rules will minimise down-stream problems: -</p><div class="itemizedlist"><ul type="disc"><li><p> - Take sufficient time - </p></li><li><p> - Avoid Panic - </p></li><li><p> - Test ALL assumptions - </p></li><li><p> - Test full roll-out program, including workstation deployment - </p></li></ul></div><div class="table"><a name="id3001783"></a><p class="title"><b>Table 31.2. Nature of the Conversion Choices</b></p><table summary="Nature of the Conversion Choices" border="1"><colgroup><col><col><col></colgroup><thead><tr><th>Simple</th><th>Upgraded</th><th>Redesign</th></tr></thead><tbody><tr><td><p>Make use of minimal OS specific features</p></td><td><p>Translate NT4 features to new host OS features</p></td><td><p>Decide:</p></td></tr><tr><td><p>Suck all accounts from NT4 into Samba-3</p></td><td><p>Copy and improve:</p></td><td><p>Authentication Regime (database location and access)</p></td></tr><tr><td><p>Make least number of operational changes</p></td><td><p>Make progressive improvements</p></td><td><p>Desktop Management Methods</p></td></tr><tr><td><p>Take least amount of time to migrate</p></td><td><p>Minimise user impact</p></td><td><p>Better Control of Desktops / Users</p></td></tr><tr><td><p>Live versus Isolated Conversion</p></td><td><p>Maximise functionality</p></td><td><p>Identify Needs for: Manageability, Scalability, Security, Availability</p></td></tr><tr><td><p>Integrate Samba-3 then migrate while users are active, then Change of control (ie: swap out)</p></td><td><p>Take advantage of lower maintenance opportunity</p></td><td><p></p></td></tr></tbody></table></div></div><div xmlns:ns95="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id3001954"></a>Samba Implementation Choices</h3></div></div><div></div></div><pre class="programlisting"> -Authentication database back end - Winbind (external Samba or NT4/200x server) - Can use pam_mkhomedir.so to auto-create home dirs - External server could use Active Directory or NT4 Domain - -Database type - smbpasswd, tdbsam, ldapsam, mysqlsam - -Access Control Points - On the Share itself (Use NT4 Server Manager) - On the file system - Unix permissions on files and directories - Enable Posix ACLs in file system? - Through Samba share parameters - Not recommended - except as only resort - -Policies (migrate or create new ones) - Group Policy Editor (NT4) - Watch out for Tattoo effect - -User and Group Profiles - Platform specific so use platform tool to change from a Local - to a Roaming profile Can use new profiles tool to change SIDs - (NTUser.DAT) - -Logon Scripts (Know how they work) - -User and Group mapping to Unix/Linux - username map facility may be needed - Use 'net groupmap' to connect NT4 groups to Unix groups - Use pdbedit to set/change user configuration -NOTE: -If migrating to LDAP back end it may be easier to dump initial LDAP database -to LDIF, then edit, then reload into LDAP - - OS specific scripts / programs may be needed - Add / delete Users - Note OS limits on size of name (Linux 8 chars) - NT4 up to 254 chars - Add / delete machines - Applied only to domain members (note up to 16 chars) - Add / delete Groups - Note OS limits on size and nature - Linux limit is 16 char, - no spaces and no upper case chars (groupadd) - -Migration Tools - Domain Control (NT4 Style) - Profiles, Policies, Access Controls, Security - -Migration Tools - Samba: net, rpcclient, smbpasswd, pdbedit, profiles - Windows: NT4 Domain User Manager, Server Manager (NEXUS) - -Authentication - New SAM back end (smbpasswd, tdbsam, ldapsam, mysqlsam) -</pre><ns95:p> -</ns95:p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="upgrading-to-3.0.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="migration.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="SWAT.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 30. Upgrading from Samba-2.x to Samba-3.0.0 </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 32. SWAT - The Samba Web Administration Tool</td></tr></table></div></body></html> |