summaryrefslogtreecommitdiff
path: root/docs/Samba-Guide
diff options
context:
space:
mode:
authorJohn Terpstra <jht@samba.org>2005-04-13 23:29:07 +0000
committerGerald W. Carter <jerry@samba.org>2008-04-23 08:46:26 -0500
commitd1a2a25b5c06e235af99707228739fa676be2f2d (patch)
tree113f9f34a5b2d3561184918fb4f11f22b6496573 /docs/Samba-Guide
parent6f9ebcdcc9ed232ebf2c97ffc5d765ddc3399d1e (diff)
downloadsamba-d1a2a25b5c06e235af99707228739fa676be2f2d.tar.gz
samba-d1a2a25b5c06e235af99707228739fa676be2f2d.tar.bz2
samba-d1a2a25b5c06e235af99707228739fa676be2f2d.zip
Another update.
(This used to be commit 1665f8f6cc41c77959b98930f5623d2fa9e160e3)
Diffstat (limited to 'docs/Samba-Guide')
-rw-r--r--docs/Samba-Guide/SBE-UpgradingSamba.xml376
-rw-r--r--docs/Samba-Guide/SBE-preface.xml2
2 files changed, 338 insertions, 40 deletions
diff --git a/docs/Samba-Guide/SBE-UpgradingSamba.xml b/docs/Samba-Guide/SBE-UpgradingSamba.xml
index a4d5097cd9..65790cf3fb 100644
--- a/docs/Samba-Guide/SBE-UpgradingSamba.xml
+++ b/docs/Samba-Guide/SBE-UpgradingSamba.xml
@@ -24,7 +24,7 @@ highlighted by an email posting that included the following neat remark:
</para>
<blockquote><para>
-I like the <quote>net rpc vampire</quote> on NT4, but that to my surpirse does
+I like the <quote>net rpc vampire</quote> 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.
</para></blockquote>
@@ -65,89 +65,234 @@ the precautions take were inadequate. If a backup was not needed, but was availa
precaution was on the side of the victor.
</para>
-</sect1>
+ <sect2>
+ <title>Cautions and Notes</title>
-<sect1>
-<title>Upgrading from Samba-2 to Samba-3</title>
+ <para>
+ Someone once said, <quote>It is good to be sorry, but better never to need to be!</quote>
+ These are wise words of advice to those contemplating a Samba upgrade or update.
+ </para>
-<para>
-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 straight forward, although no upgrade should be
-attempted without proper planning and preparation.
-</para>
+ <para>
+ This is as good a time as any to define the terms <constant>upgrade</constant> and
+ <constant>update</constant>. The term <constant>upgrade</constant> is used to refer 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 release in generations 1.x, 2.x, 3.x and currently 4.0
+ is in development.
+ </para>
-<para>
-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.
-</para>
+ <para>
+ The term <constant>update</constant> is used to refer 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.
+ </para>
- <sect2>
- <title>Samba 1.9.x and 2.x Versions Without LDAP</title>
+ <para>
+ 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 requires careful review of the
+ latest documentation to identify precisely how the new installation may need to be
+ modified to preserve prior functionality.
+ </para>
<para>
- JJJ Pick up from here JJJ.
+ There is an old axiom that says, <quote>The greater the volume of the documentation
+ the greater the risk that no-one will read it, but where there is no documentation
+ no-one can read it!</quote>. While true, some documentation is an evil necessity.
+ It is to be hoped that this update to the documentation will avoid both extremes.
</para>
- </sect2>
+ <sect3>
+ <title>Security Identifiers (SIDs)</title>
- <sect2>
- <title>Samba-2.x with LDAP support</title>
+ <para>
+ 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 identifies
+ in the same context as the way that the SID is used since the development of
+ Windows NT 3.10.
+ </para>
<para>
+ 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.
</para>
- </sect2>
+ <para>
+ 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 <filename>MACHINE.SID.</filename>
+ </para>
-</sect1>
+ <para>
+ Within the life time of the early Samba 2.x series the machine SID information was
+ relocated into a tdb file called <filename>secrets.tdb</filename>, which is where is
+ 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.
+ </para>
-<sect1>
-<title>Updating a Samba-3 Installation</title>
+ <para>
+ 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 stand-alone servers (SAS) and domain member
+ servers (DMS).
+ </para>
-<para>
-</para>
+ <para>
+ When the Samba <command>smbd</command> daemon is first started, if the <filename>secrets.tdb</filename>
+ file does not exist it is created at the first client connection attempt. If this file does
+ exist, <command>smbd</command> checks that there is a machine SID (if it is a domain controller
+ it searches for the domain SID). If <command>smbd</command> 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 <filename>secrets.tdb</filename> file. The SID is generated in a non-determinative
+ 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.
+ </para>
- <sect2>
- <title>Updating from Versions Earlier than 3.0.6</title>
+ <para>
+ 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.
+ </para>
+
+ <note><para>
+ It is of paramount importance that the machine and domain SID must 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.
+ </para></note>
<para>
+ The local machine SID can be backed up using this procedure (Samba-3):
+<screen>
+&rootprompt; net getlocalsid > /etc/samba/my-local-SID
+</screen>
+ The contents of the file <filename>/etc/samba/my-local-SID</filename> will be:
+<screen>
+SID for domain FRODO is: S-1-5-21-726309263-4128913605-1168186429
+</screen>
+ This SID can be restored by executing:
+<screen>
+&rootprompt; net setlocalsid S-1-5-21-726309263-4128913605-1168186429
+</screen>
</para>
- </sect2>
+ <para>
+ Samba 1.9.x stored the machine SID in the the file <filename>/etc/MACHINE.SID</filename>
+ from which it can be recovered and stored into the <filename>secrets.tdb</filename> file
+ using the procedure shown above.
+ </para>
- <sect2>
- <title>Updating from Versions between 3.0.7 and 3.0.10</title>
+ <para>
+ Where the <filename>secrets.tdb</filename> 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.
+ </para>
<para>
+ In the course of the Samba 2.0.x series the <command>smbpasswd</command> was modified to
+ permit the domain SID to be captured to the <filename>secrets.tdb</filename> file by executing:
+<screen>
+&rootprompt; smbpasswd -S PDC -Uadministrator%password
+</screen>
</para>
- </sect2>
+ <para>
+ The release of the Samba 2.2.x series permitted the SID to be obtained by executing:
+<screen>
+&rootprompt; smbpasswd -S PDC -Uadministrator%password
+</screen>
+ From which the SID could be copied to a file and then it could be written to the
+ <filename>secrets.tdb</filename> file by executing:
+<screen>
+&rootprompt; smbpasswd -W S-1-5-21-726309263-4128913605-1168186429
+</screen>
+ </para>
- <sect2>
- <title>Migrating Samba-3 to a New Server</title>
+ <para>
+ Domain security information, that includes the domain SID, can be obtained from Samba-2.2.x
+ systems by executing:
+<screen>
+&rootprompt; rpcclient lsaquery -Uroot%password
+</screen>
+ This can also be done with Samba-3 by executing:
+<screen>
+&rootprompt; 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
+</screen>
+ 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.
+ </para>
<para>
+ Take note that the domain SID is used extensively in Samba. Where LDAP is used for the
+ <parameter>passdb backend</parameter>, 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 thus requiring extensive corrective action is the
+ original SID can not 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:
+<screen>
+&rootprompt; slapcat -v -l filename.ldif
+</screen>
</para>
- </sect2>
+ <para>
+ When the domain SID has changed roaming profiles will cease to be functional. The recovery
+ of roaming profiles will necessitate resetting of the domain portion of the user SID
+ that owns the profile. This is encoded in the <filename>NTUser.DAT</filename> and can be
+ updated using the Samba <command>profiles</command> utility. Please be aware that not all
+ Linux distributions of the Samba RPMs do include this essential utility. Please do not
+ complain to the Samba Team if this utility is missing, that is an 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.
+ </para>
- <sect2>
- <title>Cautions and Notes</title>
+ </sect3>
<sect3>
<title>Change of hostname</title>
<para>
+ Samba uses two (2) methods by which the primary NetBIOS machine name (also known as a computer
+ name or the hostname) may be determined: If the &smb.conf; file contains an entry
+ <parameter>netbios name</parameter> entry its value will be used directly. In the absence
+ of such and entry the UNIX system hostname will be used.
</para>
+ <para>
+ 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 above.
+ </para>
+
+ <note><para>
+ Do NOT change the hostname or the <parameter>netbios name</parameter>. 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.
+ </para></note>
+
</sect3>
<sect3>
<title>Change of workgroup (domain) name</title>
<para>
+ The domain name of a Samba server is identical with the workgroup name and is
+ set in the &smb.conf; file using the <parameter>workgroup</parameter> parameter.
+ This has been consistent throughout the history of Samba and across all versions.
+ </para>
+
+ <para>
+ 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.
</para>
</sect3>
@@ -173,6 +318,50 @@ Samba-2.x could be compiled with LDAP support.
</para>
<para>
+ The location at which <command>smbd</command> 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:
+<screen>
+&rootprompt; strings /usr/sbin/smbd | grep conf
+&rootprompt; strings /usr/sbin/smbd | grep secret
+&rootprompt; strings /usr/sbin/smbd | grep smbpasswd
+</screen>
+ Note: The <command>smbd</command> executable may be located in the path
+ <filename>/usr/local/samba/sbin</filename>.
+ </para>
+
+ <para>
+ 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 Samba can be uncovered:
+<screen>
+&rootprompt; 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.15/source
+ BUILDDIR: /usr/src/packages/BUILD/samba-3.0.15/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
+ ...
+</screen>
+ </para>
+
+ <para>
It is important that both the &smb.conf; file and the <filename>secrets.tdb</filename> should
be backed up before attempting any upgrade. The <filename>secrets.tdb</filename> file is version
encoded and therefore a newer version may not work with an older version of Samba. A backup
@@ -185,5 +374,114 @@ Samba-2.x could be compiled with LDAP support.
</sect1>
+<sect1>
+<title>Upgrading from Samba 1.x and 2.x to Samba-3</title>
+
+<para>
+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 straight forward, although no upgrade should be
+attempted without proper planning and preparation.
+</para>
+
+<para>
+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.
+</para>
+
+ <sect2>
+ <title>Samba 1.9.x and 2.x Versions Without LDAP</title>
+
+ <para>
+ Where it is necessary to upgrade an old Samba installation to Samba-3
+ the following procedure can be followed:
+ </para>
+
+ <procedure>
+ <step><para>
+ Stop Samba. This can be done using the appropriate system tool
+ that is particular for each operating system or by executing the
+ <command>kill</command> command on <command>smbd, nmbd</command>
+ and on <command>winbindd</command>.
+ </para></step>
+
+ <step><para>
+ Find the location of the Samba &smb.conf; file - back it up to a
+ safe location.
+ </para></step>
+
+ <step><para>
+ Find the location of the
+ </para></step>
+
+ <step><para>
+ </para></step>
+
+ <step><para>
+ </para></step>
+
+ <step><para>
+ </para></step>
+
+ <step><para>
+ </para></step>
+
+ <step><para>
+ </para></step>
+
+ <step><para>
+ </para></step>
+
+ <step><para>
+ </para></step>
+
+ </procedure>
+
+ </sect2>
+
+ <sect2>
+ <title>Samba-2.x with LDAP support</title>
+
+ <para>
+ </para>
+
+ </sect2>
+
+</sect1>
+
+<sect1>
+<title>Updating a Samba-3 Installation</title>
+
+<para>
+</para>
+
+ <sect2>
+ <title>Updating from Versions Earlier than 3.0.6</title>
+
+ <para>
+ </para>
+
+ </sect2>
+
+ <sect2>
+ <title>Updating from Versions between 3.0.7 and 3.0.10</title>
+
+ <para>
+ </para>
+
+ </sect2>
+
+ <sect2>
+ <title>Migrating Samba-3 to a New Server</title>
+
+ <para>
+ </para>
+
+ </sect2>
+
+</sect1>
+
</chapter>
diff --git a/docs/Samba-Guide/SBE-preface.xml b/docs/Samba-Guide/SBE-preface.xml
index 898b83ecc7..595b9cd6de 100644
--- a/docs/Samba-Guide/SBE-preface.xml
+++ b/docs/Samba-Guide/SBE-preface.xml
@@ -83,7 +83,7 @@
<para>
The Samba 3.0.x series has been remarkably popular. At the time this book first
went to print samba-3.0.2 was being released. There have been significant modifications
- and enhancements between samba-3.0.2 and samba-3.0.11 (the current release) that
+ and enhancements between samba-3.0.2 and samba-3.0.14 (the current release) that
necessitate this documentation update. This update has the specific intent to
refocus this book so that its guidance can be followed for samba-3.0.15
and beyond. Further changes are expected as Samba-3 matures further and will