diff options
Diffstat (limited to 'docs/htmldocs/Samba3-ByExample/upgrades.html')
| -rw-r--r-- | docs/htmldocs/Samba3-ByExample/upgrades.html | 947 |
1 files changed, 0 insertions, 947 deletions
diff --git a/docs/htmldocs/Samba3-ByExample/upgrades.html b/docs/htmldocs/Samba3-ByExample/upgrades.html deleted file mode 100644 index f025a2ab38..0000000000 --- a/docs/htmldocs/Samba3-ByExample/upgrades.html +++ /dev/null @@ -1,947 +0,0 @@ -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 8. Updating Samba-3</title><link rel="stylesheet" href="../samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Samba-3 by Example"><link rel="up" href="DMSMig.html" title="Part II. Domain Members, Updating Samba and Migration"><link rel="prev" href="unixclients.html" title="Chapter 7. Adding Domain Member Servers and Clients"><link rel="next" href="ntmigration.html" title="Chapter 9. Migrating NT4 Domain to Samba-3"></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 8. Updating Samba-3</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="unixclients.html">Prev</a> </td><th width="60%" align="center">Part II. Domain Members, Updating Samba and Migration</th><td width="20%" align="right"> <a accesskey="n" href="ntmigration.html">Next</a></td></tr></table><hr></div><div class="chapter" title="Chapter 8. Updating Samba-3"><div class="titlepage"><div><div><h2 class="title"><a name="upgrades"></a>Chapter 8. Updating Samba-3</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="upgrades.html#id366117">Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="upgrades.html#id366200">Cautions and Notes</a></span></dt></dl></dd><dt><span class="sect1"><a href="upgrades.html#id367413">Upgrading from Samba 1.x and 2.x to Samba-3</a></span></dt><dd><dl><dt><span class="sect2"><a href="upgrades.html#sbeug2">Samba 1.9.x and 2.x Versions Without LDAP</a></span></dt><dt><span class="sect2"><a href="upgrades.html#id367754">Applicable to All Samba 2.x to Samba-3 Upgrades</a></span></dt><dt><span class="sect2"><a href="upgrades.html#id368069">Samba-2.x with LDAP Support</a></span></dt></dl></dd><dt><span class="sect1"><a href="upgrades.html#id368184">Updating a Samba-3 Installation</a></span></dt><dd><dl><dt><span class="sect2"><a href="upgrades.html#id368281">Samba-3 to Samba-3 Updates on the Same Server</a></span></dt><dt><span class="sect2"><a href="upgrades.html#id368465">Migrating Samba-3 to a New Server</a></span></dt><dt><span class="sect2"><a href="upgrades.html#id368842">Migration of Samba Accounts to Active Directory</a></span></dt></dl></dd></dl></div><p> -<a class="indexterm" name="id366043"></a> -<a class="indexterm" name="id366050"></a> -It was a little difficult to select an appropriate title for this chapter. -From email messages on the Samba mailing lists it is clear that many people -consider the updating and upgrading of Samba to be a migration matter. Others -talk about migrating Samba servers when in fact the issue at hand is one of -installing a new Samba server to replace an older existing Samba server. -</p><p> -<a class="indexterm" name="id366063"></a> -<a class="indexterm" name="id366070"></a> -There has also been much talk about migration of Samba-3 from an smbpasswd -passdb backend to the use of the tdbsam or ldapsam facilities that are new -to Samba-3. -</p><p> -Clearly, there is not a great deal of clarity in the terminology that various -people apply to these modes by which Samba servers are updated. This is further -highlighted by an email posting that included the following neat remark: -</p><div class="blockquote"><blockquote class="blockquote"><p> -<a class="indexterm" name="id366088"></a> -I like the <span class="quote">“<span class="quote">net rpc vampire</span>”</span> on NT4, but that to my surprise does -not seem to work against a Samba PDC and, if addressed in the Samba to Samba -context in either book, I could not find it. -</p></blockquote></div><p> -<a class="indexterm" name="id366107"></a> -So in response to the significant request for these situations to be better -documented, this chapter has now been added. User contributions and documentation -of real-world experiences are a most welcome addition to this chapter. -</p><div class="sect1" title="Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id366117"></a>Introduction</h2></div></div></div><p> -<a class="indexterm" name="id366125"></a> -<a class="indexterm" name="id366131"></a> -<a class="indexterm" name="id366138"></a> -A Windows network administrator explained in an email what changes he was -planning to make and followed with the question: <span class="quote">“<span class="quote">Anyone done this -before?</span>”</span> Many of us have upgraded and updated Samba without incident. -Others have experienced much pain and user frustration. So it is to be hoped -that the notes in this chapter will make a positive difference by assuring -that someone will be saved a lot of discomfort. -</p><p> -Before anyone commences an upgrade or an update of Samba, the one cardinal -rule that must be observed is: Backup all Samba configuration files in -case it is necessary to revert to the old version. Even if you do not like -this precautionary step, users will punish an administrator who -fails to take adequate steps to avoid situations that may inflict lost -productivity on them. -</p><div class="warning" title="Warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p> -<a class="indexterm" name="id366163"></a> -<a class="indexterm" name="id366170"></a> -Samba makes it possible to upgrade and update configuration files, but it -is not possible to downgrade the configuration files. Please ensure that -all configuration and control files are backed up to permit a down-grade -in the rare event that this may be necessary. -</p></div><p> -<a class="indexterm" name="id366182"></a> -<a class="indexterm" name="id366189"></a> -It is prudent also to backup all data files on the server before attempting -to perform a major upgrade. Many administrators have experienced the consequences -of failure to take adequate precautions. So what is adequate? That is simple! -If data is lost during an upgrade or update and it can not be restored, -the precautions taken were inadequate. If a backup was not needed, but was available, -caution was on the side of the victor. -</p><div class="sect2" title="Cautions and Notes"><div class="titlepage"><div><div><h3 class="title"><a name="id366200"></a>Cautions and Notes</h3></div></div></div><p> - Someone once said, <span class="quote">“<span class="quote">It is good to be sorry, but better never to need to be!</span>”</span> - These are wise words of advice to those contemplating a Samba upgrade or update. - </p><p> - <a class="indexterm" name="id366216"></a> - <a class="indexterm" name="id366223"></a> - <a class="indexterm" name="id366230"></a> - This is as good a time as any to define the terms <code class="constant">upgrade</code> and - <code class="constant">update</code>. The term <code class="constant">upgrade</code> refers to - the installation of a version of Samba that is a whole generation or more ahead of - that which is installed. Generations are indicated by the first digit of the version - number. So far Samba has been released in generations 1.x, 2.x, 3.x, and currently 4.0 - is in development. - </p><p> - <a class="indexterm" name="id366254"></a> - The term <code class="constant">update</code> refers to a minor version number installation - in place of one of the same generation. For example, updating from Samba 3.0.10 to 3.0.14 - is an update. The move from Samba 2.0.7 to 3.0.14 is an upgrade. - </p><p> - <a class="indexterm" name="id366269"></a> - While the use of these terms is an exercise in semantics, what needs to be realized - is that there are major functional differences between a Samba 2.x release and a Samba - 3.0.x release. Such differences may require a significantly different approach to - solving the same networking challenge and generally require careful review of the - latest documentation to identify precisely how the new installation may need to be - modified to preserve prior functionality. - </p><p> - There is an old axiom that says, <span class="quote">“<span class="quote">The greater the volume of the documentation, - the greater the risk that noone will read it, but where there is no documentation, - noone can read it!</span>”</span> While true, some documentation is an evil necessity. - It is hoped that this update to the documentation will avoid both extremes. - </p><div class="sect3" title="Security Identifiers (SIDs)"><div class="titlepage"><div><div><h4 class="title"><a name="id366291"></a>Security Identifiers (SIDs)</h4></div></div></div><p> - <a class="indexterm" name="id366298"></a> - <a class="indexterm" name="id366308"></a> - <a class="indexterm" name="id366315"></a> - <a class="indexterm" name="id366322"></a> - <a class="indexterm" name="id366328"></a> - <a class="indexterm" name="id366337"></a> - Before the days of Windows NT and OS/2, every Windows and DOS networking client - that used the SMB protocols was an entirely autonomous entity. There was no concept - of a security identifier for a machine or a user outside of the username, the - machine name, and the workgroup name. In actual fact, these were not security identifiers - in the same context as the way that the SID is used since the development of - Windows NT 3.10. - </p><p> - <a class="indexterm" name="id366353"></a> - <a class="indexterm" name="id366360"></a> - <a class="indexterm" name="id366367"></a> - <a class="indexterm" name="id366374"></a> - <a class="indexterm" name="id366380"></a> - <a class="indexterm" name="id366387"></a> - Versions of Samba prior to 1.9 did not make use of a SID. Instead they make exclusive use - of the username that is embedded in the SessionSetUpAndX component of the connection - setup process between a Windows client and an SMB/CIFS server. - </p><p> - <a class="indexterm" name="id366402"></a> - <a class="indexterm" name="id366409"></a> - <a class="indexterm" name="id366415"></a> - Around November 1997 support was added to Samba-1.9 to handle the Windows security - RPC-based protocols that implemented support for Samba to store a machine SID. This - information was stored in a file called <code class="filename">MACHINE.SID.</code> - </p><p> - <a class="indexterm" name="id366433"></a> - <a class="indexterm" name="id366440"></a> - <a class="indexterm" name="id366446"></a> - Within the lifetime of the early Samba 2.x series, the machine SID information was - relocated into a tdb file called <code class="filename">secrets.tdb</code>, which is where - it is still located in Samba 3.0.x along with other information that pertains to the - local machine and its role within a domain security context. - </p><p> - <a class="indexterm" name="id366464"></a> - <a class="indexterm" name="id366474"></a> - <a class="indexterm" name="id366483"></a> - <a class="indexterm" name="id366489"></a> - There are two types of SID, those pertaining to the machine itself and the domain to - which it may belong, and those pertaining to users and groups within the security - context of the local machine, in the case of standalone servers (SAS) and domain member - servers (DMS). - </p><p> - <a class="indexterm" name="id366501"></a> - <a class="indexterm" name="id366508"></a> - <a class="indexterm" name="id366515"></a> - <a class="indexterm" name="id366522"></a> - <a class="indexterm" name="id366529"></a> - <a class="indexterm" name="id366535"></a> - When the Samba <code class="literal">smbd</code> daemon is first started, if the <code class="filename">secrets.tdb</code> - file does not exist, it is created at the first client connection attempt. If this file does - exist, <code class="literal">smbd</code> checks that there is a machine SID (if it is a domain controller, - it searches for the domain SID). If <code class="literal">smbd</code> does not find one for the current - name of the machine or for the current name of the workgroup, a new SID will be generated and - then written to the <code class="filename">secrets.tdb</code> file. The SID is generated in a nondeterminative - manner. This means that each time it is generated for a particular combination of machine name - (hostname) and domain name (workgroup), it will be different. - </p><p> - <a class="indexterm" name="id366580"></a> - The SID is the key used by MS Windows networking for all networking operations. This means - that when the machine or domain SID changes, all security-encoded objects such as profiles - and ACLs may become unusable. - </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> - It is of paramount importance that the machine and domain SID be backed up so that in - the event of a change of hostname (machine name) or domain name (workgroup) the SID can - be restored to its previous value. - </p></div><p> - <a class="indexterm" name="id366598"></a> - <a class="indexterm" name="id366604"></a> - <a class="indexterm" name="id366611"></a> - <a class="indexterm" name="id366617"></a> - <a class="indexterm" name="id366624"></a> - <a class="indexterm" name="id366631"></a> - <a class="indexterm" name="id366638"></a> - <a class="indexterm" name="id366645"></a> - <a class="indexterm" name="id366651"></a> - <a class="indexterm" name="id366658"></a> - In Samba-3 on a domain controller (PDC or BDC), the domain name controls the domain - SID. On all prior versions the hostname (computer name, or NetBIOS name) controlled - the SID. On a standalone server the hostname still controls the SID. - </p><p> - <a class="indexterm" name="id366670"></a> - <a class="indexterm" name="id366679"></a> - The local machine SID can be backed up using this procedure (Samba-3): -</p><pre class="screen"> -<code class="prompt">root# </code> net getlocalsid > /etc/samba/my-local-SID -</pre><p> - The contents of the file <code class="filename">/etc/samba/my-local-SID</code> will be: -</p><pre class="screen"> -SID for domain FRODO is: S-1-5-21-726309263-4128913605-1168186429 -</pre><p> - This SID can be restored by executing: -</p><pre class="screen"> -<code class="prompt">root# </code> net setlocalsid S-1-5-21-726309263-4128913605-1168186429 -</pre><p> - </p><p> - Samba 1.9.x stored the machine SID in the the file <code class="filename">/etc/MACHINE.SID</code> - from which it could be recovered and stored into the <code class="filename">secrets.tdb</code> file - using the procedure shown above. - </p><p> - Where the <code class="filename">secrets.tdb</code> file exists and a version of Samba 2.x or later - has been used, there is no specific need to go through this update process. Samba-3 has the - ability to read the older tdb file and to perform an in-situ update to the latest tdb format. - This is not a reversible process it is a one-way upgrade. - </p><p> - <a class="indexterm" name="id366761"></a> - In the course of the Samba 2.0.x series the <code class="literal">smbpasswd</code> was modified to - permit the domain SID to be captured to the <code class="filename">secrets.tdb</code> file by executing: -</p><pre class="screen"> -<code class="prompt">root# </code> smbpasswd -S PDC -Uadministrator%password -</pre><p> - </p><p> - The release of the Samba 2.2.x series permitted the SID to be obtained by executing: -</p><pre class="screen"> -<code class="prompt">root# </code> smbpasswd -S PDC -Uadministrator%password -</pre><p> - from which the SID could be copied to a file and then written to the Samba-2.2.x - <code class="filename">secrets.tdb</code> file by executing: -</p><pre class="screen"> -<code class="prompt">root# </code> smbpasswd -W S-1-5-21-726309263-4128913605-1168186429 -</pre><p> - </p><p> - <a class="indexterm" name="id366829"></a> - <a class="indexterm" name="id366835"></a> - Domain security information, which includes the domain SID, can be obtained from Samba-2.2.x - systems by executing: -</p><pre class="screen"> -<code class="prompt">root# </code> rpcclient hostname lsaquery -Uroot%password -</pre><p> - This can also be done with Samba-3 by executing: -</p><pre class="screen"> -<code class="prompt">root# </code> net rpc info -Uroot%password -Domain Name: MIDEARTH -Domain SID: S-1-5-21-726309263-4128913605-1168186429 -Sequence number: 1113415916 -Num users: 4237 -Num domain groups: 86 -Num local groups: 0 -</pre><p> - It is a very good practice to store this SID information in a safely kept file, just in - case it is ever needed at a later date. - </p><p> - <a class="indexterm" name="id366877"></a> - <a class="indexterm" name="id366884"></a> - <a class="indexterm" name="id366891"></a> - Take note that the domain SID is used extensively in Samba. Where LDAP is used for the - <em class="parameter"><code>passdb backend</code></em>, all user, group, and trust accounts are encoded - with the domain SID. This means that if the domain SID changes for any reason, the entire - Samba environment can become broken and require extensive corrective action if the - original SID cannot be restored. Fortunately, it can be recovered from a dump of the - LDAP database. A dump of the LDAP directory database can be obtained by executing: -</p><pre class="screen"> -<code class="prompt">root# </code> slapcat -v -l filename.ldif -</pre><p> - </p><p> - <a class="indexterm" name="id366922"></a> - <a class="indexterm" name="id366929"></a> - <a class="indexterm" name="id366936"></a> - When the domain SID has changed, roaming profiles cease to be functional. The recovery - of roaming profiles necessitates resetting of the domain portion of the user SID - that owns the profile. This is encoded in the <code class="filename">NTUser.DAT</code> and can be - updated using the Samba <code class="literal">profiles</code> utility. Please be aware that not all - Linux distributions of the Samba RPMs include this essential utility. Please do not - complain to the Samba Team if this utility is missing; that issue that must be - addressed to the creator of the RPM package. The Samba Team do their best to make - available all the tools needed to manage a Samba-based Windows networking environment. - </p></div><div class="sect3" title="Change of hostname"><div class="titlepage"><div><div><h4 class="title"><a name="id366964"></a>Change of hostname</h4></div></div></div><p> - <a class="indexterm" name="id366972"></a> - <a class="indexterm" name="id366981"></a> - Samba uses two methods by which the primary NetBIOS machine name (also known as a computer - name or the hostname) may be determined: If the <code class="filename">smb.conf</code> file contains a - <em class="parameter"><code>netbios name</code></em> entry, its value will be used directly. In the absence - of such an entry, the UNIX system hostname will be used. - </p><p> - Many sites have become victims of lost Samba functionality because the UNIX system - hostname was changed for one reason or another. Such a change will cause a new machine - SID to be generated. If this happens on a domain controller, it will also change the - domain SID. These SIDs can be updated (restored) using the procedure outlined previously. - </p><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> - Do NOT change the hostname or the <em class="parameter"><code>netbios name</code></em>. If this - is changed, be sure to reset the machine SID to the original setting. Otherwise - there may be serious interoperability and/or operational problems. - </p></div></div><div class="sect3" title="Change of Workgroup (Domain) Name"><div class="titlepage"><div><div><h4 class="title"><a name="id367023"></a>Change of Workgroup (Domain) Name</h4></div></div></div><p> - <a class="indexterm" name="id367030"></a> - The domain name of a Samba server is identical to the workgroup name and is - set in the <code class="filename">smb.conf</code> file using the <em class="parameter"><code>workgroup</code></em> parameter. - This has been consistent throughout the history of Samba and across all versions. - </p><p> - <a class="indexterm" name="id367054"></a> - Be aware that when the workgroup name is changed, a new SID will be generated. - The old domain SID can be reset using the procedure outlined earlier in this chapter. - </p></div><div class="sect3" title="Location of config files"><div class="titlepage"><div><div><h4 class="title"><a name="sbeug1"></a>Location of config files</h4></div></div></div><p> - The Samba-Team has maintained a constant default location for all Samba control files - throughout the life of the project. People who have produced binary packages of Samba - have varied the location of the Samba control files. This has led to some confusion - for network administrators. - </p><p> - <a class="indexterm" name="id367081"></a> - The Samba 1.9.x <code class="filename">smb.conf</code> file may be found either in the <code class="filename">/etc</code> - directory or in <code class="filename">/usr/local/samba/lib</code>. - </p><p> - During the life of the Samba 2.x release, the <code class="filename">smb.conf</code> file was relocated - on Linux systems to the <code class="filename">/etc/samba</code> directory where it - remains located also for Samba 3.0.x installations. - </p><p> - <a class="indexterm" name="id367126"></a> - Samba 2.x introduced the <code class="filename">secrets.tdb</code> file that is also stored in the - <code class="filename">/etc/samba</code> directory, or in the <code class="filename">/usr/local/samba/lib</code> - directory subsystem. - </p><p> - <a class="indexterm" name="id367154"></a> - The location at which <code class="literal">smbd</code> expects to find all configuration and control - files is determined at the time of compilation of Samba. For versions of Samba prior to - 3.0, one way to find the expected location of these files is to execute: -</p><pre class="screen"> -<code class="prompt">root# </code> strings /usr/sbin/smbd | grep conf -<code class="prompt">root# </code> strings /usr/sbin/smbd | grep secret -<code class="prompt">root# </code> strings /usr/sbin/smbd | grep smbpasswd -</pre><p> - Note: The <code class="literal">smbd</code> executable may be located in the path - <code class="filename">/usr/local/samba/sbin</code>. - </p><p> - <a class="indexterm" name="id367209"></a> - Samba-3 provides a neat new way to track the location of all control files as well as to - find the compile-time options used as the Samba package was built. Here is how the dark - secrets of the internals of the location of control files within Samba executables can - be uncovered: -</p><pre class="screen"> -<code class="prompt">root# </code> smbd -b | less -Build environment: - Built by: root@frodo - Built on: Mon Apr 11 20:23:27 MDT 2005 - Built using: gcc - Build host: Linux frodo 2.6... - SRCDIR: /usr/src/packages/BUILD/samba-3.0.20/source - BUILDDIR: /usr/src/packages/BUILD/samba-3.0.20/source - -Paths: - SBINDIR: /usr/sbin - BINDIR: /usr/bin - SWATDIR: /usr/share/samba/swat - CONFIGFILE: /etc/samba/smb.conf - LOGFILEBASE: /var/log/samba - LMHOSTSFILE: /etc/samba/lmhosts - LIBDIR: /usr/lib/samba - SHLIBEXT: so - LOCKDIR: /var/lib/samba - PIDDIR: /var/run/samba - SMB_PASSWD_FILE: /etc/samba/smbpasswd - PRIVATE_DIR: /etc/samba - ... -</pre><p> - </p><p> - <a class="indexterm" name="id367238"></a> - It is important that both the <code class="filename">smb.conf</code> file and the <code class="filename">secrets.tdb</code> - be backed up before attempting any upgrade. The <code class="filename">secrets.tdb</code> file - is version-encoded, and therefore a newer version may not work with an older version - of Samba. A backup means that it is always possible to revert a failed or problematic - upgrade. - </p></div><div class="sect3" title="International Language Support"><div class="titlepage"><div><div><h4 class="title"><a name="id367266"></a>International Language Support</h4></div></div></div><p> - <a class="indexterm" name="id367273"></a> - <a class="indexterm" name="id367280"></a> - <a class="indexterm" name="id367287"></a> - <a class="indexterm" name="id367294"></a> - Samba-2.x had no support for Unicode; instead, all national language character-set support in file names - was done using particular locale codepage mapping techniques. Samba-3 supports Unicode in file names, thus - providing true internationalization support. - </p><p> - <a class="indexterm" name="id367306"></a> - Non-English users whose national language character set has special characters and who upgrade naively will - find that many files that have the special characters in the file name will see them garbled and jumbled up. - This typically happens with umlauts and accents because these characters were particular to the codepage - that was in use with Samba-2.x using an 8-bit encoding scheme. - </p><p> - <a class="indexterm" name="id367320"></a> - Files that are created with Samba-3 will use UTF-8 encoding. Should the file system ever end up with a - mix of codepage (unix charset)-encoded file names and UTF-8-encoded file names, the mess will take some - effort to set straight. - </p><p> - <a class="indexterm" name="id367332"></a> - A very helpful tool is available from Bjorn Jacke's <a class="ulink" href="http://j3e.de/linux/convmv/" target="_top">convmv</a> - work. Convmv is a tool that can be used to convert file and directory names from one encoding method to - another. The most common use for this tool is to convert locale-encoded files to UTF-8 Unicode encoding. - </p></div><div class="sect3" title="Updates and Changes in Idealx smbldap-tools"><div class="titlepage"><div><div><h4 class="title"><a name="id367349"></a>Updates and Changes in Idealx smbldap-tools</h4></div></div></div><p> - The smbldap-tools have been maturing rapidly over the past year. With maturation comes change. - The location of the <code class="filename">smbldap.conf</code> and the <code class="filename">smbldap_bind.conf</code> - configuration files have been moved from the directory <code class="filename">/etc/smbldap-tools</code> to - the new location of <code class="filename">/etc/opt/IDEALX/smblda-tools</code> directory. - </p><p> - The smbldap-tools maintains an entry in the LDAP directory in which it stores the next - values that should be used for UID and GID allocation for POSIX accounts that are created - using this tool. The DIT location of these values has changed recently. The original - <code class="constant">sambaUnixIdPooldn object</code> entity was stored in a directory entry (DIT object) - called <code class="constant">NextFreeUnixId</code>, this has been changed to the DIT object - <code class="constant">sambaDomainName</code>. Anyone who updates from an older version to the - current release should note that the information stored under <code class="constant">NextFreeUnixId</code> - must now be relocated to the DIT object <code class="constant">sambaDomainName</code>. - </p></div></div></div><div class="sect1" title="Upgrading from Samba 1.x and 2.x to Samba-3"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id367413"></a>Upgrading from Samba 1.x and 2.x to Samba-3</h2></div></div></div><p> -Sites that are being upgraded from Samba-2 (or earlier versions) to Samba-3 -may experience little difficulty or may require a lot of effort, depending -on the complexity of the configuration. Samba-1.9.x upgrades to Samba-3 will -generally be simple and straightforward, although no upgrade should be -attempted without proper planning and preparation. -</p><p> -There are two basic modes of use of Samba versions prior to Samba-3. The first -does not use LDAP, the other does. Samba-1.9.x did not provide LDAP support. -Samba-2.x could be compiled with LDAP support. -</p><div class="sect2" title="Samba 1.9.x and 2.x Versions Without LDAP"><div class="titlepage"><div><div><h3 class="title"><a name="sbeug2"></a>Samba 1.9.x and 2.x Versions Without LDAP</h3></div></div></div><p> - Where it is necessary to upgrade an old Samba installation to Samba-3, - the following procedure can be followed: - </p><div class="procedure" title="Procedure 8.1. Upgrading from a Pre-Samba-3 Version"><a name="id367444"></a><p class="title"><b>Procedure 8.1. Upgrading from a Pre-Samba-3 Version</b></p><ol class="procedure" type="1"><li class="step" title="Step 1"><p> - <a class="indexterm" name="id367455"></a> - <a class="indexterm" name="id367462"></a> - <a class="indexterm" name="id367468"></a> - Stop Samba. This can be done using the appropriate system tool - that is particular for each operating system or by executing the - <code class="literal">kill</code> command on <code class="literal">smbd</code>, - <code class="literal">nmbd</code>, and <code class="literal">winbindd</code>. - </p></li><li class="step" title="Step 2"><p> - Find the location of the Samba <code class="filename">smb.conf</code> file and back it up to a - safe location. - </p></li><li class="step" title="Step 3"><p> - Find the location of the <code class="filename">smbpasswd</code> file and - back it up to a safe location. - </p></li><li class="step" title="Step 4"><p> - Find the location of the <code class="filename">secrets.tdb</code> file and - back it up to a safe location. - </p></li><li class="step" title="Step 5"><p> - <a class="indexterm" name="id367546"></a> - <a class="indexterm" name="id367553"></a> - <a class="indexterm" name="id367560"></a> - <a class="indexterm" name="id367567"></a> - Find the location of the lock directory. This is the directory - in which Samba stores all its tdb control files. The default - location used by the Samba Team is in - <code class="filename">/usr/local/samba/var/locks</code> directory, - but on Linux systems the old location was under the - <code class="filename">/var/cache/samba</code> directory. However, the - Linux Standards Base specified location is now under the - <code class="filename">/var/lib/samba</code> directory. Copy all the - tdb files to a safe location. - </p></li><li class="step" title="Step 6"><p> - <a class="indexterm" name="id367601"></a> - It is now safe to upgrade the Samba installation. On Linux systems - it is not necessary to remove the Samba RPMs because a simple - upgrade installation will automatically remove the old files. - </p><p> - On systems that do not support a reliable package management system - it is advisable either to delete the Samba old installation or to - move it out of the way by renaming the directories that contain the - Samba binary files. - </p></li><li class="step" title="Step 7"><p> - When the Samba upgrade has been installed, the first step that should - be completed is to identify the new target locations for the control - files. Follow the steps shown in <a class="link" href="upgrades.html#sbeug1" title="Location of config files">“Location of config files”</a> to locate - the correct directories to which each control file must be moved. - </p></li><li class="step" title="Step 8"><p> - Do not change the hostname. - </p></li><li class="step" title="Step 9"><p> - Do not change the workgroup name. - </p></li><li class="step" title="Step 10"><p> - <a class="indexterm" name="id367650"></a> - Execute the <code class="literal">testparm</code> to validate the <code class="filename">smb.conf</code> file. - This process will flag any parameters that are no longer supported. - It will also flag configuration settings that may be in conflict. - </p><p> - One solution that may be used to clean up and to update the <code class="filename">smb.conf</code> - file involves renaming it to <code class="filename">smb.conf.master</code> and - then executing the following: -</p><pre class="screen"> -<code class="prompt">root# </code> cd /etc/samba -<code class="prompt">root# </code> testparm -s smb.conf.master > smb.conf -</pre><p> - <a class="indexterm" name="id367704"></a> - The resulting <code class="filename">smb.conf</code> file will be stripped of all comments - and of all nonconforming configuration settings. - </p></li><li class="step" title="Step 11"><p> - <a class="indexterm" name="id367725"></a> - It is now safe to start Samba using the appropriate system tool. - Alternately, it is possible to just execute <code class="literal">nmbd</code>, - <code class="literal">smbd</code>, and <code class="literal">winbindd</code> for the command - line while logged in as the root user. - </p></li></ol></div></div><div class="sect2" title="Applicable to All Samba 2.x to Samba-3 Upgrades"><div class="titlepage"><div><div><h3 class="title"><a name="id367754"></a>Applicable to All Samba 2.x to Samba-3 Upgrades</h3></div></div></div><p> - <a class="indexterm" name="id367762"></a> - <a class="indexterm" name="id367769"></a> - <a class="indexterm" name="id367776"></a> - Samba 2.x servers that were running as a domain controller (PDC) - require changes to the configuration of the scripting interface - tools that Samba uses to perform OS updates for - users, groups, and trust accounts (machines and interdomain). - </p><p> - <a class="indexterm" name="id367788"></a> - The following parameters are new to Samba-3 and should be correctly configured. - Please refer to <a class="link" href="secure.html" title="Chapter 3. Secure Office Networking">“Secure Office Networking”</a> through <a class="link" href="net2000users.html" title="Chapter 6. A Distributed 2000-User Network">“A Distributed 2000-User Network”</a> - in this book for examples of use of the new parameters shown here: - <a class="indexterm" name="id367807"></a> - <a class="indexterm" name="id367814"></a> - <a class="indexterm" name="id367821"></a> - <a class="indexterm" name="id367828"></a> - <a class="indexterm" name="id367834"></a> - <a class="indexterm" name="id367841"></a> - <a class="indexterm" name="id367848"></a> - </p><p> - </p><table border="0" summary="Simple list" class="simplelist"><tr><td>add group script</td></tr><tr><td>add machine script</td></tr><tr><td>add user to group script</td></tr><tr><td>delete group script</td></tr><tr><td>delete user from group script</td></tr><tr><td>passdb backend</td></tr><tr><td>set primary group script</td></tr></table><p> - </p><p> - <a class="indexterm" name="id367892"></a> - <a class="indexterm" name="id367898"></a> - The <em class="parameter"><code>add machine script</code></em> functionality was previously - handled by the <em class="parameter"><code>add user script</code></em>, which in Samba-3 is - used exclusively to add user accounts. - </p><p> - <a class="indexterm" name="id367921"></a> - <a class="indexterm" name="id367928"></a> - <a class="indexterm" name="id367935"></a> - <a class="indexterm" name="id367942"></a> - <a class="indexterm" name="id367948"></a> - <a class="indexterm" name="id367955"></a> - <a class="indexterm" name="id367962"></a> - <a class="indexterm" name="id367969"></a> - <a class="indexterm" name="id367976"></a> - Where the <em class="parameter"><code>passdb backend</code></em> used is either <code class="constant">smbpasswd</code> - (the default) or the new <code class="constant">tdbsam</code>, the system interface scripts - are typically used. These involve use of OS tools such as <code class="literal">useradd</code>, - <code class="literal">usermod</code>, <code class="literal">userdel</code>, <code class="literal">groupadd</code>, - <code class="literal">groupmod</code>, <code class="literal">groupdel</code>, and so on. - </p><p> - <a class="indexterm" name="id368035"></a> - <a class="indexterm" name="id368042"></a> - <a class="indexterm" name="id368048"></a> - Where the <em class="parameter"><code>passdb backend</code></em> makes use of an LDAP directory, - it is necessary either to use the <code class="constant">smbldap-tools</code> provided - by Idealx or to use an alternate toolset provided by a third - party or else home-crafted to manage the LDAP directory accounts. - </p></div><div class="sect2" title="Samba-2.x with LDAP Support"><div class="titlepage"><div><div><h3 class="title"><a name="id368069"></a>Samba-2.x with LDAP Support</h3></div></div></div><p> - Samba version 2.x could be compiled for use either with or without LDAP. - The LDAP control settings in the <code class="filename">smb.conf</code> file in this old version are - completely different (and less complete) than they are with Samba-3. This - means that after migrating the control files, it is necessary to reconfigure - the LDAP settings entirely. - </p><p> - Follow the procedure outlined in <a class="link" href="upgrades.html#sbeug2" title="Samba 1.9.x and 2.x Versions Without LDAP">“Samba 1.9.x and 2.x Versions Without LDAP”</a> to affect a migration - of all files to the correct locations. - </p><p> - <a class="indexterm" name="id368099"></a> - <a class="indexterm" name="id368106"></a> - The Samba SAM schema required for Samba-3 is significantly different from that - used with Samba 2.x. This means that the LDAP directory must be updated - using the procedure outlined in the Samba WHATSNEW.txt file that accompanies - all releases of Samba-3. This information is repeated here directly from this - file: -</p><pre class="screen"> -This is an extract from the Samba-3.0.x WHATSNEW.txt file: -========================================================== -Changes in Behavior -------------------- - -The following issues are known changes in behavior between Samba 2.2 and -Samba 3.0 that may affect certain installations of Samba. - - 1) When operating as a member of a Windows domain, Samba 2.2 would - map any users authenticated by the remote DC to the 'guest account' - if a uid could not be obtained via the getpwnam() call. Samba 3.0 - rejects the connection as NT_STATUS_LOGON_FAILURE. There is no - current work around to re-establish the 2.2 behavior. - - 2) When adding machines to a Samba 2.2 controlled domain, the - 'add user script' was used to create the UNIX identity of the - machine trust account. Samba 3.0 introduces a new 'add machine - script' that must be specified for this purpose. Samba 3.0 will - not fall back to using the 'add user script' in the absence of - an 'add machine script' - -###################################################################### -Passdb Backends and Authentication -################################## - -There have been a few new changes that Samba administrators should be -aware of when moving to Samba 3.0. - - 1) encrypted passwords have been enabled by default in order to - inter-operate better with out-of-the-box Windows client - installations. This does mean that either (a) a samba account - must be created for each user, or (b) 'encrypt passwords = no' - must be explicitly defined in smb.conf. - - 2) Inclusion of new 'security = ads' option for integration - with an Active Directory domain using the native Windows - Kerberos 5 and LDAP protocols. - - MIT kerberos 1.3.1 supports the ARCFOUR-HMAC-MD5 encryption - type which is necessary for servers on which the - administrator password has not been changed, or kerberos-enabled - SMB connections to servers that require Kerberos SMB signing. - Besides this one difference, either MIT or Heimdal Kerberos - distributions are usable by Samba 3.0. - - -Samba 3.0 also includes the possibility of setting up chains -of authentication methods (auth methods) and account storage -backends (passdb backend). Please refer to the smb.conf(5) -man page for details. While both parameters assume sane default -values, it is likely that you will need to understand what the -values actually mean in order to ensure Samba operates correctly. - -The recommended passdb backends at this time are - - * smbpasswd - 2.2 compatible flat file format - * tdbsam - attribute rich database intended as an smbpasswd - replacement for stand alone servers - * ldapsam - attribute rich account storage and retrieval - backend utilizing an LDAP directory. - * ldapsam_compat - a 2.2 backward compatible LDAP account - backend - -Certain functions of the smbpasswd(8) tool have been split between the -new smbpasswd(8) utility, the net(8) tool, and the new pdbedit(8) -utility. See the respective man pages for details. - -###################################################################### -LDAP -#### - -This section outlines the new features affecting Samba / LDAP -integration. - -New Schema ----------- - -A new object class (sambaSamAccount) has been introduced to replace -the old sambaAccount. This change aids us in the renaming of -attributes to prevent clashes with attributes from other vendors. -There is a conversion script (examples/LDAP/convertSambaAccount) to -modify and LDIF file to the new schema. - -Example: - - $ ldapsearch .... -b "ou=people,dc=..." > sambaAcct.ldif - $ convertSambaAccount --sid=<Domain SID> \ - --input=sambaAcct.ldif --output=sambaSamAcct.ldif \ - --changetype=[modify|add] - -The <DOM SID> can be obtained by running 'net getlocalsid -<DOMAINNAME>' on the Samba PDC as root. The changetype determines -the format of the generated LDIF output--either create new entries -or modify existing entries. - -The old sambaAccount schema may still be used by specifying the -"ldapsam_compat" passdb backend. However, the sambaAccount and -associated attributes have been moved to the historical section of -the schema file and must be uncommented before use if needed. -The 2.2 object class declaration for a sambaAccount has not changed -in the 3.0 samba.schema file. - -Other new object classes and their uses include: - - * sambaDomain - domain information used to allocate rids - for users and groups as necessary. The attributes are added - in 'ldap suffix' directory entry automatically if - an idmap uid/gid range has been set and the 'ldapsam' - passdb backend has been selected. - - * sambaGroupMapping - an object representing the - relationship between a posixGroup and a Windows - group/SID. These entries are stored in the 'ldap - group suffix' and managed by the 'net groupmap' command. - - * sambaUnixIdPool - created in the 'ldap idmap suffix' entry - automatically and contains the next available 'idmap uid' and - 'idmap gid' - - * sambaIdmapEntry - object storing a mapping between a - SID and a UNIX uid/gid. These objects are created by the - idmap_ldap module as needed. - - * sambaSidEntry - object representing a SID alone, as a Structural - class on which to build the sambaIdmapEntry. - - -New Suffix for Searching ------------------------- - -The following new smb.conf parameters have been added to aid in directing -certain LDAP queries when 'passdb backend = ldapsam://...' has been -specified. - - * ldap suffix - used to search for user and computer accounts - * ldap user suffix - used to store user accounts - * ldap machine suffix - used to store machine trust accounts - * ldap group suffix - location of posixGroup/sambaGroupMapping entries - * ldap idmap suffix - location of sambaIdmapEntry objects - -If an 'ldap suffix' is defined, it will be appended to all of the -remaining sub-suffix parameters. In this case, the order of the suffix -listings in smb.conf is important. Always place the 'ldap suffix' first -in the list. - -Due to a limitation in Samba's smb.conf parsing, you should not surround -the DN's with quotation marks. -</pre><p> - </p></div></div><div class="sect1" title="Updating a Samba-3 Installation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id368184"></a>Updating a Samba-3 Installation</h2></div></div></div><p> -The key concern in this section is to deal with the changes that have been -affected in Samba-3 between the Samba-3.0.0 release and the current update. -Network administrators have expressed concerns over the steps that should be -taken to update Samba-3 versions. -</p><p> -<a class="indexterm" name="id368197"></a> -The information in <a class="link" href="upgrades.html#sbeug1" title="Location of config files">“Location of config files”</a> would not be necessary if every -person who has ever produced Samba executable (binary) files could agree on -the preferred location of the <code class="filename">smb.conf</code> file and other Samba control files. -Clearly, such agreement is further away than a pipedream. -</p><p> -<a class="indexterm" name="id368220"></a> -Vendors and packagers who produce Samba binary installable packages do not, -as a rule, use the default paths used by the Samba-Team for the location of -the binary files, the <code class="filename">smb.conf</code> file, and the Samba control files (tdb's -as well as files such as <code class="filename">secrets.tdb</code>). This means that -the network or UNIX administrator who sets out to build the Samba executable -files from the Samba tarball must take particular care. Failure to take care -will result in both the original vendor's version of Samba remaining installed -and the new version being installed in the default location used -by the Samba-Team. This can lead to confusion and to much lost time as the -uninformed administrator deals with apparent failure of the update to take -effect. -</p><p> -<a class="indexterm" name="id368248"></a> -The best advice for those lacking in code compilation experience is to use -only vendor (or Samba-Team) provided binary packages. The Samba packages -that are provided by the Samba-Team are generally built to use file paths -that are compatible with the original OS vendor's practices. -</p><p> -<a class="indexterm" name="id368261"></a> -<a class="indexterm" name="id368268"></a> -If you are not sure whether a binary package complies with the OS -vendor's practices, it is better to ask the package maintainer via -email than to waste much time dealing with the nuances. -Alternately, just diagnose the paths specified by the binary files following -the procedure outlined above. -</p><div class="sect2" title="Samba-3 to Samba-3 Updates on the Same Server"><div class="titlepage"><div><div><h3 class="title"><a name="id368281"></a>Samba-3 to Samba-3 Updates on the Same Server</h3></div></div></div><p> - The guidance in this section deals with updates to an existing - Samba-3 server installation. - </p><div class="sect3" title="Updating from Samba Versions Earlier than 3.0.5"><div class="titlepage"><div><div><h4 class="title"><a name="id368291"></a>Updating from Samba Versions Earlier than 3.0.5</h4></div></div></div><p> - With the provision that the binary Samba-3 package has been built - with the same path and feature settings as the existing Samba-3 - package that is being updated, an update of Samba-3 versions 3.0.0 - through 3.0.4 can be updated to 3.0.5 without loss of functionality - and without need to change either the <code class="filename">smb.conf</code> file or, where - used, the LDAP schema. - </p></div><div class="sect3" title="Updating from Samba Versions between 3.0.6 and 3.0.10"><div class="titlepage"><div><div><h4 class="title"><a name="id368310"></a>Updating from Samba Versions between 3.0.6 and 3.0.10</h4></div></div></div><p> - <a class="indexterm" name="id368318"></a> - <a class="indexterm" name="id368324"></a> - When updating versions of Samba-3 prior to 3.0.6 to 3.0.6 through 3.0.10, - it is necessary only to update the LDAP schema (where LDAP is used). - Always use the LDAP schema file that is shipped with the latest Samba-3 - update. - </p><p> - <a class="indexterm" name="id368339"></a> - <a class="indexterm" name="id368346"></a> - <a class="indexterm" name="id368352"></a> - Samba-3.0.6 introduced the ability to remember the last <span class="emphasis"><em>n</em></span> number - of passwords a user has used. This information will work only with - the <code class="constant">tdbsam</code> and <code class="constant">ldapsam</code> - <em class="parameter"><code>passdb backend</code></em> facilities. - </p><p> - After updating the LDAP schema, do not forget to re-index the LDAP database. - </p></div><div class="sect3" title="Updating from Samba Versions after 3.0.6 to a Current Release"><div class="titlepage"><div><div><h4 class="title"><a name="id368384"></a>Updating from Samba Versions after 3.0.6 to a Current Release</h4></div></div></div><p> - <a class="indexterm" name="id368392"></a> - Samba-3.0.8 introduced changes in how the <em class="parameter"><code>username map</code></em> - behaves. It also included a change in behavior of <code class="literal">winbindd</code>. - Please refer to the man page for <code class="filename">smb.conf</code> before implementing any update - from versions prior to 3.0.8 to a current version. - </p><p> - <a class="indexterm" name="id368421"></a> - In Samba-3.0.11 a new privileges interface was implemented. Please - refer to <a class="link" href="happy.html#sbehap-ppc" title="Addition of Machines to the Domain">“Addition of Machines to the Domain”</a> for information regarding this new - feature. It is not necessary to implement the privileges interface, but it - is one that has been requested for several years and thus may be of interest - at your site. - </p><p> - In Samba-3.0.11 there were some functional changes to the <em class="parameter"><code>ldap user - suffix</code></em> and to the <em class="parameter"><code>ldap machine suffix</code></em> behaviors. - The following information has been extracted from the WHATSNEW.txt file from this - release: -</p><pre class="screen"> -============ -LDAP Changes -============ - -If "ldap user suffix" or "ldap machine suffix" are defined in -smb.conf, all user-accounts must reside below the user suffix, -and all machine and inter-domain trust-accounts must be located -below the machine suffix. Previous Samba releases would fall -back to searching the 'ldap suffix' in some cases. -</pre><p> - </p></div></div><div class="sect2" title="Migrating Samba-3 to a New Server"><div class="titlepage"><div><div><h3 class="title"><a name="id368465"></a>Migrating Samba-3 to a New Server</h3></div></div></div><p> - The two most likely candidates for replacement of a server are - domain member servers and domain controllers. Each needs to be - handled slightly differently. - </p><div class="sect3" title="Replacing a Domain Member Server"><div class="titlepage"><div><div><h4 class="title"><a name="id368475"></a>Replacing a Domain Member Server</h4></div></div></div><p> - <a class="indexterm" name="id368483"></a> - Replacement of a domain member server should be done - using the same procedure as outlined in <a class="link" href="unixclients.html" title="Chapter 7. Adding Domain Member Servers and Clients">“Adding Domain Member Servers and Clients”</a>. - </p><p> - Usually the new server will be introduced with a temporary name. After - the old server data has been migrated to the new server, it is customary - that the new server be renamed to that of the old server. This will - change its SID and will necessitate rejoining to the domain. - </p><p> - <a class="indexterm" name="id368506"></a> - <a class="indexterm" name="id368512"></a> - <a class="indexterm" name="id368519"></a> - <a class="indexterm" name="id368526"></a> - <a class="indexterm" name="id368532"></a> - <a class="indexterm" name="id368539"></a> - Following a change of hostname (NetBIOS name) it is a good idea on all servers - to shut down the Samba <code class="literal">smbd</code>, <code class="literal">nmbd</code>, and - <code class="literal">winbindd</code> services, delete the <code class="filename">wins.dat</code> - and <code class="filename">browse.dat</code> files, then restart Samba. This will ensure - that the old name and IP address information is no longer able to interfere with - name to IP address resolution. If this is not done, there can be temporary name - resolution problems. These problems usually clear within 45 minutes of a name - change, but can persist for a longer period of time. - </p><p> - <a class="indexterm" name="id368583"></a> - <a class="indexterm" name="id368589"></a> - <a class="indexterm" name="id368596"></a> - <a class="indexterm" name="id368603"></a> - If the old domain member server had local accounts, it is necessary to create - on the new domain member server the same accounts with the same UID and GID - for each account. Where the <em class="parameter"><code>passdb backend</code></em> database - is stored in the <code class="constant">smbpasswd</code> or in the - <code class="constant">tdbsam</code> format, the user and group account information - for UNIX accounts that match the Samba accounts will reside in the system - <code class="filename">/etc/passwd</code>, <code class="filename">/etc/shadow</code>, and - <code class="filename">/etc/group</code> files. In this case, be sure to copy these - account entries to the new target server. - </p><p> - <a class="indexterm" name="id368648"></a> - Where the user accounts for both UNIX and Samba are stored in LDAP, the new - target server must be configured to use the <code class="literal">nss_ldap</code> tool set. - This will automatically ensure that the appropriate user entities are - available on the new server. - </p></div><div class="sect3" title="Replacing a Domain Controller"><div class="titlepage"><div><div><h4 class="title"><a name="id368664"></a>Replacing a Domain Controller</h4></div></div></div><p> - <a class="indexterm" name="id368672"></a> - In the past, people who replaced a Windows NT4 domain controller typically - installed a new server, created printers and file shares on it, then migrate across - all data that was destined to reside on it. The same can of course be done with - Samba. - </p><p> - From recent mailing list postings it would seem that some administrators - have the intent to just replace the old Samba server with a new one with - the same name as the old one. In this case, simply follow the same process - as for upgrading a Samba 2.x system and do the following: - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - Where UNIX (POSIX) user and group accounts are stored in the system - <code class="filename">/etc/passwd</code>, <code class="filename">/etc/shadow</code>, and - <code class="filename">/etc/group</code> files, be sure to add the same accounts - with identical UID and GID values for each user. - </p><p> - Where LDAP is used, if the new system is intended to be the LDAP server, - migrate it across by configuring the LDAP server - (<code class="filename">/etc/openldap/slapd.conf</code>). The directory can - be populated either initially by setting this LDAP server up as a slave or - by dumping the data from the old LDAP server using the <code class="literal">slapcat</code> - command and then reloading the same data into the new LDAP server using the - <code class="literal">slapadd</code> command. Do not forget to install and configure - the <code class="literal">nss_ldap</code> tool and the <code class="filename">/etc/nsswitch.conf</code> - (as shown in <a class="link" href="happy.html" title="Chapter 5. Making Happy Users">“Making Happy Users”</a>). - </p></li><li class="listitem"><p> - Copy the <code class="filename">smb.conf</code> file from the old server to the new server into the correct - location as indicated previously in this chapter. - </p></li><li class="listitem"><p> - Copy the <code class="filename">secrets.tdb</code> file, the <code class="filename">smbpasswd</code> - file (if it is used), the <code class="filename">/etc/samba/passdb.tdb</code> file (only - used by the <code class="constant">tdbsam</code> backend), and all the tdb control files - from the old system to the correct location on the new system. - </p></li><li class="listitem"><p> - Before starting the Samba daemons, verify that the hostname of the new server - is identical to that of the old one. Note: The IP address can be different - from that of the old server. - </p></li><li class="listitem"><p> - Copy all files from the old server to the new server, taking precaution to - preserve all file ownership and permissions as well as any POSIX ACLs that - may have been created on the old server. - </p></li></ul></div><p> - When replacing a Samba domain controller (PDC or BDC) that uses LDAP, the new server - need simply be configured to use the LDAP directory, and for the rest it should just - work. The domain SID is obtained from the LDAP directory as part of the first connect - to the LDAP directory server. - </p><p> - All Samba servers, other than one that uses LDAP, depend on the tdb files, and - particularly on the <code class="filename">secrets.tdb</code> file. So long as the tdb files are - all in place, the <code class="filename">smb.conf</code> file is preserved, and either the hostname is identical - or the <em class="parameter"><code>netbios name</code></em> is set to the original server name, Samba - should correctly pick up the original SID and preserve all other settings. It is - sound advice to validate this before turning the system over to users. - </p></div></div><div class="sect2" title="Migration of Samba Accounts to Active Directory"><div class="titlepage"><div><div><h3 class="title"><a name="id368842"></a>Migration of Samba Accounts to Active Directory</h3></div></div></div><p> - Yes, it works. The Windows ADMT tool can be used to migrate Samba accounts - to MS Active Directory. There are a few pitfalls to be aware of: - </p><div class="procedure" title="Procedure 8.2. Migration to Active Directory"><a name="id368853"></a><p class="title"><b>Procedure 8.2. Migration to Active Directory</b></p><ol class="procedure" type="1"><li class="step" title="Step 1"><p> - Administrator password must be THE SAME on the Samba server, - the 2003 ADS, and the local Administrator account on the workstations. - Perhaps this goes without saying, but there needs to be an account - called <code class="constant">Administrator</code> in your Samba domain, with - full administrative (root) rights to that domain. - </p></li><li class="step" title="Step 2"><p> - In the Advanced/DNS section of the TCP/IP settings on your Windows - workstations, make sure the <em class="parameter"><code>DNS suffix for this - connection</code></em> field is blank. - </p></li><li class="step" title="Step 3"><p> - Because you are migrating from Samba, user passwords cannot be - migrated. You'll have to reset everyone's passwords. (If you were - migrating from NT4 to ADS, you could migrate passwords as well.) - </p><p> - To date this has not been attempted with roaming profile support; - it has been documented as working with local profiles. - </p></li><li class="step" title="Step 4"><p> - Disable the Windows Firewall on all workstations. Otherwise, - workstations won't be migrated to the new domain. - </p></li><li class="step" title="Step 5"><p> - <a class="indexterm" name="id368911"></a> - When migrating machines, always test first (using ADMT's test mode) - and satisfy all errors before committing the migration. Note that the - test will always fail, because the machine will not have been actually - migrated. You'll need to interpret the errors to know whether the - failure was due to a problem or simply to the fact that it was just - a test. - </p></li></ol></div><p> - <a class="indexterm" name="id368925"></a> - There are some significant benefits of using the ADMT, besides just - migrating user accounts. ADMT can be found on the Windows 2003 CD. - </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> - You can migrate workstations remotely. You can specify that SIDs - be simply added instead of replaced, giving you the option of joining a - workstation back to the old domain if something goes awry. The - workstations will be joined to the new domain. - </p></li><li class="listitem"><p> - Not only are user accounts migrated from the old domain to the new - domain, but ACLs on the workstations are migrated as well. Like SIDs, - ACLs can be added instead of replaced. - </p></li><li class="listitem"><p> - Locally stored user profiles on workstations are migrated as well, - presenting almost no disruption to the user. Saved passwords will be - lost, just as when you administratively reset the password in Windows ADS. - </p></li><li class="listitem"><p> - The ADMT lets you test all operations before actually performing the - migration. Accounts and workstations can be migrated individually or in - batches. User accounts can be safely migrated all at once (since no - changes are made on the original domain). It is recommended to migrate only one - or two workstations as a test before committing them all. - </p></li></ul></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="unixclients.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="DMSMig.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ntmigration.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 7. Adding Domain Member Servers and Clients </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 9. Migrating NT4 Domain to Samba-3</td></tr></table></div></body></html> |