From d4b35b895cdf157e49609b59ec89ab648dafb524 Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Wed, 13 Apr 2005 04:04:36 +0000 Subject: More updates. (This used to be commit 20f8bde1d0a2b2e42efedcdac21778fe34c0ab79) --- .../TOSHARG-NT4Migration.xml | 527 +++++++++++++++++++++ 1 file changed, 527 insertions(+) create mode 100644 docs/Samba-HOWTO-Collection/TOSHARG-NT4Migration.xml (limited to 'docs/Samba-HOWTO-Collection/TOSHARG-NT4Migration.xml') diff --git a/docs/Samba-HOWTO-Collection/TOSHARG-NT4Migration.xml b/docs/Samba-HOWTO-Collection/TOSHARG-NT4Migration.xml new file mode 100644 index 0000000000..4f65b8c0a7 --- /dev/null +++ b/docs/Samba-HOWTO-Collection/TOSHARG-NT4Migration.xml @@ -0,0 +1,527 @@ + + + + + &author.jht; + April 3, 2003 + + +Migration from NT4 PDC to Samba-3 PDC + + +This is a rough guide to assist those wishing to migrate from NT4 Domain Control to +Samba-3-based Domain Control. + + + +Planning and Getting Started + + +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. + + + +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. + + + +Objectives + + +The key objective for most organizations 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. + + + +Before attempting a migration to a Samba-3 controlled network, make every possible effort to +gain all-round commitment to the change. Know precisely why the change +is important for the organization. Possible motivations to make a change include: + + + + Improve network manageability. + Obtain better user level functionality. + Reduce network operating costs. + Reduce exposure caused by Microsoft withdrawal of NT4 support. + Avoid MS License 6 implications. + Reduce organization's dependency on Microsoft. + + + +Make sure everyone knows that Samba-3 is not MS Windows NT4. Samba-3 offers +an alternative solution that is both different from MS Windows NT4 and offers +advantages compared with it. Gain recognition 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). + + + +What are the features that Samba-3 cannot provide? + + + + Active Directory Server. + Group Policy Objects (in Active Directory). + Machine Policy Objects. + Logon Scripts in Active Directory. + Software Application and Access Controls in Active Directory. + + + +The features that Samba-3 does provide and that may be of compelling interest to your site +include: + + + + Lower cost of ownership. + Global availability of support with no strings attached. + Dynamic SMB Servers (can run more than one SMB/CIFS server per UNIX/Linux system). + Creation of on-the-fly logon scripts. + Creation of on-the-fly Policy Files. + Greater stability, reliability, performance and availability. + Manageability via an ssh connection. + Flexible choices of back-end authentication technologies (tdbsam, ldapsam, mysqlsam). + Ability to implement a full single-sign-on architecture. + Ability to distribute authentication systems for absolute minimum wide area network bandwidth demand. + + + +Before migrating a network from MS Windows NT4 to Samba-3, consider all necessary factors. Users +should be educated about changes they may experience so the change will be a welcome one +and not become an obstacle to the work they need to do. The following are factors that will +help ensure a successful migration: + + + +Domain Layout + + +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). +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. In a +complex organization, there can be a single LDAP database, which itself can be distributed (have +a master server and multiple slave servers) that can simultaneously serve multiple domains. + + + +From a design perspective, the number of users per server as well as the number of servers per +domain should be scaled taking into consideration server capacity and network bandwidth. + + + +A physical network segment may house several domains. Each may span multiple network segments. +Where domains span routed network segments, consider and test the performance implications of +the design and layout of a network. A centrally located Domain Controller that is designed to +serve multiple routed network segments may result in severe performance problems. Check the +response time (ping timing) between the remote segment and the PDC. If +it's long (more than 100 ms), +locate a backup controller (BDC) on the remote segment to serve as the local authentication and +access control server. + + + + +Server Share and Directory Layout + + +There are cardinal rules to effective network design that cannot be broken with impunity. +The most important rule: 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. + + + +Keep in mind the nature of how data must be shared. Physical disk space layout should be considered +carefully. Some data must be backed up. The simpler the disk layout the easier it will be to +keep track of backup needs. Identify what backup media will meet your needs; consider backup to tape, +CD-ROM or (DVD-ROM), or other offline storage medium. Plan and implement for minimum +maintenance. Leave nothing to chance in your design; above all, do not leave backups to chance: +Backup, test, and validate every backup, create a disaster recovery plan and prove that it works. + + + +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. + + + +Inexperienced network administrators often attempt elaborate techniques to set access +controls on files, directories, shares, as well as in share definitions. +Keep your design and implementation simple and document your design extensively. Have others +audit your documentation. Do not create a complex mess that your successor will not understand. +Remember, job security through complex design and implementation may cause loss of operations +and downtime to users as the new administrator learns to untangle your knots. Keep access +controls simple and effective and make sure that users will never be interrupted by obtuse +complexity. + + + + +Logon Scripts + + +Logon scripts can help to ensure that all users gain the share and printer connections they need. + + + +Logon scripts can be created on-the-fly so all commands executed are specific to the +rights and privileges granted to the user. The preferred controls should be affected through +group membership so group information can be used to create a custom logon script using +the parameters to the share. + + + +Some sites prefer to use a tool such as kixstart 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 Knowledge Base article KB189105 that +deals with how to add printers without user intervention via the logon script process. + + + + +Profile Migration/Creation + + +User and Group Profiles may be migrated using the tools described in the section titled Desktop Profile +Management. + + + + +SID +Profiles may also be managed using the Samba-3 tool profiles. 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. + + + + +User and Group Accounts + + +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 AND to map them to +suitable UNIX/Linux groups. By following this simple advice, all user and group attributes +should migrate painlessly. + + + + + + +Steps in Migration Process + + +The approximate migration process is described below. + + + + +You have an NT4 PDC that has the users, groups, policies and profiles to be migrated. + + + +Samba-3 set up as a DC with netlogon share, profile share, and so on. Configure the &smb.conf; file +to function as a BDC, i.e., domain master = No. + + + +The Account Migration Process + +pdbedit + Create a BDC account in the old NT4 domain for the Samba server using NT Server Manager. + Samba must not be running. + + + +netrpc + net rpc join -S NT4PDC -w DOMNAME -U Administrator%passwd + + net rpc vampire -S NT4PDC -U administrator%passwd + + pdbedit -L + Note &smbmdash; did the users migrate? + + + + +netgroupmap +initGroups.sh + Now assign each of the UNIX groups to NT groups: + (It may be useful to copy this text to a script called initGroups.sh) + + +#!/bin/bash +#### Keep this as a shell script for future re-use + +# First assign well known domain global groups +net groupmap modify ntgroup="Domain Admins" unixgroup=root +net groupmap modify ntgroup="Domain Users" unixgroup=users +net groupmap modify ntgroup="Domain Guests" unixgroup=nobody + +# Now for our added domain global groups +net groupmap add ntgroup="Designers" unixgroup=designers type=d rid=3200 +net groupmap add ntgroup="Engineers" unixgroup=engineers type=d rid=3210 +net groupmap add ntgroup="QA Team" unixgroup=qateam type=d rid=3220 + + + + + net groupmap list + Check that all groups are recognized. + + + + +Migrate all the profiles, then migrate all policy files. + + + + + + +Migration Options + + +Sites that wish to migrate from MS Windows NT4 Domain Control to a Samba-based solution +generally fit into three basic categories. Following table shows the possibilities. + + +The Three Major Site Types + + + + + Number of UsersDescription + + + < 50Want simple conversion with no pain. + 50 - 250Want new features, can manage some in-house complexity. + > 250Solution/Implementation must scale well, complex needs. Cross-departmental decision process. Local expertise in most areas. + + +
+ + +Planning for Success + + +There are three basic choices for sites that intend to migrate from MS Windows NT4 +to Samba-3: + + + + + Simple conversion (total replacement). + + + + Upgraded conversion (could be one of integration). + + + + Complete redesign (completely new solution). + + + + +Minimize down-stream problems by: + + + + + Taking sufficient time. + + + + Avoiding Panic. + + + + Testing all assumptions. + + + + Testing the full roll-out program, including workstation deployment. + + + +Following table lists the conversion choices given the type of migration +being contemplated. + + +Nature of the Conversion Choices + + + + + + SimpleUpgradedRedesign + + + + Make use of minimal OS specific features. + Translate NT4 features to new host OS features. + Decide: + + + Move all accounts from NT4 into Samba-3 + Copy and improve + Authentication regime (database location and access) + + + Make least number of operational changes + Make progressive improvements + Desktop management methods + + + Take least amount of time to migrate + Minimize user impact + Better control of Desktops/Users + + + Live versus isolated conversion + Maximize functionality + Identify Needs for: Manageability, Scalability, Security, Availability + + + Integrate Samba-3 then migrate while users are active, then change of control (swap out) + Take advantage of lower maintenance opportunity + + + + +
+ + + +Samba-3 Implementation Choices + + + Authentication Database/Backend + + Samba-3 can use an external authentication backend: + + + + + Winbind (external Samba or NT4/200x server). + External server could use Active Directory or NT4 Domain. + Can use pam_mkhomedir.so to auto-create home dirs. + + Samba-3 can use a local authentication backend: smbpasswd, tdbsam, ldapsam, mysqlsam + + + + + Access Control Points + + Samba permits Access Control Points to be set: + + + On the share itself &smbmdash; using Share ACLs. + On the file system &smbmdash; using UNIX permissions on files and directories. + Note: Can enable Posix ACLs in file system also. + Through Samba share parameters &smbmdash; not recommended except as last resort. + + + + + Policies (migrate or create new ones) + + Exercise great caution when affecting registry changes, use the right tool and be aware + that changes made through NT4-style NTConfig.POL files can leave + permanent changes. + + + Using 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 + +pdbedit + User and Group mapping code is new. Many problems have been experienced as network administrators + who are familiar with Samba-2.2.x migrate to Samba-3. Carefully study the chapters that document + the new password backend behavior and the new group mapping functionality. + + + The username map facility may be needed. + Use net groupmap to connect NT4 groups to UNIX groups. + Use pdbedit to set/change user configuration. + + + When migrating to LDAP backend, it may be easier to dump the initial + LDAP database to LDIF, edit, then reload into LDAP. + + + + + + + OS Specific Scripts/Programs may be Needed + + Every operating system has its peculiarities. These are the result of engineering decisions + that were based on the experience of the designer, and may have side-effects that were not + anticipated. Limitations that may bite the Windows network administrator include: + + + 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: machine names may be limited to 16 characters). + Use net groupmap to connect NT4 groups to UNIX groups. + 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 + +pdbedit + Domain Control (NT4 Style) Profiles, Policies, Access Controls, Security + + Samba: net, rpcclient, smbpasswd, pdbedit, profiles. + Windows: NT4 Domain User Manager, Server Manager (NEXUS) + + + + + + + + + + + -- cgit