diff --git a/docs/Samba-Guide/SBE-UpgradingSamba.xml b/docs/Samba-Guide/SBE-UpgradingSamba.xml index a4d5097cd94..65790cf3fb4 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:
-I like the net rpc vampire on NT4, but that to my surpirse does +I like the net rpc vampire 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.
@@ -65,10 +65,317 @@ the precautions take were inadequate. If a backup was not needed, but was availa precaution was on the side of the victor. + + Cautions and Notes + + + Someone once said, It is good to be sorry, but better never to need to be! + These are wise words of advice to those contemplating a Samba upgrade or update. + + + + This is as good a time as any to define the terms upgrade and + update. The term upgrade 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. + + + + The term update 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. + + + + 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. + + + + There is an old axiom that says, 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!. While true, some documentation is an evil necessity. + It is to be hoped that this update to the documentation will avoid both extremes. + + + + Security Identifiers (SIDs) + + + 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. + + + + 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. + + + + 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 MACHINE.SID. + + + + Within the life time of the early Samba 2.x series the machine SID information was + relocated into a tdb file called secrets.tdb, 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. + + + + 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). + + + + When the Samba smbd daemon is first started, if the secrets.tdb + file does not exist it is created at the first client connection attempt. If this file does + exist, smbd checks that there is a machine SID (if it is a domain controller + it searches for the domain SID). If smbd 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 secrets.tdb 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. + + + + 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. + + + + 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. + + + + The local machine SID can be backed up using this procedure (Samba-3): + +&rootprompt; net getlocalsid > /etc/samba/my-local-SID + + The contents of the file /etc/samba/my-local-SID will be: + +SID for domain FRODO is: S-1-5-21-726309263-4128913605-1168186429 + + This SID can be restored by executing: + +&rootprompt; net setlocalsid S-1-5-21-726309263-4128913605-1168186429 + + + + + Samba 1.9.x stored the machine SID in the the file /etc/MACHINE.SID + from which it can be recovered and stored into the secrets.tdb file + using the procedure shown above. + + + + Where the secrets.tdb 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. + + + + In the course of the Samba 2.0.x series the smbpasswd was modified to + permit the domain SID to be captured to the secrets.tdb file by executing: + +&rootprompt; smbpasswd -S PDC -Uadministrator%password + + + + + The release of the Samba 2.2.x series permitted the SID to be obtained by executing: + +&rootprompt; smbpasswd -S PDC -Uadministrator%password + + From which the SID could be copied to a file and then it could be written to the + secrets.tdb file by executing: + +&rootprompt; smbpasswd -W S-1-5-21-726309263-4128913605-1168186429 + + + + + Domain security information, that includes the domain SID, can be obtained from Samba-2.2.x + systems by executing: + +&rootprompt; rpcclient lsaquery -Uroot%password + + This can also be done with Samba-3 by executing: + +&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 + + 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. + + + + Take note that the domain SID is used extensively in Samba. Where LDAP is used for the + passdb backend, 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: + +&rootprompt; slapcat -v -l filename.ldif + + + + + 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 NTUser.DAT and can be + updated using the Samba profiles 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. + + + + + + Change of hostname + + + 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 + netbios name entry its value will be used directly. In the absence + of such and entry the UNIX system hostname will be used. + + + + 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. + + + + Do NOT change the hostname or the netbios name. 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. + + + + + + Change of workgroup (domain) name + + + The domain name of a Samba server is identical with the workgroup name and is + set in the &smb.conf; file using the workgroup parameter. + This has been consistent throughout the history of Samba and across all versions. + + + + 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. + + + + + + Location of config files + + + The Samba 1.9.x &smb.conf; file may be found either in the /etc + directory or in /usr/local/samba/lib. + + + + During the life of the Samba 2.x release the &smb.conf; file was relocated + on Linux systems to the /etc/samba directory where it + remains located also for Samba 3.0.x installations. + + + + Samba 2.x introduced the secrets.tdb file that is also stored in the + /etc/samba directory, or in the /usr/local/samba/lib + directory sub-system. + + + + The location at which smbd 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: + +&rootprompt; strings /usr/sbin/smbd | grep conf +&rootprompt; strings /usr/sbin/smbd | grep secret +&rootprompt; strings /usr/sbin/smbd | grep smbpasswd + + Note: The smbd executable may be located in the path + /usr/local/samba/sbin. + + + + 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: + +&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 + ... + + + + + It is important that both the &smb.conf; file and the secrets.tdb should + be backed up before attempting any upgrade. The secrets.tdb 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. + + + + + + -Upgrading from Samba-2 to Samba-3 +Upgrading from Samba 1.x and 2.x to Samba-3 Sites that are being upgraded from Samba-2 (or earlier versions) to Samba-3 @@ -88,9 +395,50 @@ Samba-2.x could be compiled with LDAP support. Samba 1.9.x and 2.x Versions Without LDAP - JJJ Pick up from here JJJ. + Where it is necessary to upgrade an old Samba installation to Samba-3 + the following procedure can be followed: + + + Stop Samba. This can be done using the appropriate system tool + that is particular for each operating system or by executing the + kill command on smbd, nmbd + and on winbindd. + + + + Find the location of the Samba &smb.conf; file - back it up to a + safe location. + + + + Find the location of the + + + + + + + + + + + + + + + + + + + + + + + + + @@ -133,56 +481,6 @@ Samba-2.x could be compiled with LDAP support. - - Cautions and Notes - - - Change of hostname - - - - - - - - Change of workgroup (domain) name - - - - - - - - Location of config files - - - The Samba 1.9.x &smb.conf; file may be found either in the /etc - directory or in /usr/local/samba/lib. - - - - During the life of the Samba 2.x release the &smb.conf; file was relocated - on Linux systems to the /etc/samba directory where it - remains located also for Samba 3.0.x installations. - - - - Samba 2.x introduced the secrets.tdb file that is also stored in the - /etc/samba directory, or in the /usr/local/samba/lib - directory sub-system. - - - - It is important that both the &smb.conf; file and the secrets.tdb should - be backed up before attempting any upgrade. The secrets.tdb 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. - - - - - - diff --git a/docs/Samba-Guide/SBE-preface.xml b/docs/Samba-Guide/SBE-preface.xml index 898b83ecc71..595b9cd6de0 100644 --- a/docs/Samba-Guide/SBE-preface.xml +++ b/docs/Samba-Guide/SBE-preface.xml @@ -83,7 +83,7 @@ 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