--- /dev/null
+<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.68.1"><link rel="start" 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" lang="en"><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#id2566198">Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="upgrades.html#id2566294">Cautions and Notes</a></span></dt></dl></dd><dt><span class="sect1"><a href="upgrades.html#id2567617">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#id2567985">Applicable to All Samba 2.x to Samba-3 Upgrades</a></span></dt><dt><span class="sect2"><a href="upgrades.html#id2568319">Samba-2.x with LDAP Support</a></span></dt></dl></dd><dt><span class="sect1"><a href="upgrades.html#id2568500">Updating a Samba-3 Installation</a></span></dt><dd><dl><dt><span class="sect2"><a href="upgrades.html#id2568616">Samba-3 to Samba-3 Updates on the Same Server</a></span></dt><dt><span class="sect2"><a href="upgrades.html#id2568819">Migrating Samba-3 to a New Server</a></span></dt><dt><span class="sect2"><a href="upgrades.html#id2569238">Migration of Samba Accounts to Active Directory</a></span></dt></dl></dd></dl></div><p>
+<a class="indexterm" name="id2566114"></a>
+<a class="indexterm" name="id2566120"></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="id2566137"></a>
+<a class="indexterm" name="id2566144"></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="id2566165"></a>
+I like the “<span class="quote">net rpc vampire</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="id2566186"></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" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2566198"></a>Introduction</h2></div></div></div><p>
+<a class="indexterm" name="id2566206"></a>
+<a class="indexterm" name="id2566212"></a>
+<a class="indexterm" name="id2566219"></a>
+A Windows network administrator explained in an email what changes he was
+planning to make and followed with the question: “<span class="quote">Anyone done this
+before?</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" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>
+<a class="indexterm" name="id2566250"></a>
+<a class="indexterm" name="id2566257"></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="id2566272"></a>
+<a class="indexterm" name="id2566279"></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" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2566294"></a>Cautions and Notes</h3></div></div></div><p>
+ Someone once said, “<span class="quote">It is good to be sorry, but better never to need to be!</span>”
+ These are wise words of advice to those contemplating a Samba upgrade or update.
+ </p><p>
+ <a class="indexterm" name="id2566312"></a>
+ <a class="indexterm" name="id2566318"></a>
+ <a class="indexterm" name="id2566325"></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="id2566352"></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="id2566370"></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">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>” 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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2566398"></a>Security Identifiers (SIDs)</h4></div></div></div><p>
+ <a class="indexterm" name="id2566406"></a>
+ <a class="indexterm" name="id2566415"></a>
+ <a class="indexterm" name="id2566422"></a>
+ <a class="indexterm" name="id2566428"></a>
+ <a class="indexterm" name="id2566435"></a>
+ <a class="indexterm" name="id2566444"></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="id2566464"></a>
+ <a class="indexterm" name="id2566470"></a>
+ <a class="indexterm" name="id2566477"></a>
+ <a class="indexterm" name="id2566484"></a>
+ <a class="indexterm" name="id2566490"></a>
+ <a class="indexterm" name="id2566497"></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="id2566514"></a>
+ <a class="indexterm" name="id2566521"></a>
+ <a class="indexterm" name="id2566527"></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="id2566547"></a>
+ <a class="indexterm" name="id2566553"></a>
+ <a class="indexterm" name="id2566560"></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="id2566581"></a>
+ <a class="indexterm" name="id2566590"></a>
+ <a class="indexterm" name="id2566599"></a>
+ <a class="indexterm" name="id2566606"></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="id2566621"></a>
+ <a class="indexterm" name="id2566628"></a>
+ <a class="indexterm" name="id2566634"></a>
+ <a class="indexterm" name="id2566641"></a>
+ <a class="indexterm" name="id2566648"></a>
+ <a class="indexterm" name="id2566654"></a>
+ When the Samba <span><strong class="command">smbd</strong></span> 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, <span><strong class="command">smbd</strong></span> checks that there is a machine SID (if it is a domain controller,
+ it searches for the domain SID). If <span><strong class="command">smbd</strong></span> 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="id2566704"></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" 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="id2566726"></a>
+ <a class="indexterm" name="id2566733"></a>
+ <a class="indexterm" name="id2566739"></a>
+ <a class="indexterm" name="id2566746"></a>
+ <a class="indexterm" name="id2566752"></a>
+ <a class="indexterm" name="id2566759"></a>
+ <a class="indexterm" name="id2566766"></a>
+ <a class="indexterm" name="id2566773"></a>
+ <a class="indexterm" name="id2566780"></a>
+ <a class="indexterm" name="id2566787"></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="id2566800"></a>
+ <a class="indexterm" name="id2566809"></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="id2566898"></a>
+ In the course of the Samba 2.0.x series the <span><strong class="command">smbpasswd</strong></span> 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="id2566972"></a>
+ <a class="indexterm" name="id2566978"></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="id2567025"></a>
+ <a class="indexterm" name="id2567032"></a>
+ <a class="indexterm" name="id2567039"></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="id2567075"></a>
+ <a class="indexterm" name="id2567081"></a>
+ <a class="indexterm" name="id2567088"></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 <span><strong class="command">profiles</strong></span> 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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2567119"></a>Change of hostname</h4></div></div></div><p>
+ <a class="indexterm" name="id2567127"></a>
+ <a class="indexterm" name="id2567136"></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" 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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2567185"></a>Change of Workgroup (Domain) Name</h4></div></div></div><p>
+ <a class="indexterm" name="id2567193"></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="id2567218"></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" lang="en"><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="id2567250"></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="id2567296"></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="id2567326"></a>
+ The location at which <span><strong class="command">smbd</strong></span> 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 <span><strong class="command">smbd</strong></span> executable may be located in the path
+ <code class="filename">/usr/local/samba/sbin</code>.
+ </p><p>
+ <a class="indexterm" name="id2567384"></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="id2567421"></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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2567451"></a>International Language Support</h4></div></div></div><p>
+ <a class="indexterm" name="id2567459"></a>
+ <a class="indexterm" name="id2567466"></a>
+ <a class="indexterm" name="id2567473"></a>
+ <a class="indexterm" name="id2567480"></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="id2567495"></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="id2567511"></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="id2567526"></a>
+ A very helpful tool is available from Bjorn Jacke's <a 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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2567545"></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" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2567617"></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" lang="en"><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"><a name="id2567654"></a><p class="title"><b>Procedure 8.1. Upgrading from a Pre-Samba-3 Version</b></p><ol type="1"><li><p>
+ <a class="indexterm" name="id2567666"></a>
+ <a class="indexterm" name="id2567673"></a>
+ <a class="indexterm" name="id2567679"></a>
+ Stop Samba. This can be done using the appropriate system tool
+ that is particular for each operating system or by executing the
+ <span><strong class="command">kill</strong></span> command on <span><strong class="command">smbd</strong></span>,
+ <span><strong class="command">nmbd</strong></span>, and <span><strong class="command">winbindd</strong></span>.
+ </p></li><li><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><p>
+ Find the location of the <code class="filename">smbpasswd</code> file and
+ back it up to a safe location.
+ </p></li><li><p>
+ Find the location of the <code class="filename">secrets.tdb</code> file and
+ back it up to a safe location.
+ </p></li><li><p>
+ <a class="indexterm" name="id2567761"></a>
+ <a class="indexterm" name="id2567768"></a>
+ <a class="indexterm" name="id2567775"></a>
+ <a class="indexterm" name="id2567782"></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><p>
+ <a class="indexterm" name="id2567820"></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><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 href="upgrades.html#sbeug1" title="Location of config files">???</a> to locate
+ the correct directories to which each control file must be moved.
+ </p></li><li><p>
+ Do not change the hostname.
+ </p></li><li><p>
+ Do not change the workgroup name.
+ </p></li><li><p>
+ <a class="indexterm" name="id2567875"></a>
+ Execute the <span><strong class="command">testparm</strong></span> 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="id2567933"></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><p>
+ <a class="indexterm" name="id2567954"></a>
+ It is now safe to start Samba using the appropriate system tool.
+ Alternately, it is possible to just execute <span><strong class="command">nmbd</strong></span>,
+ <span><strong class="command">smbd</strong></span>, and <span><strong class="command">winbindd</strong></span> for the command
+ line while logged in as the root user.
+ </p></li></ol></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2567985"></a>Applicable to All Samba 2.x to Samba-3 Upgrades</h3></div></div></div><p>
+ <a class="indexterm" name="id2567993"></a>
+ <a class="indexterm" name="id2568000"></a>
+ <a class="indexterm" name="id2568007"></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="id2568021"></a>
+ The following parameters are new to Samba-3 and should be correctly configured.
+ Please refer to <a href="secure.html" title="Chapter 3. Secure Office Networking">???</a> through <a href="2000users.html" title="Chapter 6. A Distributed 2000-User Network">???</a>
+ in this book for examples of use of the new parameters shown here:
+ <a class="indexterm" name="id2568042"></a>
+ <a class="indexterm" name="id2568049"></a>
+ <a class="indexterm" name="id2568056"></a>
+ <a class="indexterm" name="id2568063"></a>
+ <a class="indexterm" name="id2568070"></a>
+ <a class="indexterm" name="id2568077"></a>
+ <a class="indexterm" name="id2568084"></a>
+ </p><p>
+ </p><table class="simplelist" border="0" summary="Simple list"><tr><td><p>add group script</p></td></tr><tr><td><p>add machine script</p></td></tr><tr><td><p>add user to group script</p></td></tr><tr><td><p>delete group script</p></td></tr><tr><td><p>delete user from group script</p></td></tr><tr><td><p>passdb backend</p></td></tr><tr><td><p>set primary group script</p></td></tr></table><p>
+ </p><p>
+ <a class="indexterm" name="id2568136"></a>
+ <a class="indexterm" name="id2568143"></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="id2568167"></a>
+ <a class="indexterm" name="id2568174"></a>
+ <a class="indexterm" name="id2568181"></a>
+ <a class="indexterm" name="id2568188"></a>
+ <a class="indexterm" name="id2568195"></a>
+ <a class="indexterm" name="id2568202"></a>
+ <a class="indexterm" name="id2568208"></a>
+ <a class="indexterm" name="id2568215"></a>
+ <a class="indexterm" name="id2568222"></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 <span><strong class="command">useradd</strong></span>,
+ <span><strong class="command">usermod</strong></span>, <span><strong class="command">userdel</strong></span>, <span><strong class="command">groupadd</strong></span>,
+ <span><strong class="command">groupmod</strong></span>, <span><strong class="command">groupdel</strong></span>, and so on.
+ </p><p>
+ <a class="indexterm" name="id2568282"></a>
+ <a class="indexterm" name="id2568289"></a>
+ <a class="indexterm" name="id2568296"></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" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2568319"></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 href="upgrades.html#sbeug2" title="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="id2568353"></a>
+ <a class="indexterm" name="id2568360"></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" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2568500"></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="id2568516"></a>
+The information in <a href="upgrades.html#sbeug1" title="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="id2568542"></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="id2568576"></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="id2568596"></a>
+<a class="indexterm" name="id2568602"></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" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2568616"></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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2568627"></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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2568649"></a>Updating from Samba Versions between 3.0.6 and 3.0.10</h4></div></div></div><p>
+ <a class="indexterm" name="id2568658"></a>
+ <a class="indexterm" name="id2568664"></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="id2568681"></a>
+ <a class="indexterm" name="id2568688"></a>
+ <a class="indexterm" name="id2568694"></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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2568727"></a>Updating from Samba Versions after 3.0.6 to a Current Release</h4></div></div></div><p>
+ <a class="indexterm" name="id2568736"></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 <span><strong class="command">winbindd</strong></span>.
+ 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="id2568768"></a>
+ In Samba-3.0.11 a new privileges interface was implemented. Please
+ refer to <a href="happy.html#sbehap-ppc" title="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" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2568819"></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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2568831"></a>Replacing a Domain Member Server</h4></div></div></div><p>
+ <a class="indexterm" name="id2568839"></a>
+ Replacement of a domain member server should be done
+ using the same procedure as outlined in <a href="unixclients.html" title="Chapter 7. 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="id2568864"></a>
+ <a class="indexterm" name="id2568871"></a>
+ <a class="indexterm" name="id2568878"></a>
+ <a class="indexterm" name="id2568884"></a>
+ <a class="indexterm" name="id2568891"></a>
+ <a class="indexterm" name="id2568898"></a>
+ Following a change of hostname (NetBIOS name) it is a good idea on all servers
+ to shut down the Samba <span><strong class="command">smbd</strong></span>, <span><strong class="command">nmbd</strong></span>, and
+ <span><strong class="command">winbindd</strong></span> 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="id2568946"></a>
+ <a class="indexterm" name="id2568952"></a>
+ <a class="indexterm" name="id2568959"></a>
+ <a class="indexterm" name="id2568966"></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="id2569014"></a>
+ Where the user accounts for both UNIX and Samba are stored in LDAP, the new
+ target server must be configured to use the <span><strong class="command">nss_ldap</strong></span> tool set.
+ This will automatically ensure that the appropriate user entities are
+ available on the new server.
+ </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2569033"></a>Replacing a Domain Controller</h4></div></div></div><p>
+ <a class="indexterm" name="id2569041"></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 type="disc"><li><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 <span><strong class="command">slapcat</strong></span>
+ command and then reloading the same data into the new LDAP server using the
+ <span><strong class="command">slapadd</strong></span> command. Do not forget to install and configure
+ the <span><strong class="command">nss_ldap</strong></span> tool and the <code class="filename">/etc/nsswitch.conf</code>
+ (as shown in <a href="happy.html" title="Chapter 5. Making Happy Users">???</a>).
+ </p></li><li><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><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><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><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" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2569238"></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"><a name="id2569250"></a><p class="title"><b>Procedure 8.2. Migration to Active Directory</b></p><ol type="1"><li><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><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><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><p>
+ Disable the Windows Firewall on all workstations. Otherwise,
+ workstations won't be migrated to the new domain.
+ </p></li><li><p>
+ <a class="indexterm" name="id2569316"></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="id2569333"></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 type="disc"><li><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><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><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><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>
projects / samba / blobdiff