| 1 | <?xml version="1.0" encoding="iso-8859-1"?>
|
|---|
| 2 | <!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
|
|---|
| 3 | <chapter id="upgrades">
|
|---|
| 4 | <title>Updating Samba</title>
|
|---|
| 5 |
|
|---|
| 6 | <para>
|
|---|
| 7 | <indexterm><primary>migrate</primary></indexterm>
|
|---|
| 8 | <indexterm><primary>install</primary></indexterm>
|
|---|
| 9 | It was a little difficult to select an appropriate title for this chapter.
|
|---|
| 10 | From email messages on the Samba mailing lists it is clear that many people
|
|---|
| 11 | consider the updating and upgrading of Samba to be a migration matter. Others
|
|---|
| 12 | talk about migrating Samba servers when in fact the issue at hand is one of
|
|---|
| 13 | installing a new Samba server to replace an older existing Samba server.
|
|---|
| 14 | </para>
|
|---|
| 15 |
|
|---|
| 16 | <para>
|
|---|
| 17 | <indexterm><primary>smbpasswd</primary></indexterm>
|
|---|
| 18 | <indexterm><primary>passdb backend</primary></indexterm>
|
|---|
| 19 | There has also been much talk about migration of Samba from an smbpasswd
|
|---|
| 20 | passdb backend to the use of the tdbsam or ldapsam facilities that are new
|
|---|
| 21 | to Samba.
|
|---|
| 22 | </para>
|
|---|
| 23 |
|
|---|
| 24 | <para>
|
|---|
| 25 | Clearly, there is not a great deal of clarity in the terminology that various
|
|---|
| 26 | people apply to these modes by which Samba servers are updated. This is further
|
|---|
| 27 | highlighted by an email posting that included the following neat remark:
|
|---|
| 28 | </para>
|
|---|
| 29 |
|
|---|
| 30 | <blockquote><para>
|
|---|
| 31 | <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>vampire</tertiary></indexterm>
|
|---|
| 32 | I like the <quote>net rpc vampire</quote> on NT4, but that to my surprise does
|
|---|
| 33 | not seem to work against a Samba PDC and, if addressed in the Samba to Samba
|
|---|
| 34 | context in either book, I could not find it.
|
|---|
| 35 | </para></blockquote>
|
|---|
| 36 |
|
|---|
| 37 | <para>
|
|---|
| 38 | <indexterm><primary>contributions</primary></indexterm>
|
|---|
| 39 | So in response to the significant request for these situations to be better
|
|---|
| 40 | documented, this chapter has now been added. User contributions and documentation
|
|---|
| 41 | of real-world experiences are a most welcome addition to this chapter.
|
|---|
| 42 | </para>
|
|---|
| 43 |
|
|---|
| 44 | <sect1>
|
|---|
| 45 | <title>Introduction</title>
|
|---|
| 46 |
|
|---|
| 47 | <para>
|
|---|
| 48 | <indexterm><primary>update</primary></indexterm>
|
|---|
| 49 | <indexterm><primary>upgrade</primary></indexterm>
|
|---|
| 50 | <indexterm><primary>frustration</primary></indexterm>
|
|---|
| 51 | A Windows network administrator explained in an email what changes he was
|
|---|
| 52 | planning to make and followed with the question: <quote>Anyone done this
|
|---|
| 53 | before?</quote> Many of us have upgraded and updated Samba without incident.
|
|---|
| 54 | Others have experienced much pain and user frustration. So it is to be hoped
|
|---|
| 55 | that the notes in this chapter will make a positive difference by assuring
|
|---|
| 56 | that someone will be saved a lot of discomfort.
|
|---|
| 57 | </para>
|
|---|
| 58 |
|
|---|
| 59 | <para>
|
|---|
| 60 | Before anyone commences an upgrade or an update of Samba, the one cardinal
|
|---|
| 61 | rule that must be observed is: Backup all Samba configuration files in
|
|---|
| 62 | case it is necessary to revert to the old version. Even if you do not like
|
|---|
| 63 | this precautionary step, users will punish an administrator who
|
|---|
| 64 | fails to take adequate steps to avoid situations that may inflict lost
|
|---|
| 65 | productivity on them.
|
|---|
| 66 | </para>
|
|---|
| 67 |
|
|---|
| 68 | <warning><para>
|
|---|
| 69 | <indexterm><primary>configuration files</primary></indexterm>
|
|---|
| 70 | <indexterm><primary>down-grade</primary></indexterm>
|
|---|
| 71 | Samba makes it possible to upgrade and update configuration files, but it
|
|---|
| 72 | is not possible to downgrade the configuration files. Please ensure that
|
|---|
| 73 | all configuration and control files are backed up to permit a down-grade
|
|---|
| 74 | in the rare event that this may be necessary.
|
|---|
| 75 | </para></warning>
|
|---|
| 76 |
|
|---|
| 77 |
|
|---|
| 78 | <para>
|
|---|
| 79 | <indexterm><primary>adequate precautions</primary></indexterm>
|
|---|
| 80 | <indexterm><primary>precaution</primary></indexterm>
|
|---|
| 81 | It is prudent also to backup all data files on the server before attempting
|
|---|
| 82 | to perform a major upgrade. Many administrators have experienced the consequences
|
|---|
| 83 | of failure to take adequate precautions. So what is adequate? That is simple!
|
|---|
| 84 | If data is lost during an upgrade or update and it can not be restored,
|
|---|
| 85 | the precautions taken were inadequate. If a backup was not needed, but was available,
|
|---|
| 86 | caution was on the side of the victor.
|
|---|
| 87 | </para>
|
|---|
| 88 |
|
|---|
| 89 | <sect2>
|
|---|
| 90 | <title>Cautions and Notes</title>
|
|---|
| 91 |
|
|---|
| 92 | <para>
|
|---|
| 93 | Someone once said, <quote>It is good to be sorry, but better never to need to be!</quote>
|
|---|
| 94 | These are wise words of advice to those contemplating a Samba upgrade or update.
|
|---|
| 95 | </para>
|
|---|
| 96 |
|
|---|
| 97 | <para>
|
|---|
| 98 | <indexterm><primary>update</primary></indexterm>
|
|---|
| 99 | <indexterm><primary>upgrade</primary></indexterm>
|
|---|
| 100 | <indexterm><primary>generation</primary></indexterm>
|
|---|
| 101 | This is as good a time as any to define the terms <constant>upgrade</constant> and
|
|---|
| 102 | <constant>update</constant>. The term <constant>upgrade</constant> refers to
|
|---|
| 103 | the installation of a version of Samba that is a whole generation or more ahead of
|
|---|
| 104 | that which is installed. Generations are indicated by the first digit of the version
|
|---|
| 105 | number. So far Samba has been released in generations 1.x, 2.x, 3.x, and currently 4.0
|
|---|
| 106 | is in development.
|
|---|
| 107 | </para>
|
|---|
| 108 |
|
|---|
| 109 | <para>
|
|---|
| 110 | <indexterm><primary>generation</primary></indexterm>
|
|---|
| 111 | The term <constant>update</constant> refers to a minor version number installation
|
|---|
| 112 | in place of one of the same generation. For example, updating from Samba 3.0.10 to 3.0.14
|
|---|
| 113 | is an update. The move from Samba 2.0.7 to 3.0.14 is an upgrade.
|
|---|
| 114 | </para>
|
|---|
| 115 |
|
|---|
| 116 | <para>
|
|---|
| 117 | <indexterm><primary>functional differences</primary></indexterm>
|
|---|
| 118 | While the use of these terms is an exercise in semantics, what needs to be realized
|
|---|
| 119 | is that there are major functional differences between a Samba 2.x release and a Samba
|
|---|
| 120 | 3.0.x release. Such differences may require a significantly different approach to
|
|---|
| 121 | solving the same networking challenge and generally require careful review of the
|
|---|
| 122 | latest documentation to identify precisely how the new installation may need to be
|
|---|
| 123 | modified to preserve prior functionality.
|
|---|
| 124 | </para>
|
|---|
| 125 |
|
|---|
| 126 | <para>
|
|---|
| 127 | There is an old axiom that says, <quote>The greater the volume of the documentation,
|
|---|
| 128 | the greater the risk that noone will read it, but where there is no documentation,
|
|---|
| 129 | noone can read it!</quote> While true, some documentation is an evil necessity.
|
|---|
| 130 | It is hoped that this update to the documentation will avoid both extremes.
|
|---|
| 131 | </para>
|
|---|
| 132 |
|
|---|
| 133 | <sect3>
|
|---|
| 134 | <title>Security Identifiers (SIDs)</title>
|
|---|
| 135 |
|
|---|
| 136 | <para>
|
|---|
| 137 | <indexterm><primary>Windows</primary><secondary>NT</secondary></indexterm>
|
|---|
| 138 | <indexterm><primary>OS/2</primary></indexterm>
|
|---|
| 139 | <indexterm><primary>DOS</primary></indexterm>
|
|---|
| 140 | <indexterm><primary>SID</primary></indexterm>
|
|---|
| 141 | <indexterm><primary>networking</primary><secondary>client</secondary></indexterm>
|
|---|
| 142 | <indexterm><primary>security</primary><secondary>identifier</secondary></indexterm>
|
|---|
| 143 | Before the days of Windows NT and OS/2, every Windows and DOS networking client
|
|---|
| 144 | that used the SMB protocols was an entirely autonomous entity. There was no concept
|
|---|
| 145 | of a security identifier for a machine or a user outside of the username, the
|
|---|
| 146 | machine name, and the workgroup name. In actual fact, these were not security identifiers
|
|---|
| 147 | in the same context as the way that the SID is used since the development of
|
|---|
| 148 | Windows NT 3.10.
|
|---|
| 149 | </para>
|
|---|
| 150 |
|
|---|
| 151 | <para>
|
|---|
| 152 | <indexterm><primary>SessionSetUpAndX</primary></indexterm>
|
|---|
| 153 | <indexterm><primary>SMB</primary></indexterm>
|
|---|
| 154 | <indexterm><primary>CIFS</primary></indexterm>
|
|---|
| 155 | <indexterm><primary>SID</primary></indexterm>
|
|---|
| 156 | <indexterm><primary>username</primary></indexterm>
|
|---|
| 157 | <indexterm><primary>Windows</primary><secondary>client</secondary></indexterm>
|
|---|
| 158 | Versions of Samba prior to 1.9 did not make use of a SID. Instead they make exclusive use
|
|---|
| 159 | of the username that is embedded in the SessionSetUpAndX component of the connection
|
|---|
| 160 | setup process between a Windows client and an SMB/CIFS server.
|
|---|
| 161 | </para>
|
|---|
| 162 |
|
|---|
| 163 | <para>
|
|---|
| 164 | <indexterm><primary>MACHINE.SID</primary></indexterm>
|
|---|
| 165 | <indexterm><primary>rpc</primary></indexterm>
|
|---|
| 166 | <indexterm><primary>security</primary></indexterm>
|
|---|
| 167 | Around November 1997 support was added to Samba-1.9 to handle the Windows security
|
|---|
| 168 | RPC-based protocols that implemented support for Samba to store a machine SID. This
|
|---|
| 169 | information was stored in a file called <filename>MACHINE.SID.</filename>
|
|---|
| 170 | </para>
|
|---|
| 171 |
|
|---|
| 172 | <para>
|
|---|
| 173 | <indexterm><primary>machine</primary></indexterm>
|
|---|
| 174 | <indexterm><primary>SID</primary></indexterm>
|
|---|
| 175 | <indexterm><primary>secrets.tdb</primary></indexterm>
|
|---|
| 176 | Within the lifetime of the early Samba 2.x series, the machine SID information was
|
|---|
| 177 | relocated into a tdb file called <filename>secrets.tdb</filename>, which is where
|
|---|
| 178 | it is still located in Samba 3.0.x along with other information that pertains to the
|
|---|
| 179 | local machine and its role within a domain security context.
|
|---|
| 180 | </para>
|
|---|
| 181 |
|
|---|
| 182 | <para>
|
|---|
| 183 | <indexterm><primary>server</primary><secondary>stand-alone</secondary></indexterm>
|
|---|
| 184 | <indexterm><primary>server</primary><secondary>domain member</secondary></indexterm>
|
|---|
| 185 | <indexterm><primary>DMS</primary></indexterm>
|
|---|
| 186 | <indexterm><primary>SAS</primary></indexterm>
|
|---|
| 187 | There are two types of SID, those pertaining to the machine itself and the domain to
|
|---|
| 188 | which it may belong, and those pertaining to users and groups within the security
|
|---|
| 189 | context of the local machine, in the case of standalone servers (SAS) and domain member
|
|---|
| 190 | servers (DMS).
|
|---|
| 191 | </para>
|
|---|
| 192 |
|
|---|
| 193 | <para>
|
|---|
| 194 | <indexterm><primary>smbd</primary></indexterm>
|
|---|
| 195 | <indexterm><primary>workgroup</primary></indexterm>
|
|---|
| 196 | <indexterm><primary>hostname</primary></indexterm>
|
|---|
| 197 | <indexterm><primary>daemon</primary></indexterm>
|
|---|
| 198 | <indexterm><primary>SID</primary></indexterm>
|
|---|
| 199 | <indexterm><primary>secrets.tdb</primary></indexterm>
|
|---|
| 200 | When the Samba <command>smbd</command> daemon is first started, if the <filename>secrets.tdb</filename>
|
|---|
| 201 | file does not exist, it is created at the first client connection attempt. If this file does
|
|---|
| 202 | exist, <command>smbd</command> checks that there is a machine SID (if it is a domain controller,
|
|---|
| 203 | it searches for the domain SID). If <command>smbd</command> does not find one for the current
|
|---|
| 204 | name of the machine or for the current name of the workgroup, a new SID will be generated and
|
|---|
| 205 | then written to the <filename>secrets.tdb</filename> file. The SID is generated in a nondeterminative
|
|---|
| 206 | manner. This means that each time it is generated for a particular combination of machine name
|
|---|
| 207 | (hostname) and domain name (workgroup), it will be different.
|
|---|
| 208 | </para>
|
|---|
| 209 |
|
|---|
| 210 | <para>
|
|---|
| 211 | <indexterm><primary>ACL</primary></indexterm>
|
|---|
| 212 | The SID is the key used by MS Windows networking for all networking operations. This means
|
|---|
| 213 | that when the machine or domain SID changes, all security-encoded objects such as profiles
|
|---|
| 214 | and ACLs may become unusable.
|
|---|
| 215 | </para>
|
|---|
| 216 |
|
|---|
| 217 | <note><para>
|
|---|
| 218 | It is of paramount importance that the machine and domain SID be backed up so that in
|
|---|
| 219 | the event of a change of hostname (machine name) or domain name (workgroup) the SID can
|
|---|
| 220 | be restored to its previous value.
|
|---|
| 221 | </para></note>
|
|---|
| 222 |
|
|---|
| 223 | <para>
|
|---|
| 224 | <indexterm><primary>domain controller</primary></indexterm>
|
|---|
| 225 | <indexterm><primary>PDC</primary></indexterm>
|
|---|
| 226 | <indexterm><primary>BDC</primary></indexterm>
|
|---|
| 227 | <indexterm><primary>domain SID</primary></indexterm>
|
|---|
| 228 | <indexterm><primary>hostname</primary></indexterm>
|
|---|
| 229 | <indexterm><primary>computer name</primary></indexterm>
|
|---|
| 230 | <indexterm><primary>netbios name</primary></indexterm>
|
|---|
| 231 | <indexterm><primary>stand-alone server</primary></indexterm>
|
|---|
| 232 | <indexterm><primary>SAS</primary></indexterm>
|
|---|
| 233 | <indexterm><primary>SID</primary></indexterm>
|
|---|
| 234 | In Samba on a domain controller (PDC or BDC), the domain name controls the domain
|
|---|
| 235 | SID. On all prior versions the hostname (computer name, or NetBIOS name) controlled
|
|---|
| 236 | the SID. On a standalone server the hostname still controls the SID.
|
|---|
| 237 | </para>
|
|---|
| 238 |
|
|---|
| 239 | <para>
|
|---|
| 240 | <indexterm><primary>net</primary><secondary>getlocalsid</secondary></indexterm>
|
|---|
| 241 | <indexterm><primary>net</primary><secondary>setlocalsid</secondary></indexterm>
|
|---|
| 242 | The local machine SID can be backed up using this procedure (Samba):
|
|---|
| 243 | <screen>
|
|---|
| 244 | &rootprompt; net getlocalsid > /etc/samba/my-local-SID
|
|---|
| 245 | </screen>
|
|---|
| 246 | The contents of the file <filename>/etc/samba/my-local-SID</filename> will be:
|
|---|
| 247 | <screen>
|
|---|
| 248 | SID for domain FRODO is: S-1-5-21-726309263-4128913605-1168186429
|
|---|
| 249 | </screen>
|
|---|
| 250 | This SID can be restored by executing:
|
|---|
| 251 | <screen>
|
|---|
| 252 | &rootprompt; net setlocalsid S-1-5-21-726309263-4128913605-1168186429
|
|---|
| 253 | </screen>
|
|---|
| 254 | </para>
|
|---|
| 255 |
|
|---|
| 256 | <para>
|
|---|
| 257 | Samba 1.9.x stored the machine SID in the the file <filename>/etc/MACHINE.SID</filename>
|
|---|
| 258 | from which it could be recovered and stored into the <filename>secrets.tdb</filename> file
|
|---|
| 259 | using the procedure shown above.
|
|---|
| 260 | </para>
|
|---|
| 261 |
|
|---|
| 262 | <para>
|
|---|
| 263 | Where the <filename>secrets.tdb</filename> file exists and a version of Samba 2.x or later
|
|---|
| 264 | has been used, there is no specific need to go through this update process. Samba has the
|
|---|
| 265 | ability to read the older tdb file and to perform an in-situ update to the latest tdb format.
|
|---|
| 266 | This is not a reversible process &smbmdash; it is a one-way upgrade.
|
|---|
| 267 | </para>
|
|---|
| 268 |
|
|---|
| 269 | <para>
|
|---|
| 270 | <indexterm><primary>smbpasswd</primary></indexterm>
|
|---|
| 271 | In the course of the Samba 2.0.x series the <command>smbpasswd</command> was modified to
|
|---|
| 272 | permit the domain SID to be captured to the <filename>secrets.tdb</filename> file by executing:
|
|---|
| 273 | <screen>
|
|---|
| 274 | &rootprompt; smbpasswd -S PDC -Uadministrator%password
|
|---|
| 275 | </screen>
|
|---|
| 276 | </para>
|
|---|
| 277 |
|
|---|
| 278 | <para>
|
|---|
| 279 | The release of the Samba 2.2.x series permitted the SID to be obtained by executing:
|
|---|
| 280 | <screen>
|
|---|
| 281 | &rootprompt; smbpasswd -S PDC -Uadministrator%password
|
|---|
| 282 | </screen>
|
|---|
| 283 | from which the SID could be copied to a file and then written to the Samba-2.2.x
|
|---|
| 284 | <filename>secrets.tdb</filename> file by executing:
|
|---|
| 285 | <screen>
|
|---|
| 286 | &rootprompt; smbpasswd -W S-1-5-21-726309263-4128913605-1168186429
|
|---|
| 287 | </screen>
|
|---|
| 288 | </para>
|
|---|
| 289 |
|
|---|
| 290 | <para>
|
|---|
| 291 | <indexterm><primary>rpcclient</primary></indexterm>
|
|---|
| 292 | <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>info</tertiary></indexterm>
|
|---|
| 293 | Domain security information, which includes the domain SID, can be obtained from Samba-2.2.x
|
|---|
| 294 | systems by executing:
|
|---|
| 295 | <screen>
|
|---|
| 296 | &rootprompt; rpcclient hostname lsaquery -Uroot%password
|
|---|
| 297 | </screen>
|
|---|
| 298 | This can also be done with Samba by executing:
|
|---|
| 299 | <screen>
|
|---|
| 300 | &rootprompt; net rpc info -Uroot%password
|
|---|
| 301 | Domain Name: MIDEARTH
|
|---|
| 302 | Domain SID: S-1-5-21-726309263-4128913605-1168186429
|
|---|
| 303 | Sequence number: 1113415916
|
|---|
| 304 | Num users: 4237
|
|---|
| 305 | Num domain groups: 86
|
|---|
| 306 | Num local groups: 0
|
|---|
| 307 | </screen>
|
|---|
| 308 | It is a very good practice to store this SID information in a safely kept file, just in
|
|---|
| 309 | case it is ever needed at a later date.
|
|---|
| 310 | </para>
|
|---|
| 311 |
|
|---|
| 312 | <para>
|
|---|
| 313 | <indexterm><primary>passdb backend</primary></indexterm>
|
|---|
| 314 | <indexterm><primary>LDAP</primary></indexterm>
|
|---|
| 315 | <indexterm><primary>SID</primary></indexterm>
|
|---|
| 316 | Take note that the domain SID is used extensively in Samba. Where LDAP is used for the
|
|---|
| 317 | <parameter>passdb backend</parameter>, all user, group, and trust accounts are encoded
|
|---|
| 318 | with the domain SID. This means that if the domain SID changes for any reason, the entire
|
|---|
| 319 | Samba environment can become broken and require extensive corrective action if the
|
|---|
| 320 | original SID cannot be restored. Fortunately, it can be recovered from a dump of the
|
|---|
| 321 | LDAP database. A dump of the LDAP directory database can be obtained by executing:
|
|---|
| 322 | <screen>
|
|---|
| 323 | &rootprompt; slapcat -v -l filename.ldif
|
|---|
| 324 | </screen>
|
|---|
| 325 | </para>
|
|---|
| 326 |
|
|---|
| 327 | <para>
|
|---|
| 328 | <indexterm><primary>SID</primary></indexterm>
|
|---|
| 329 | <indexterm><primary>profiles</primary></indexterm>
|
|---|
| 330 | <indexterm><primary>RPM</primary></indexterm>
|
|---|
| 331 | When the domain SID has changed, roaming profiles cease to be functional. The recovery
|
|---|
| 332 | of roaming profiles necessitates resetting of the domain portion of the user SID
|
|---|
| 333 | that owns the profile. This is encoded in the <filename>NTUser.DAT</filename> and can be
|
|---|
| 334 | updated using the Samba <command>profiles</command> utility. Please be aware that not all
|
|---|
| 335 | Linux distributions of the Samba RPMs include this essential utility. Please do not
|
|---|
| 336 | complain to the Samba Team if this utility is missing; that issue that must be
|
|---|
| 337 | addressed to the creator of the RPM package. The Samba Team do their best to make
|
|---|
| 338 | available all the tools needed to manage a Samba-based Windows networking environment.
|
|---|
| 339 | </para>
|
|---|
| 340 |
|
|---|
| 341 | </sect3>
|
|---|
| 342 |
|
|---|
| 343 | <sect3>
|
|---|
| 344 | <title>Change of hostname</title>
|
|---|
| 345 |
|
|---|
| 346 | <para>
|
|---|
| 347 | <indexterm><primary>netbios</primary><secondary>machine name</secondary></indexterm>
|
|---|
| 348 | <indexterm><primary>netbios name</primary></indexterm>
|
|---|
| 349 | Samba uses two methods by which the primary NetBIOS machine name (also known as a computer
|
|---|
| 350 | name or the hostname) may be determined: If the &smb.conf; file contains a
|
|---|
| 351 | <parameter>netbios name</parameter> entry, its value will be used directly. In the absence
|
|---|
| 352 | of such an entry, the UNIX system hostname will be used.
|
|---|
| 353 | </para>
|
|---|
| 354 |
|
|---|
| 355 | <para>
|
|---|
| 356 | Many sites have become victims of lost Samba functionality because the UNIX system
|
|---|
| 357 | hostname was changed for one reason or another. Such a change will cause a new machine
|
|---|
| 358 | SID to be generated. If this happens on a domain controller, it will also change the
|
|---|
| 359 | domain SID. These SIDs can be updated (restored) using the procedure outlined previously.
|
|---|
| 360 | </para>
|
|---|
| 361 |
|
|---|
| 362 | <note><para>
|
|---|
| 363 | Do NOT change the hostname or the <parameter>netbios name</parameter>. If this
|
|---|
| 364 | is changed, be sure to reset the machine SID to the original setting. Otherwise
|
|---|
| 365 | there may be serious interoperability and/or operational problems.
|
|---|
| 366 | </para></note>
|
|---|
| 367 |
|
|---|
| 368 | </sect3>
|
|---|
| 369 |
|
|---|
| 370 | <sect3>
|
|---|
| 371 | <title>Change of Workgroup (Domain) Name</title>
|
|---|
| 372 |
|
|---|
| 373 | <para>
|
|---|
| 374 | <indexterm><primary>workgroup</primary></indexterm>
|
|---|
| 375 | The domain name of a Samba server is identical to the workgroup name and is
|
|---|
| 376 | set in the &smb.conf; file using the <parameter>workgroup</parameter> parameter.
|
|---|
| 377 | This has been consistent throughout the history of Samba and across all versions.
|
|---|
| 378 | </para>
|
|---|
| 379 |
|
|---|
| 380 | <para>
|
|---|
| 381 | <indexterm><primary>SID</primary></indexterm>
|
|---|
| 382 | Be aware that when the workgroup name is changed, a new SID will be generated.
|
|---|
| 383 | The old domain SID can be reset using the procedure outlined earlier in this chapter.
|
|---|
| 384 | </para>
|
|---|
| 385 |
|
|---|
| 386 | </sect3>
|
|---|
| 387 |
|
|---|
| 388 | <sect3 id="sbeug1">
|
|---|
| 389 | <title>Location of config files</title>
|
|---|
| 390 |
|
|---|
| 391 | <para>
|
|---|
| 392 | The Samba-Team has maintained a constant default location for all Samba control files
|
|---|
| 393 | throughout the life of the project. People who have produced binary packages of Samba
|
|---|
| 394 | have varied the location of the Samba control files. This has led to some confusion
|
|---|
| 395 | for network administrators.
|
|---|
| 396 | </para>
|
|---|
| 397 |
|
|---|
| 398 | <para>
|
|---|
| 399 | <indexterm><primary>directory</primary></indexterm>
|
|---|
| 400 | The Samba 1.9.x &smb.conf; file may be found either in the <filename>/etc</filename>
|
|---|
| 401 | directory or in <filename>/usr/local/samba/lib</filename>.
|
|---|
| 402 | </para>
|
|---|
| 403 |
|
|---|
| 404 | <para>
|
|---|
| 405 | During the life of the Samba 2.x release, the &smb.conf; file was relocated
|
|---|
| 406 | on Linux systems to the <filename>/etc/samba</filename> directory where it
|
|---|
| 407 | remains located also for Samba 3.0.x installations.
|
|---|
| 408 | </para>
|
|---|
| 409 |
|
|---|
| 410 | <para>
|
|---|
| 411 | <indexterm><primary>secrets.tdb</primary></indexterm>
|
|---|
| 412 | Samba 2.x introduced the <filename>secrets.tdb</filename> file that is also stored in the
|
|---|
| 413 | <filename>/etc/samba</filename> directory, or in the <filename>/usr/local/samba/lib</filename>
|
|---|
| 414 | directory subsystem.
|
|---|
| 415 | </para>
|
|---|
| 416 |
|
|---|
| 417 | <para>
|
|---|
| 418 | <indexterm><primary>smbd</primary></indexterm>
|
|---|
| 419 | The location at which <command>smbd</command> expects to find all configuration and control
|
|---|
| 420 | files is determined at the time of compilation of Samba. For versions of Samba prior to
|
|---|
| 421 | 3.0, one way to find the expected location of these files is to execute:
|
|---|
| 422 | <screen>
|
|---|
| 423 | &rootprompt; strings /usr/sbin/smbd | grep conf
|
|---|
| 424 | &rootprompt; strings /usr/sbin/smbd | grep secret
|
|---|
| 425 | &rootprompt; strings /usr/sbin/smbd | grep smbpasswd
|
|---|
| 426 | </screen>
|
|---|
| 427 | Note: The <command>smbd</command> executable may be located in the path
|
|---|
| 428 | <filename>/usr/local/samba/sbin</filename>.
|
|---|
| 429 | </para>
|
|---|
| 430 |
|
|---|
| 431 | <para>
|
|---|
| 432 | <indexterm><primary>compile-time</primary></indexterm>
|
|---|
| 433 | Samba provides a neat new way to track the location of all control files as well as to
|
|---|
| 434 | find the compile-time options used as the Samba package was built. Here is how the dark
|
|---|
| 435 | secrets of the internals of the location of control files within Samba executables can
|
|---|
| 436 | be uncovered:
|
|---|
| 437 | <screen>
|
|---|
| 438 | &rootprompt; smbd -b | less
|
|---|
| 439 | Build environment:
|
|---|
| 440 | Built by: root@frodo
|
|---|
| 441 | Built on: Mon Apr 11 20:23:27 MDT 2005
|
|---|
| 442 | Built using: gcc
|
|---|
| 443 | Build host: Linux frodo 2.6...
|
|---|
| 444 | SRCDIR: /usr/src/packages/BUILD/samba-3.0.20/source
|
|---|
| 445 | BUILDDIR: /usr/src/packages/BUILD/samba-3.0.20/source
|
|---|
| 446 |
|
|---|
| 447 | Paths:
|
|---|
| 448 | SBINDIR: /usr/sbin
|
|---|
| 449 | BINDIR: /usr/bin
|
|---|
| 450 | SWATDIR: /usr/share/samba/swat
|
|---|
| 451 | CONFIGFILE: /etc/samba/smb.conf
|
|---|
| 452 | LOGFILEBASE: /var/log/samba
|
|---|
| 453 | LMHOSTSFILE: /etc/samba/lmhosts
|
|---|
| 454 | LIBDIR: /usr/lib/samba
|
|---|
| 455 | SHLIBEXT: so
|
|---|
| 456 | LOCKDIR: /var/lib/samba
|
|---|
| 457 | PIDDIR: /var/run/samba
|
|---|
| 458 | SMB_PASSWD_FILE: /etc/samba/smbpasswd
|
|---|
| 459 | PRIVATE_DIR: /etc/samba
|
|---|
| 460 | ...
|
|---|
| 461 | </screen>
|
|---|
| 462 | </para>
|
|---|
| 463 |
|
|---|
| 464 | <para>
|
|---|
| 465 | <indexterm><primary></primary></indexterm>
|
|---|
| 466 | It is important that both the &smb.conf; file and the <filename>secrets.tdb</filename>
|
|---|
| 467 | be backed up before attempting any upgrade. The <filename>secrets.tdb</filename> file
|
|---|
| 468 | is version-encoded, and therefore a newer version may not work with an older version
|
|---|
| 469 | of Samba. A backup means that it is always possible to revert a failed or problematic
|
|---|
| 470 | upgrade.
|
|---|
| 471 | </para>
|
|---|
| 472 |
|
|---|
| 473 | </sect3>
|
|---|
| 474 |
|
|---|
| 475 | <sect3>
|
|---|
| 476 | <title>International Language Support</title>
|
|---|
| 477 |
|
|---|
| 478 | <para>
|
|---|
| 479 | <indexterm><primary>unicode</primary></indexterm>
|
|---|
| 480 | <indexterm><primary>character set</primary></indexterm>
|
|---|
| 481 | <indexterm><primary>codepage</primary></indexterm>
|
|---|
| 482 | <indexterm><primary>internationalization</primary></indexterm>
|
|---|
| 483 | Samba-2.x had no support for Unicode; instead, all national language character-set support in file names
|
|---|
| 484 | was done using particular locale codepage mapping techniques. Samba supports Unicode in file names, thus
|
|---|
| 485 | providing true internationalization support.
|
|---|
| 486 | </para>
|
|---|
| 487 |
|
|---|
| 488 | <para>
|
|---|
| 489 | <indexterm><primary>8-bit</primary></indexterm>
|
|---|
| 490 | Non-English users whose national language character set has special characters and who upgrade naively will
|
|---|
| 491 | find that many files that have the special characters in the file name will see them garbled and jumbled up.
|
|---|
| 492 | This typically happens with umlauts and accents because these characters were particular to the codepage
|
|---|
| 493 | that was in use with Samba-2.x using an 8-bit encoding scheme.
|
|---|
| 494 | </para>
|
|---|
| 495 |
|
|---|
| 496 | <para>
|
|---|
| 497 | <indexterm><primary>UTF-8</primary></indexterm>
|
|---|
| 498 | Files that are created with Samba will use UTF-8 encoding. Should the file system ever end up with a
|
|---|
| 499 | mix of codepage (unix charset)-encoded file names and UTF-8-encoded file names, the mess will take some
|
|---|
| 500 | effort to set straight.
|
|---|
| 501 | </para>
|
|---|
| 502 |
|
|---|
| 503 | <para>
|
|---|
| 504 | <indexterm><primary>convmv</primary></indexterm>
|
|---|
| 505 | A very helpful tool is available from Bjorn Jacke's <ulink url="http://j3e.de/linux/convmv/">convmv</ulink>
|
|---|
| 506 | work. Convmv is a tool that can be used to convert file and directory names from one encoding method to
|
|---|
| 507 | another. The most common use for this tool is to convert locale-encoded files to UTF-8 Unicode encoding.
|
|---|
| 508 | </para>
|
|---|
| 509 |
|
|---|
| 510 | </sect3>
|
|---|
| 511 |
|
|---|
| 512 | <sect3>
|
|---|
| 513 | <title>Updates and Changes in Idealx smbldap-tools</title>
|
|---|
| 514 |
|
|---|
| 515 | <para>
|
|---|
| 516 | The smbldap-tools have been maturing rapidly over the past year. With maturation comes change.
|
|---|
| 517 | The location of the <filename>smbldap.conf</filename> and the <filename>smbldap_bind.conf</filename>
|
|---|
| 518 | configuration files have been moved from the directory <filename>/etc/smbldap-tools</filename> to
|
|---|
| 519 | the new location of <filename>/etc/opt/IDEALX/smblda-tools</filename> directory.
|
|---|
| 520 | </para>
|
|---|
| 521 |
|
|---|
| 522 | <para>
|
|---|
| 523 | The smbldap-tools maintains an entry in the LDAP directory in which it stores the next
|
|---|
| 524 | values that should be used for UID and GID allocation for POSIX accounts that are created
|
|---|
| 525 | using this tool. The DIT location of these values has changed recently. The original
|
|---|
| 526 | <constant>sambaUnixIdPooldn object</constant> entity was stored in a directory entry (DIT object)
|
|---|
| 527 | called <constant>NextFreeUnixId</constant>, this has been changed to the DIT object
|
|---|
| 528 | <constant>sambaDomainName</constant>. Anyone who updates from an older version to the
|
|---|
| 529 | current release should note that the information stored under <constant>NextFreeUnixId</constant>
|
|---|
| 530 | must now be relocated to the DIT object <constant>sambaDomainName</constant>.
|
|---|
| 531 | </para>
|
|---|
| 532 |
|
|---|
| 533 | </sect3>
|
|---|
| 534 |
|
|---|
| 535 | </sect2>
|
|---|
| 536 |
|
|---|
| 537 | </sect1>
|
|---|
| 538 |
|
|---|
| 539 | <sect1>
|
|---|
| 540 | <title>Upgrading from Samba 1.x and 2.x to Samba-3</title>
|
|---|
| 541 |
|
|---|
| 542 | <para>
|
|---|
| 543 | Sites that are being upgraded from Samba-2 (or earlier versions) to Samba-3
|
|---|
| 544 | may experience little difficulty or may require a lot of effort, depending
|
|---|
| 545 | on the complexity of the configuration. Samba-1.9.x upgrades to Samba-3 will
|
|---|
| 546 | generally be simple and straightforward, although no upgrade should be
|
|---|
| 547 | attempted without proper planning and preparation.
|
|---|
| 548 | </para>
|
|---|
| 549 |
|
|---|
| 550 | <para>
|
|---|
| 551 | There are two basic modes of use of Samba versions prior to Samba-3. The first
|
|---|
| 552 | does not use LDAP, the other does. Samba-1.9.x did not provide LDAP support.
|
|---|
| 553 | Samba-2.x could be compiled with LDAP support.
|
|---|
| 554 | </para>
|
|---|
| 555 |
|
|---|
| 556 | <sect2 id="sbeug2">
|
|---|
| 557 | <title>Samba 1.9.x and 2.x Versions Without LDAP</title>
|
|---|
| 558 |
|
|---|
| 559 | <para>
|
|---|
| 560 | Where it is necessary to upgrade an old Samba installation to Samba-3,
|
|---|
| 561 | the following procedure can be followed:
|
|---|
| 562 | </para>
|
|---|
| 563 |
|
|---|
| 564 | <procedure>
|
|---|
| 565 | <title>Upgrading from a Pre-Samba-3 Version</title>
|
|---|
| 566 |
|
|---|
| 567 | <step><para>
|
|---|
| 568 | <indexterm><primary>winbindd</primary></indexterm>
|
|---|
| 569 | <indexterm><primary>smbd</primary></indexterm>
|
|---|
| 570 | <indexterm><primary>nmbd</primary></indexterm>
|
|---|
| 571 | Stop Samba. This can be done using the appropriate system tool
|
|---|
| 572 | that is particular for each operating system or by executing the
|
|---|
| 573 | <command>kill</command> command on <command>smbd</command>,
|
|---|
| 574 | <command>nmbd</command>, and <command>winbindd</command>.
|
|---|
| 575 | </para></step>
|
|---|
| 576 |
|
|---|
| 577 | <step><para>
|
|---|
| 578 | Find the location of the Samba &smb.conf; file and back it up to a
|
|---|
| 579 | safe location.
|
|---|
| 580 | </para></step>
|
|---|
| 581 |
|
|---|
| 582 | <step><para>
|
|---|
| 583 | Find the location of the <filename>smbpasswd</filename> file and
|
|---|
| 584 | back it up to a safe location.
|
|---|
| 585 | </para></step>
|
|---|
| 586 |
|
|---|
| 587 | <step><para>
|
|---|
| 588 | Find the location of the <filename>secrets.tdb</filename> file and
|
|---|
| 589 | back it up to a safe location.
|
|---|
| 590 | </para></step>
|
|---|
| 591 |
|
|---|
| 592 | <step><para>
|
|---|
| 593 | <indexterm><primary>lock directory</primary></indexterm>
|
|---|
| 594 | <indexterm><primary>/usr/local/samba/var/locks</primary></indexterm>
|
|---|
| 595 | <indexterm><primary>/var/cache/samba</primary></indexterm>
|
|---|
| 596 | <indexterm><primary>/var/lib/samba</primary></indexterm>
|
|---|
| 597 | Find the location of the lock directory. This is the directory
|
|---|
| 598 | in which Samba stores all its tdb control files. The default
|
|---|
| 599 | location used by the Samba Team is in
|
|---|
| 600 | <filename>/usr/local/samba/var/locks</filename> directory,
|
|---|
| 601 | but on Linux systems the old location was under the
|
|---|
| 602 | <filename>/var/cache/samba</filename> directory. However, the
|
|---|
| 603 | Linux Standards Base specified location is now under the
|
|---|
| 604 | <filename>/var/lib/samba</filename> directory. Copy all the
|
|---|
| 605 | tdb files to a safe location.
|
|---|
| 606 | </para></step>
|
|---|
| 607 |
|
|---|
| 608 | <step><para>
|
|---|
| 609 | <indexterm><primary>RPM</primary></indexterm>
|
|---|
| 610 | It is now safe to upgrade the Samba installation. On Linux systems
|
|---|
| 611 | it is not necessary to remove the Samba RPMs because a simple
|
|---|
| 612 | upgrade installation will automatically remove the old files.
|
|---|
| 613 | </para>
|
|---|
| 614 |
|
|---|
| 615 | <para>
|
|---|
| 616 | On systems that do not support a reliable package management system
|
|---|
| 617 | it is advisable either to delete the Samba old installation or to
|
|---|
| 618 | move it out of the way by renaming the directories that contain the
|
|---|
| 619 | Samba binary files.
|
|---|
| 620 | </para></step>
|
|---|
| 621 |
|
|---|
| 622 | <step><para>
|
|---|
| 623 | When the Samba upgrade has been installed, the first step that should
|
|---|
| 624 | be completed is to identify the new target locations for the control
|
|---|
| 625 | files. Follow the steps shown in <link linkend="sbeug1"/> to locate
|
|---|
| 626 | the correct directories to which each control file must be moved.
|
|---|
| 627 | </para></step>
|
|---|
| 628 |
|
|---|
| 629 | <step><para>
|
|---|
| 630 | Do not change the hostname.
|
|---|
| 631 | </para></step>
|
|---|
| 632 |
|
|---|
| 633 | <step><para>
|
|---|
| 634 | Do not change the workgroup name.
|
|---|
| 635 | </para></step>
|
|---|
| 636 |
|
|---|
| 637 | <step><para>
|
|---|
| 638 | <indexterm><primary>testparm</primary></indexterm>
|
|---|
| 639 | Execute the <command>testparm</command> to validate the &smb.conf; file.
|
|---|
| 640 | This process will flag any parameters that are no longer supported.
|
|---|
| 641 | It will also flag configuration settings that may be in conflict.
|
|---|
| 642 | </para>
|
|---|
| 643 |
|
|---|
| 644 | <para>
|
|---|
| 645 | One solution that may be used to clean up and to update the &smb.conf;
|
|---|
| 646 | file involves renaming it to <filename>smb.conf.master</filename> and
|
|---|
| 647 | then executing the following:
|
|---|
| 648 | <screen>
|
|---|
| 649 | &rootprompt; cd /etc/samba
|
|---|
| 650 | &rootprompt; testparm -s smb.conf.master > smb.conf
|
|---|
| 651 | </screen>
|
|---|
| 652 | <indexterm><primary>stripped</primary></indexterm>
|
|---|
| 653 | The resulting &smb.conf; file will be stripped of all comments
|
|---|
| 654 | and of all nonconforming configuration settings.
|
|---|
| 655 | </para></step>
|
|---|
| 656 |
|
|---|
| 657 | <step><para>
|
|---|
| 658 | <indexterm><primary>winbindd</primary></indexterm>
|
|---|
| 659 | It is now safe to start Samba using the appropriate system tool.
|
|---|
| 660 | Alternately, it is possible to just execute <command>nmbd</command>,
|
|---|
| 661 | <command>smbd</command>, and <command>winbindd</command> for the command
|
|---|
| 662 | line while logged in as the root user.
|
|---|
| 663 | </para></step>
|
|---|
| 664 |
|
|---|
| 665 | </procedure>
|
|---|
| 666 |
|
|---|
| 667 | </sect2>
|
|---|
| 668 |
|
|---|
| 669 | <sect2>
|
|---|
| 670 | <title>Applicable to All Samba 2.x to Samba-3 Upgrades</title>
|
|---|
| 671 |
|
|---|
| 672 | <para>
|
|---|
| 673 | <indexterm><primary>PDC</primary></indexterm>
|
|---|
| 674 | <indexterm><primary>domain controller</primary></indexterm>
|
|---|
| 675 | <indexterm><primary>inter-domain</primary></indexterm>
|
|---|
| 676 | Samba 2.x servers that were running as a domain controller (PDC)
|
|---|
| 677 | require changes to the configuration of the scripting interface
|
|---|
| 678 | tools that Samba uses to perform OS updates for
|
|---|
| 679 | users, groups, and trust accounts (machines and interdomain).
|
|---|
| 680 | </para>
|
|---|
| 681 |
|
|---|
| 682 | <para>
|
|---|
| 683 | <indexterm><primary>parameters</primary></indexterm>
|
|---|
| 684 | The following parameters are new to Samba and should be correctly configured.
|
|---|
| 685 | Please refer to <link linkend="secure"/> through <link linkend="net2000users"/>
|
|---|
| 686 | in this book for examples of use of the new parameters shown here:
|
|---|
| 687 | <indexterm><primary>add group script</primary></indexterm>
|
|---|
| 688 | <indexterm><primary>add machine script</primary></indexterm>
|
|---|
| 689 | <indexterm><primary>add user to group script</primary></indexterm>
|
|---|
| 690 | <indexterm><primary>delete group script</primary></indexterm>
|
|---|
| 691 | <indexterm><primary>delete user from group script</primary></indexterm>
|
|---|
| 692 | <indexterm><primary>set primary group script</primary></indexterm>
|
|---|
| 693 | <indexterm><primary>passdb backend</primary></indexterm>
|
|---|
| 694 | </para>
|
|---|
| 695 |
|
|---|
| 696 | <para>
|
|---|
| 697 | <simplelist>
|
|---|
| 698 | <member>add group script</member>
|
|---|
| 699 | <member>add machine script</member>
|
|---|
| 700 | <member>add user to group script</member>
|
|---|
| 701 | <member>delete group script</member>
|
|---|
| 702 | <member>delete user from group script</member>
|
|---|
| 703 | <member>passdb backend</member>
|
|---|
| 704 | <member>set primary group script</member>
|
|---|
| 705 | </simplelist>
|
|---|
| 706 | </para>
|
|---|
| 707 |
|
|---|
| 708 | <para>
|
|---|
| 709 | <indexterm><primary>add machine script</primary></indexterm>
|
|---|
| 710 | <indexterm><primary>add user script</primary></indexterm>
|
|---|
| 711 | The <parameter>add machine script</parameter> functionality was previously
|
|---|
| 712 | handled by the <parameter>add user script</parameter>, which in Samba is
|
|---|
| 713 | used exclusively to add user accounts.
|
|---|
| 714 | </para>
|
|---|
| 715 |
|
|---|
| 716 | <para>
|
|---|
| 717 | <indexterm><primary>passdb backend</primary></indexterm>
|
|---|
| 718 | <indexterm><primary>smbpasswd</primary></indexterm>
|
|---|
| 719 | <indexterm><primary>tdbsam</primary></indexterm>
|
|---|
| 720 | <indexterm><primary>useradd</primary></indexterm>
|
|---|
| 721 | <indexterm><primary>usermod</primary></indexterm>
|
|---|
| 722 | <indexterm><primary>userdel</primary></indexterm>
|
|---|
| 723 | <indexterm><primary>groupadd</primary></indexterm>
|
|---|
| 724 | <indexterm><primary>groupmod</primary></indexterm>
|
|---|
| 725 | <indexterm><primary>groupdel</primary></indexterm>
|
|---|
| 726 | Where the <parameter>passdb backend</parameter> used is either <constant>smbpasswd</constant>
|
|---|
| 727 | (the default) or the new <constant>tdbsam</constant>, the system interface scripts
|
|---|
| 728 | are typically used. These involve use of OS tools such as <command>useradd</command>,
|
|---|
| 729 | <command>usermod</command>, <command>userdel</command>, <command>groupadd</command>,
|
|---|
| 730 | <command>groupmod</command>, <command>groupdel</command>, and so on.
|
|---|
| 731 | </para>
|
|---|
| 732 |
|
|---|
| 733 | <para>
|
|---|
| 734 | <indexterm><primary>passdb backend</primary></indexterm>
|
|---|
| 735 | <indexterm><primary>LDAP</primary></indexterm>
|
|---|
| 736 | <indexterm><primary>Idealx</primary></indexterm>
|
|---|
| 737 | Where the <parameter>passdb backend</parameter> makes use of an LDAP directory,
|
|---|
| 738 | it is necessary either to use the <constant>smbldap-tools</constant> provided
|
|---|
| 739 | by Idealx or to use an alternate toolset provided by a third
|
|---|
| 740 | party or else home-crafted to manage the LDAP directory accounts.
|
|---|
| 741 | </para>
|
|---|
| 742 |
|
|---|
| 743 | </sect2>
|
|---|
| 744 |
|
|---|
| 745 | <sect2>
|
|---|
| 746 | <title>Samba-2.x with LDAP Support</title>
|
|---|
| 747 |
|
|---|
| 748 | <para>
|
|---|
| 749 | Samba version 2.x could be compiled for use either with or without LDAP.
|
|---|
| 750 | The LDAP control settings in the &smb.conf; file in this old version are
|
|---|
| 751 | completely different (and less complete) than they are with Samba. This
|
|---|
| 752 | means that after migrating the control files, it is necessary to reconfigure
|
|---|
| 753 | the LDAP settings entirely.
|
|---|
| 754 | </para>
|
|---|
| 755 |
|
|---|
| 756 | <para>
|
|---|
| 757 | Follow the procedure outlined in <link linkend="sbeug2"/> to affect a migration
|
|---|
| 758 | of all files to the correct locations.
|
|---|
| 759 | </para>
|
|---|
| 760 |
|
|---|
| 761 | <para>
|
|---|
| 762 | <indexterm><primary>schema</primary></indexterm>
|
|---|
| 763 | <indexterm><primary>WHATSNEW.txt</primary></indexterm>
|
|---|
| 764 | The Samba SAM schema required for Samba-3 is significantly different from that
|
|---|
| 765 | used with Samba 2.x. This means that the LDAP directory must be updated
|
|---|
| 766 | using the procedure outlined in the Samba WHATSNEW.txt file that accompanies
|
|---|
| 767 | all releases of Samba-3. This information is repeated here directly from this
|
|---|
| 768 | file:
|
|---|
| 769 | <screen>
|
|---|
| 770 | This is an extract from the Samba-3.0.x WHATSNEW.txt file:
|
|---|
| 771 | ==========================================================
|
|---|
| 772 | Changes in Behavior
|
|---|
| 773 | -------------------
|
|---|
| 774 |
|
|---|
| 775 | The following issues are known changes in behavior between Samba 2.2 and
|
|---|
| 776 | Samba 3.0 that may affect certain installations of Samba.
|
|---|
| 777 |
|
|---|
| 778 | 1) When operating as a member of a Windows domain, Samba 2.2 would
|
|---|
| 779 | map any users authenticated by the remote DC to the 'guest account'
|
|---|
| 780 | if a uid could not be obtained via the getpwnam() call. Samba 3.0
|
|---|
| 781 | rejects the connection as NT_STATUS_LOGON_FAILURE. There is no
|
|---|
| 782 | current work around to re-establish the 2.2 behavior.
|
|---|
| 783 |
|
|---|
| 784 | 2) When adding machines to a Samba 2.2 controlled domain, the
|
|---|
| 785 | 'add user script' was used to create the UNIX identity of the
|
|---|
| 786 | machine trust account. Samba 3.0 introduces a new 'add machine
|
|---|
| 787 | script' that must be specified for this purpose. Samba 3.0 will
|
|---|
| 788 | not fall back to using the 'add user script' in the absence of
|
|---|
| 789 | an 'add machine script'
|
|---|
| 790 |
|
|---|
| 791 | ######################################################################
|
|---|
| 792 | Passdb Backends and Authentication
|
|---|
| 793 | ##################################
|
|---|
| 794 |
|
|---|
| 795 | There have been a few new changes that Samba administrators should be
|
|---|
| 796 | aware of when moving to Samba 3.0.
|
|---|
| 797 |
|
|---|
| 798 | 1) encrypted passwords have been enabled by default in order to
|
|---|
| 799 | inter-operate better with out-of-the-box Windows client
|
|---|
| 800 | installations. This does mean that either (a) a samba account
|
|---|
| 801 | must be created for each user, or (b) 'encrypt passwords = no'
|
|---|
| 802 | must be explicitly defined in smb.conf.
|
|---|
| 803 |
|
|---|
| 804 | 2) Inclusion of new 'security = ads' option for integration
|
|---|
| 805 | with an Active Directory domain using the native Windows
|
|---|
| 806 | Kerberos 5 and LDAP protocols.
|
|---|
| 807 |
|
|---|
| 808 | MIT kerberos 1.3.1 supports the ARCFOUR-HMAC-MD5 encryption
|
|---|
| 809 | type which is necessary for servers on which the
|
|---|
| 810 | administrator password has not been changed, or kerberos-enabled
|
|---|
| 811 | SMB connections to servers that require Kerberos SMB signing.
|
|---|
| 812 | Besides this one difference, either MIT or Heimdal Kerberos
|
|---|
| 813 | distributions are usable by Samba 3.0.
|
|---|
| 814 |
|
|---|
| 815 |
|
|---|
| 816 | Samba 3.0 also includes the possibility of setting up chains
|
|---|
| 817 | of authentication methods (auth methods) and account storage
|
|---|
| 818 | backends (passdb backend). Please refer to the smb.conf(5)
|
|---|
| 819 | man page for details. While both parameters assume sane default
|
|---|
| 820 | values, it is likely that you will need to understand what the
|
|---|
| 821 | values actually mean in order to ensure Samba operates correctly.
|
|---|
| 822 |
|
|---|
| 823 | The recommended passdb backends at this time are
|
|---|
| 824 |
|
|---|
| 825 | * smbpasswd - 2.2 compatible flat file format
|
|---|
| 826 | * tdbsam - attribute rich database intended as an smbpasswd
|
|---|
| 827 | replacement for stand alone servers
|
|---|
| 828 | * ldapsam - attribute rich account storage and retrieval
|
|---|
| 829 | backend utilizing an LDAP directory.
|
|---|
| 830 |
|
|---|
| 831 | Certain functions of the smbpasswd(8) tool have been split between the
|
|---|
| 832 | new smbpasswd(8) utility, the net(8) tool, and the new pdbedit(8)
|
|---|
| 833 | utility. See the respective man pages for details.
|
|---|
| 834 |
|
|---|
| 835 | New Suffix for Searching
|
|---|
| 836 | ------------------------
|
|---|
| 837 |
|
|---|
| 838 | The following new smb.conf parameters have been added to aid in directing
|
|---|
| 839 | certain LDAP queries when 'passdb backend = ldapsam://...' has been
|
|---|
| 840 | specified.
|
|---|
| 841 |
|
|---|
| 842 | * ldap suffix - used to search for user and computer accounts
|
|---|
| 843 | * ldap user suffix - used to store user accounts
|
|---|
| 844 | * ldap machine suffix - used to store machine trust accounts
|
|---|
| 845 | * ldap group suffix - location of posixGroup/sambaGroupMapping entries
|
|---|
| 846 | * ldap idmap suffix - location of sambaIdmapEntry objects
|
|---|
| 847 |
|
|---|
| 848 | If an 'ldap suffix' is defined, it will be appended to all of the
|
|---|
| 849 | remaining sub-suffix parameters. In this case, the order of the suffix
|
|---|
| 850 | listings in smb.conf is important. Always place the 'ldap suffix' first
|
|---|
| 851 | in the list.
|
|---|
| 852 |
|
|---|
| 853 | Due to a limitation in Samba's smb.conf parsing, you should not surround
|
|---|
| 854 | the DN's with quotation marks.
|
|---|
| 855 | </screen>
|
|---|
| 856 | </para>
|
|---|
| 857 |
|
|---|
| 858 | </sect2>
|
|---|
| 859 |
|
|---|
| 860 | </sect1>
|
|---|
| 861 |
|
|---|
| 862 | <sect1>
|
|---|
| 863 | <title>Updating a Samba-3 Installation</title>
|
|---|
| 864 |
|
|---|
| 865 | <para>
|
|---|
| 866 | The key concern in this section is to deal with the changes that have been
|
|---|
| 867 | affected in Samba-3 between the Samba-3.0.0 release and the current update.
|
|---|
| 868 | Network administrators have expressed concerns over the steps that should be
|
|---|
| 869 | taken to update Samba-3 versions.
|
|---|
| 870 | </para>
|
|---|
| 871 |
|
|---|
| 872 | <para>
|
|---|
| 873 | <indexterm><primary>control files</primary></indexterm>
|
|---|
| 874 | The information in <link linkend="sbeug1"/> would not be necessary if every
|
|---|
| 875 | person who has ever produced Samba executable (binary) files could agree on
|
|---|
| 876 | the preferred location of the &smb.conf; file and other Samba control files.
|
|---|
| 877 | Clearly, such agreement is further away than a pipedream.
|
|---|
| 878 | </para>
|
|---|
| 879 |
|
|---|
| 880 | <para>
|
|---|
| 881 | <indexterm><primary>vendors</primary></indexterm>
|
|---|
| 882 | Vendors and packagers who produce Samba binary installable packages do not,
|
|---|
| 883 | as a rule, use the default paths used by the Samba-Team for the location of
|
|---|
| 884 | the binary files, the &smb.conf; file, and the Samba control files (tdb's
|
|---|
| 885 | as well as files such as <filename>secrets.tdb</filename>). This means that
|
|---|
| 886 | the network or UNIX administrator who sets out to build the Samba executable
|
|---|
| 887 | files from the Samba tarball must take particular care. Failure to take care
|
|---|
| 888 | will result in both the original vendor's version of Samba remaining installed
|
|---|
| 889 | and the new version being installed in the default location used
|
|---|
| 890 | by the Samba-Team. This can lead to confusion and to much lost time as the
|
|---|
| 891 | uninformed administrator deals with apparent failure of the update to take
|
|---|
| 892 | effect.
|
|---|
| 893 | </para>
|
|---|
| 894 |
|
|---|
| 895 | <para>
|
|---|
| 896 | <indexterm><primary>packages</primary></indexterm>
|
|---|
| 897 | The best advice for those lacking in code compilation experience is to use
|
|---|
| 898 | only vendor (or Samba-Team) provided binary packages. The Samba packages
|
|---|
| 899 | that are provided by the Samba-Team are generally built to use file paths
|
|---|
| 900 | that are compatible with the original OS vendor's practices.
|
|---|
| 901 | </para>
|
|---|
| 902 |
|
|---|
| 903 | <para>
|
|---|
| 904 | <indexterm><primary>binary package</primary></indexterm>
|
|---|
| 905 | <indexterm><primary>binary files</primary></indexterm>
|
|---|
| 906 | If you are not sure whether a binary package complies with the OS
|
|---|
| 907 | vendor's practices, it is better to ask the package maintainer via
|
|---|
| 908 | email than to waste much time dealing with the nuances.
|
|---|
| 909 | Alternately, just diagnose the paths specified by the binary files following
|
|---|
| 910 | the procedure outlined above.
|
|---|
| 911 | </para>
|
|---|
| 912 |
|
|---|
| 913 | <sect2>
|
|---|
| 914 | <title>Samba to Samba-3 Updates on the Same Server</title>
|
|---|
| 915 |
|
|---|
| 916 | <para>
|
|---|
| 917 | The guidance in this section deals with updates to an existing
|
|---|
| 918 | Samba server installation.
|
|---|
| 919 | </para>
|
|---|
| 920 |
|
|---|
| 921 | <sect3>
|
|---|
| 922 | <title>Updating from Samba Versions Earlier than 3.0.5</title>
|
|---|
| 923 |
|
|---|
| 924 | <para>
|
|---|
| 925 | With the provision that the binary Samba package has been built
|
|---|
| 926 | with the same path and feature settings as the existing Samba
|
|---|
| 927 | package that is being updated, an update of Samba versions 3.0.0
|
|---|
| 928 | through 3.0.4 can be updated to 3.0.5 without loss of functionality
|
|---|
| 929 | and without need to change either the &smb.conf; file or, where
|
|---|
| 930 | used, the LDAP schema.
|
|---|
| 931 | </para>
|
|---|
| 932 |
|
|---|
| 933 | </sect3>
|
|---|
| 934 |
|
|---|
| 935 | <sect3>
|
|---|
| 936 | <title>Updating from Samba Versions between 3.0.6 and 3.0.10</title>
|
|---|
| 937 |
|
|---|
| 938 | <para>
|
|---|
| 939 | <indexterm><primary>schema</primary></indexterm>
|
|---|
| 940 | <indexterm><primary>LDAP</primary><secondary>schema</secondary></indexterm>
|
|---|
| 941 | When updating versions of Samba prior to 3.0.6 to 3.0.6 through 3.0.10,
|
|---|
| 942 | it is necessary only to update the LDAP schema (where LDAP is used).
|
|---|
| 943 | Always use the LDAP schema file that is shipped with the latest Samba
|
|---|
| 944 | update.
|
|---|
| 945 | </para>
|
|---|
| 946 |
|
|---|
| 947 | <para>
|
|---|
| 948 | <indexterm><primary>ldapsam</primary></indexterm>
|
|---|
| 949 | <indexterm><primary>tdbsam</primary></indexterm>
|
|---|
| 950 | <indexterm><primary>passdb backend</primary></indexterm>
|
|---|
| 951 | Samba-3.0.6 introduced the ability to remember the last <emphasis>n</emphasis> number
|
|---|
| 952 | of passwords a user has used. This information will work only with
|
|---|
| 953 | the <constant>tdbsam</constant> and <constant>ldapsam</constant>
|
|---|
| 954 | <parameter>passdb backend</parameter> facilities.
|
|---|
| 955 | </para>
|
|---|
| 956 |
|
|---|
| 957 | <para>
|
|---|
| 958 | After updating the LDAP schema, do not forget to re-index the LDAP database.
|
|---|
| 959 | </para>
|
|---|
| 960 |
|
|---|
| 961 | </sect3>
|
|---|
| 962 |
|
|---|
| 963 | <sect3>
|
|---|
| 964 | <title>Updating from Samba Versions after 3.0.6 to a Current Release</title>
|
|---|
| 965 |
|
|---|
| 966 | <para>
|
|---|
| 967 | <indexterm><primary>winbindd</primary></indexterm>
|
|---|
| 968 | Samba-3.0.8 introduced changes in how the <parameter>username map</parameter>
|
|---|
| 969 | behaves. It also included a change in behavior of <command>winbindd</command>.
|
|---|
| 970 | Please refer to the man page for &smb.conf; before implementing any update
|
|---|
| 971 | from versions prior to 3.0.8 to a current version.
|
|---|
| 972 | </para>
|
|---|
| 973 |
|
|---|
| 974 | <para>
|
|---|
| 975 | <indexterm><primary>privileges</primary></indexterm>
|
|---|
| 976 | In Samba-3.0.11 a new privileges interface was implemented. Please
|
|---|
| 977 | refer to <link linkend="sbehap-ppc"/> for information regarding this new
|
|---|
| 978 | feature. It is not necessary to implement the privileges interface, but it
|
|---|
| 979 | is one that has been requested for several years and thus may be of interest
|
|---|
| 980 | at your site.
|
|---|
| 981 | </para>
|
|---|
| 982 |
|
|---|
| 983 | <para>
|
|---|
| 984 | In Samba-3.0.11 there were some functional changes to the <parameter>ldap user
|
|---|
| 985 | suffix</parameter> and to the <parameter>ldap machine suffix</parameter> behaviors.
|
|---|
| 986 | The following information has been extracted from the WHATSNEW.txt file from this
|
|---|
| 987 | release:
|
|---|
| 988 | <screen>
|
|---|
| 989 | ============
|
|---|
| 990 | LDAP Changes
|
|---|
| 991 | ============
|
|---|
| 992 |
|
|---|
| 993 | If "ldap user suffix" or "ldap machine suffix" are defined in
|
|---|
| 994 | smb.conf, all user-accounts must reside below the user suffix,
|
|---|
| 995 | and all machine and inter-domain trust-accounts must be located
|
|---|
| 996 | below the machine suffix. Previous Samba releases would fall
|
|---|
| 997 | back to searching the 'ldap suffix' in some cases.
|
|---|
| 998 | </screen>
|
|---|
| 999 | </para>
|
|---|
| 1000 |
|
|---|
| 1001 | </sect3>
|
|---|
| 1002 | </sect2>
|
|---|
| 1003 |
|
|---|
| 1004 | <sect2>
|
|---|
| 1005 | <title>Migrating Samba to a New Server</title>
|
|---|
| 1006 |
|
|---|
| 1007 | <para>
|
|---|
| 1008 | The two most likely candidates for replacement of a server are
|
|---|
| 1009 | domain member servers and domain controllers. Each needs to be
|
|---|
| 1010 | handled slightly differently.
|
|---|
| 1011 | </para>
|
|---|
| 1012 |
|
|---|
| 1013 | <sect3>
|
|---|
| 1014 | <title>Replacing a Domain Member Server</title>
|
|---|
| 1015 |
|
|---|
| 1016 | <para>
|
|---|
| 1017 | <indexterm><primary>DMS</primary></indexterm>
|
|---|
| 1018 | Replacement of a domain member server should be done
|
|---|
| 1019 | using the same procedure as outlined in <link linkend="unixclients"/>.
|
|---|
| 1020 | </para>
|
|---|
| 1021 |
|
|---|
| 1022 | <para>
|
|---|
| 1023 | Usually the new server will be introduced with a temporary name. After
|
|---|
| 1024 | the old server data has been migrated to the new server, it is customary
|
|---|
| 1025 | that the new server be renamed to that of the old server. This will
|
|---|
| 1026 | change its SID and will necessitate rejoining to the domain.
|
|---|
| 1027 | </para>
|
|---|
| 1028 |
|
|---|
| 1029 | <para>
|
|---|
| 1030 | <indexterm><primary>smbd</primary></indexterm>
|
|---|
| 1031 | <indexterm><primary>nmbd</primary></indexterm>
|
|---|
| 1032 | <indexterm><primary>winbindd</primary></indexterm>
|
|---|
| 1033 | <indexterm><primary>wins.dat</primary></indexterm>
|
|---|
| 1034 | <indexterm><primary>browse.dat</primary></indexterm>
|
|---|
| 1035 | <indexterm><primary>resolution</primary></indexterm>
|
|---|
| 1036 | Following a change of hostname (NetBIOS name) it is a good idea on all servers
|
|---|
| 1037 | to shut down the Samba <command>smbd</command>, <command>nmbd</command>, and
|
|---|
| 1038 | <command>winbindd</command> services, delete the <filename>wins.dat</filename>
|
|---|
| 1039 | and <filename>browse.dat</filename> files, then restart Samba. This will ensure
|
|---|
| 1040 | that the old name and IP address information is no longer able to interfere with
|
|---|
| 1041 | name to IP address resolution. If this is not done, there can be temporary name
|
|---|
| 1042 | resolution problems. These problems usually clear within 45 minutes of a name
|
|---|
| 1043 | change, but can persist for a longer period of time.
|
|---|
| 1044 | </para>
|
|---|
| 1045 |
|
|---|
| 1046 | <para>
|
|---|
| 1047 | <indexterm><primary>DMS</primary></indexterm>
|
|---|
| 1048 | <indexterm><primary>/etc/passwd</primary></indexterm>
|
|---|
| 1049 | <indexterm><primary>/etc/shadow</primary></indexterm>
|
|---|
| 1050 | <indexterm><primary>/etc/group</primary></indexterm>
|
|---|
| 1051 | If the old domain member server had local accounts, it is necessary to create
|
|---|
| 1052 | on the new domain member server the same accounts with the same UID and GID
|
|---|
| 1053 | for each account. Where the <parameter>passdb backend</parameter> database
|
|---|
| 1054 | is stored in the <constant>smbpasswd</constant> or in the
|
|---|
| 1055 | <constant>tdbsam</constant> format, the user and group account information
|
|---|
| 1056 | for UNIX accounts that match the Samba accounts will reside in the system
|
|---|
| 1057 | <filename>/etc/passwd</filename>, <filename>/etc/shadow</filename>, and
|
|---|
| 1058 | <filename>/etc/group</filename> files. In this case, be sure to copy these
|
|---|
| 1059 | account entries to the new target server.
|
|---|
| 1060 | </para>
|
|---|
| 1061 |
|
|---|
| 1062 | <para>
|
|---|
| 1063 | <indexterm><primary>nss_ldap</primary></indexterm>
|
|---|
| 1064 | Where the user accounts for both UNIX and Samba are stored in LDAP, the new
|
|---|
| 1065 | target server must be configured to use the <command>nss_ldap</command> tool set.
|
|---|
| 1066 | This will automatically ensure that the appropriate user entities are
|
|---|
| 1067 | available on the new server.
|
|---|
| 1068 | </para>
|
|---|
| 1069 |
|
|---|
| 1070 | </sect3>
|
|---|
| 1071 |
|
|---|
| 1072 | <sect3>
|
|---|
| 1073 | <title>Replacing a Domain Controller</title>
|
|---|
| 1074 |
|
|---|
| 1075 | <para>
|
|---|
| 1076 | <indexterm><primary>domain</primary><secondary>controller</secondary></indexterm>
|
|---|
| 1077 | In the past, people who replaced a Windows NT4 domain controller typically
|
|---|
| 1078 | installed a new server, created printers and file shares on it, then migrate across
|
|---|
| 1079 | all data that was destined to reside on it. The same can of course be done with
|
|---|
| 1080 | Samba.
|
|---|
| 1081 | </para>
|
|---|
| 1082 |
|
|---|
| 1083 | <para>
|
|---|
| 1084 | From recent mailing list postings it would seem that some administrators
|
|---|
| 1085 | have the intent to just replace the old Samba server with a new one with
|
|---|
| 1086 | the same name as the old one. In this case, simply follow the same process
|
|---|
| 1087 | as for upgrading a Samba 2.x system and do the following:
|
|---|
| 1088 | </para>
|
|---|
| 1089 |
|
|---|
| 1090 | <itemizedlist>
|
|---|
| 1091 | <listitem><para>
|
|---|
| 1092 | Where UNIX (POSIX) user and group accounts are stored in the system
|
|---|
| 1093 | <filename>/etc/passwd</filename>, <filename>/etc/shadow</filename>, and
|
|---|
| 1094 | <filename>/etc/group</filename> files, be sure to add the same accounts
|
|---|
| 1095 | with identical UID and GID values for each user.
|
|---|
| 1096 | </para>
|
|---|
| 1097 |
|
|---|
| 1098 | <para>
|
|---|
| 1099 | Where LDAP is used, if the new system is intended to be the LDAP server,
|
|---|
| 1100 | migrate it across by configuring the LDAP server
|
|---|
| 1101 | (<filename>/etc/openldap/slapd.conf</filename>). The directory can
|
|---|
| 1102 | be populated either initially by setting this LDAP server up as a slave or
|
|---|
| 1103 | by dumping the data from the old LDAP server using the <command>slapcat</command>
|
|---|
| 1104 | command and then reloading the same data into the new LDAP server using the
|
|---|
| 1105 | <command>slapadd</command> command. Do not forget to install and configure
|
|---|
| 1106 | the <command>nss_ldap</command> tool and the <filename>/etc/nsswitch.conf</filename>
|
|---|
| 1107 | (as shown in <link linkend="happy"/>).
|
|---|
| 1108 | </para></listitem>
|
|---|
| 1109 |
|
|---|
| 1110 | <listitem><para>
|
|---|
| 1111 | Copy the &smb.conf; file from the old server to the new server into the correct
|
|---|
| 1112 | location as indicated previously in this chapter.
|
|---|
| 1113 | </para></listitem>
|
|---|
| 1114 |
|
|---|
| 1115 | <listitem><para>
|
|---|
| 1116 | Copy the <filename>secrets.tdb</filename> file, the <filename>smbpasswd</filename>
|
|---|
| 1117 | file (if it is used), the <filename>/etc/samba/passdb.tdb</filename> file (only
|
|---|
| 1118 | used by the <constant>tdbsam</constant> backend), and all the tdb control files
|
|---|
| 1119 | from the old system to the correct location on the new system.
|
|---|
| 1120 | </para></listitem>
|
|---|
| 1121 |
|
|---|
| 1122 | <listitem><para>
|
|---|
| 1123 | Before starting the Samba daemons, verify that the hostname of the new server
|
|---|
| 1124 | is identical to that of the old one. Note: The IP address can be different
|
|---|
| 1125 | from that of the old server.
|
|---|
| 1126 | </para></listitem>
|
|---|
| 1127 |
|
|---|
| 1128 | <listitem><para>
|
|---|
| 1129 | Copy all files from the old server to the new server, taking precaution to
|
|---|
| 1130 | preserve all file ownership and permissions as well as any POSIX ACLs that
|
|---|
| 1131 | may have been created on the old server.
|
|---|
| 1132 | </para></listitem>
|
|---|
| 1133 | </itemizedlist>
|
|---|
| 1134 |
|
|---|
| 1135 | <para>
|
|---|
| 1136 | When replacing a Samba domain controller (PDC or BDC) that uses LDAP, the new server
|
|---|
| 1137 | need simply be configured to use the LDAP directory, and for the rest it should just
|
|---|
| 1138 | work. The domain SID is obtained from the LDAP directory as part of the first connect
|
|---|
| 1139 | to the LDAP directory server.
|
|---|
| 1140 | </para>
|
|---|
| 1141 |
|
|---|
| 1142 | <para>
|
|---|
| 1143 | All Samba servers, other than one that uses LDAP, depend on the tdb files, and
|
|---|
| 1144 | particularly on the <filename>secrets.tdb</filename> file. So long as the tdb files are
|
|---|
| 1145 | all in place, the &smb.conf; file is preserved, and either the hostname is identical
|
|---|
| 1146 | or the <parameter>netbios name</parameter> is set to the original server name, Samba
|
|---|
| 1147 | should correctly pick up the original SID and preserve all other settings. It is
|
|---|
| 1148 | sound advice to validate this before turning the system over to users.
|
|---|
| 1149 | </para>
|
|---|
| 1150 |
|
|---|
| 1151 | </sect3>
|
|---|
| 1152 |
|
|---|
| 1153 | </sect2>
|
|---|
| 1154 |
|
|---|
| 1155 | <sect2>
|
|---|
| 1156 | <title>Migration of Samba Accounts to Active Directory</title>
|
|---|
| 1157 |
|
|---|
| 1158 | <para>
|
|---|
| 1159 | Yes, it works. The Windows ADMT tool can be used to migrate Samba accounts
|
|---|
| 1160 | to MS Active Directory. There are a few pitfalls to be aware of:
|
|---|
| 1161 | </para>
|
|---|
| 1162 |
|
|---|
| 1163 | <procedure>
|
|---|
| 1164 | <title>Migration to Active Directory</title>
|
|---|
| 1165 |
|
|---|
| 1166 | <step><para>
|
|---|
| 1167 | Administrator password must be THE SAME on the Samba server,
|
|---|
| 1168 | the 2003 ADS, and the local Administrator account on the workstations.
|
|---|
| 1169 | Perhaps this goes without saying, but there needs to be an account
|
|---|
| 1170 | called <constant>Administrator</constant> in your Samba domain, with
|
|---|
| 1171 | full administrative (root) rights to that domain.
|
|---|
| 1172 | </para></step>
|
|---|
| 1173 |
|
|---|
| 1174 | <step><para>
|
|---|
| 1175 | In the Advanced/DNS section of the TCP/IP settings on your Windows
|
|---|
| 1176 | workstations, make sure the <parameter>DNS suffix for this
|
|---|
| 1177 | connection</parameter> field is blank.
|
|---|
| 1178 | </para></step>
|
|---|
| 1179 |
|
|---|
| 1180 | <step><para>
|
|---|
| 1181 | Because you are migrating from Samba, user passwords cannot be
|
|---|
| 1182 | migrated. You'll have to reset everyone's passwords. (If you were
|
|---|
| 1183 | migrating from NT4 to ADS, you could migrate passwords as well.)
|
|---|
| 1184 | </para>
|
|---|
| 1185 |
|
|---|
| 1186 | <para>
|
|---|
| 1187 | To date this has not been attempted with roaming profile support;
|
|---|
| 1188 | it has been documented as working with local profiles.
|
|---|
| 1189 | </para></step>
|
|---|
| 1190 |
|
|---|
| 1191 | <step><para>
|
|---|
| 1192 | Disable the Windows Firewall on all workstations. Otherwise,
|
|---|
| 1193 | workstations won't be migrated to the new domain.
|
|---|
| 1194 | </para></step>
|
|---|
| 1195 |
|
|---|
| 1196 | <step><para>
|
|---|
| 1197 | <indexterm><primary>ADMT</primary></indexterm>
|
|---|
| 1198 | When migrating machines, always test first (using ADMT's test mode)
|
|---|
| 1199 | and satisfy all errors before committing the migration. Note that the
|
|---|
| 1200 | test will always fail, because the machine will not have been actually
|
|---|
| 1201 | migrated. You'll need to interpret the errors to know whether the
|
|---|
| 1202 | failure was due to a problem or simply to the fact that it was just
|
|---|
| 1203 | a test.
|
|---|
| 1204 | </para></step>
|
|---|
| 1205 |
|
|---|
| 1206 | </procedure>
|
|---|
| 1207 |
|
|---|
| 1208 |
|
|---|
| 1209 | <para>
|
|---|
| 1210 | <indexterm><primary>ADMT</primary></indexterm>
|
|---|
| 1211 | There are some significant benefits of using the ADMT, besides just
|
|---|
| 1212 | migrating user accounts. ADMT can be found on the Windows 2003 CD.
|
|---|
| 1213 | </para>
|
|---|
| 1214 |
|
|---|
| 1215 | <itemizedlist>
|
|---|
| 1216 | <listitem><para>
|
|---|
| 1217 | You can migrate workstations remotely. You can specify that SIDs
|
|---|
| 1218 | be simply added instead of replaced, giving you the option of joining a
|
|---|
| 1219 | workstation back to the old domain if something goes awry. The
|
|---|
| 1220 | workstations will be joined to the new domain.
|
|---|
| 1221 | </para></listitem>
|
|---|
| 1222 |
|
|---|
| 1223 | <listitem><para>
|
|---|
| 1224 | Not only are user accounts migrated from the old domain to the new
|
|---|
| 1225 | domain, but ACLs on the workstations are migrated as well. Like SIDs,
|
|---|
| 1226 | ACLs can be added instead of replaced.
|
|---|
| 1227 | </para></listitem>
|
|---|
| 1228 |
|
|---|
| 1229 | <listitem><para>
|
|---|
| 1230 | Locally stored user profiles on workstations are migrated as well,
|
|---|
| 1231 | presenting almost no disruption to the user. Saved passwords will be
|
|---|
| 1232 | lost, just as when you administratively reset the password in Windows ADS.
|
|---|
| 1233 | </para></listitem>
|
|---|
| 1234 |
|
|---|
| 1235 | <listitem><para>
|
|---|
| 1236 | The ADMT lets you test all operations before actually performing the
|
|---|
| 1237 | migration. Accounts and workstations can be migrated individually or in
|
|---|
| 1238 | batches. User accounts can be safely migrated all at once (since no
|
|---|
| 1239 | changes are made on the original domain). It is recommended to migrate only one
|
|---|
| 1240 | or two workstations as a test before committing them all.
|
|---|
| 1241 | </para></listitem>
|
|---|
| 1242 |
|
|---|
| 1243 | </itemizedlist>
|
|---|
| 1244 |
|
|---|
| 1245 | </sect2>
|
|---|
| 1246 |
|
|---|
| 1247 | </sect1>
|
|---|
| 1248 |
|
|---|
| 1249 | </chapter>
|
|---|
