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-3</title> 5 6<para> 7<indexterm><primary>migrate</primary></indexterm> 8<indexterm><primary>install</primary></indexterm> 9It was a little difficult to select an appropriate title for this chapter. 10From email messages on the Samba mailing lists it is clear that many people 11consider the updating and upgrading of Samba to be a migration matter. Others 12talk about migrating Samba servers when in fact the issue at hand is one of 13installing 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> 19There has also been much talk about migration of Samba-3 from an smbpasswd 20passdb backend to the use of the tdbsam or ldapsam facilities that are new 21to Samba-3. 22</para> 23 24<para> 25Clearly, there is not a great deal of clarity in the terminology that various 26people apply to these modes by which Samba servers are updated. This is further 27highlighted 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> 32I like the <quote>net rpc vampire</quote> on NT4, but that to my surprise does 33not seem to work against a Samba PDC and, if addressed in the Samba to Samba 34context in either book, I could not find it. 35</para></blockquote> 36 37<para> 38<indexterm><primary>contributions</primary></indexterm> 39So in response to the significant request for these situations to be better 40documented, this chapter has now been added. User contributions and documentation 41of 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> 51A Windows network administrator explained in an email what changes he was 52planning to make and followed with the question: <quote>Anyone done this 53before?</quote> Many of us have upgraded and updated Samba without incident. 54Others have experienced much pain and user frustration. So it is to be hoped 55that the notes in this chapter will make a positive difference by assuring 56that someone will be saved a lot of discomfort. 57</para> 58 59<para> 60Before anyone commences an upgrade or an update of Samba, the one cardinal 61rule that must be observed is: Backup all Samba configuration files in 62case it is necessary to revert to the old version. Even if you do not like 63this precautionary step, users will punish an administrator who 64fails to take adequate steps to avoid situations that may inflict lost 65productivity on them. 66</para> 67 68<warning><para> 69<indexterm><primary>configuration files</primary></indexterm> 70<indexterm><primary>down-grade</primary></indexterm> 71Samba makes it possible to upgrade and update configuration files, but it 72is not possible to downgrade the configuration files. Please ensure that 73all configuration and control files are backed up to permit a down-grade 74in 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> 81It is prudent also to backup all data files on the server before attempting 82to perform a major upgrade. Many administrators have experienced the consequences 83of failure to take adequate precautions. So what is adequate? That is simple! 84If data is lost during an upgrade or update and it can not be restored, 85the precautions taken were inadequate. If a backup was not needed, but was available, 86caution 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-3 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-3): 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> 248SID 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-3 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-3 by executing: 299<screen> 300&rootprompt; net rpc info -Uroot%password 301Domain Name: MIDEARTH 302Domain SID: S-1-5-21-726309263-4128913605-1168186429 303Sequence number: 1113415916 304Num users: 4237 305Num domain groups: 86 306Num 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-3 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 439Build 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 447Paths: 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-3 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-3 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> 543Sites that are being upgraded from Samba-2 (or earlier versions) to Samba-3 544may experience little difficulty or may require a lot of effort, depending 545on the complexity of the configuration. Samba-1.9.x upgrades to Samba-3 will 546generally be simple and straightforward, although no upgrade should be 547attempted without proper planning and preparation. 548</para> 549 550<para> 551There are two basic modes of use of Samba versions prior to Samba-3. The first 552does not use LDAP, the other does. Samba-1.9.x did not provide LDAP support. 553Samba-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-3 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-3 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-3. 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> 770This is an extract from the Samba-3.0.x WHATSNEW.txt file: 771========================================================== 772Changes in Behavior 773------------------- 774 775The following issues are known changes in behavior between Samba 2.2 and 776Samba 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###################################################################### 792Passdb Backends and Authentication 793################################## 794 795There have been a few new changes that Samba administrators should be 796aware 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 816Samba 3.0 also includes the possibility of setting up chains 817of authentication methods (auth methods) and account storage 818backends (passdb backend). Please refer to the smb.conf(5) 819man page for details. While both parameters assume sane default 820values, it is likely that you will need to understand what the 821values actually mean in order to ensure Samba operates correctly. 822 823The 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 * ldapsam_compat - a 2.2 backward compatible LDAP account 831 backend 832 833Certain functions of the smbpasswd(8) tool have been split between the 834new smbpasswd(8) utility, the net(8) tool, and the new pdbedit(8) 835utility. See the respective man pages for details. 836 837###################################################################### 838LDAP 839#### 840 841This section outlines the new features affecting Samba / LDAP 842integration. 843 844New Schema 845---------- 846 847A new object class (sambaSamAccount) has been introduced to replace 848the old sambaAccount. This change aids us in the renaming of 849attributes to prevent clashes with attributes from other vendors. 850There is a conversion script (examples/LDAP/convertSambaAccount) to 851modify and LDIF file to the new schema. 852 853Example: 854 855 $ ldapsearch .... -b "ou=people,dc=..." > sambaAcct.ldif 856 $ convertSambaAccount --sid=<Domain SID> \ 857 --input=sambaAcct.ldif --output=sambaSamAcct.ldif \ 858 --changetype=[modify|add] 859 860The <DOM SID> can be obtained by running 'net getlocalsid 861<DOMAINNAME>' on the Samba PDC as root. The changetype determines 862the format of the generated LDIF output--either create new entries 863or modify existing entries. 864 865The old sambaAccount schema may still be used by specifying the 866"ldapsam_compat" passdb backend. However, the sambaAccount and 867associated attributes have been moved to the historical section of 868the schema file and must be uncommented before use if needed. 869The 2.2 object class declaration for a sambaAccount has not changed 870in the 3.0 samba.schema file. 871 872Other new object classes and their uses include: 873 874 * sambaDomain - domain information used to allocate rids 875 for users and groups as necessary. The attributes are added 876 in 'ldap suffix' directory entry automatically if 877 an idmap uid/gid range has been set and the 'ldapsam' 878 passdb backend has been selected. 879 880 * sambaGroupMapping - an object representing the 881 relationship between a posixGroup and a Windows 882 group/SID. These entries are stored in the 'ldap 883 group suffix' and managed by the 'net groupmap' command. 884 885 * sambaUnixIdPool - created in the 'ldap idmap suffix' entry 886 automatically and contains the next available 'idmap uid' and 887 'idmap gid' 888 889 * sambaIdmapEntry - object storing a mapping between a 890 SID and a UNIX uid/gid. These objects are created by the 891 idmap_ldap module as needed. 892 893 * sambaSidEntry - object representing a SID alone, as a Structural 894 class on which to build the sambaIdmapEntry. 895 896 897New Suffix for Searching 898------------------------ 899 900The following new smb.conf parameters have been added to aid in directing 901certain LDAP queries when 'passdb backend = ldapsam://...' has been 902specified. 903 904 * ldap suffix - used to search for user and computer accounts 905 * ldap user suffix - used to store user accounts 906 * ldap machine suffix - used to store machine trust accounts 907 * ldap group suffix - location of posixGroup/sambaGroupMapping entries 908 * ldap idmap suffix - location of sambaIdmapEntry objects 909 910If an 'ldap suffix' is defined, it will be appended to all of the 911remaining sub-suffix parameters. In this case, the order of the suffix 912listings in smb.conf is important. Always place the 'ldap suffix' first 913in the list. 914 915Due to a limitation in Samba's smb.conf parsing, you should not surround 916the DN's with quotation marks. 917</screen> 918 </para> 919 920 </sect2> 921 922</sect1> 923 924<sect1> 925<title>Updating a Samba-3 Installation</title> 926 927<para> 928The key concern in this section is to deal with the changes that have been 929affected in Samba-3 between the Samba-3.0.0 release and the current update. 930Network administrators have expressed concerns over the steps that should be 931taken to update Samba-3 versions. 932</para> 933 934<para> 935<indexterm><primary>control files</primary></indexterm> 936The information in <link linkend="sbeug1"/> would not be necessary if every 937person who has ever produced Samba executable (binary) files could agree on 938the preferred location of the &smb.conf; file and other Samba control files. 939Clearly, such agreement is further away than a pipedream. 940</para> 941 942<para> 943<indexterm><primary>vendors</primary></indexterm> 944Vendors and packagers who produce Samba binary installable packages do not, 945as a rule, use the default paths used by the Samba-Team for the location of 946the binary files, the &smb.conf; file, and the Samba control files (tdb's 947as well as files such as <filename>secrets.tdb</filename>). This means that 948the network or UNIX administrator who sets out to build the Samba executable 949files from the Samba tarball must take particular care. Failure to take care 950will result in both the original vendor's version of Samba remaining installed 951and the new version being installed in the default location used 952by the Samba-Team. This can lead to confusion and to much lost time as the 953uninformed administrator deals with apparent failure of the update to take 954effect. 955</para> 956 957<para> 958<indexterm><primary>packages</primary></indexterm> 959The best advice for those lacking in code compilation experience is to use 960only vendor (or Samba-Team) provided binary packages. The Samba packages 961that are provided by the Samba-Team are generally built to use file paths 962that are compatible with the original OS vendor's practices. 963</para> 964 965<para> 966<indexterm><primary>binary package</primary></indexterm> 967<indexterm><primary>binary files</primary></indexterm> 968If you are not sure whether a binary package complies with the OS 969vendor's practices, it is better to ask the package maintainer via 970email than to waste much time dealing with the nuances. 971Alternately, just diagnose the paths specified by the binary files following 972the procedure outlined above. 973</para> 974 975 <sect2> 976 <title>Samba-3 to Samba-3 Updates on the Same Server</title> 977 978 <para> 979 The guidance in this section deals with updates to an existing 980 Samba-3 server installation. 981 </para> 982 983 <sect3> 984 <title>Updating from Samba Versions Earlier than 3.0.5</title> 985 986 <para> 987 With the provision that the binary Samba-3 package has been built 988 with the same path and feature settings as the existing Samba-3 989 package that is being updated, an update of Samba-3 versions 3.0.0 990 through 3.0.4 can be updated to 3.0.5 without loss of functionality 991 and without need to change either the &smb.conf; file or, where 992 used, the LDAP schema. 993 </para> 994 995 </sect3> 996 997 <sect3> 998 <title>Updating from Samba Versions between 3.0.6 and 3.0.10</title> 999 1000 <para> 1001 <indexterm><primary>schema</primary></indexterm> 1002 <indexterm><primary>LDAP</primary><secondary>schema</secondary></indexterm> 1003 When updating versions of Samba-3 prior to 3.0.6 to 3.0.6 through 3.0.10, 1004 it is necessary only to update the LDAP schema (where LDAP is used). 1005 Always use the LDAP schema file that is shipped with the latest Samba-3 1006 update. 1007 </para> 1008 1009 <para> 1010 <indexterm><primary>ldapsam</primary></indexterm> 1011 <indexterm><primary>tdbsam</primary></indexterm> 1012 <indexterm><primary>passdb backend</primary></indexterm> 1013 Samba-3.0.6 introduced the ability to remember the last <emphasis>n</emphasis> number 1014 of passwords a user has used. This information will work only with 1015 the <constant>tdbsam</constant> and <constant>ldapsam</constant> 1016 <parameter>passdb backend</parameter> facilities. 1017 </para> 1018 1019 <para> 1020 After updating the LDAP schema, do not forget to re-index the LDAP database. 1021 </para> 1022 1023 </sect3> 1024 1025 <sect3> 1026 <title>Updating from Samba Versions after 3.0.6 to a Current Release</title> 1027 1028 <para> 1029 <indexterm><primary>winbindd</primary></indexterm> 1030 Samba-3.0.8 introduced changes in how the <parameter>username map</parameter> 1031 behaves. It also included a change in behavior of <command>winbindd</command>. 1032 Please refer to the man page for &smb.conf; before implementing any update 1033 from versions prior to 3.0.8 to a current version. 1034 </para> 1035 1036 <para> 1037 <indexterm><primary>privileges</primary></indexterm> 1038 In Samba-3.0.11 a new privileges interface was implemented. Please 1039 refer to <link linkend="sbehap-ppc"/> for information regarding this new 1040 feature. It is not necessary to implement the privileges interface, but it 1041 is one that has been requested for several years and thus may be of interest 1042 at your site. 1043 </para> 1044 1045 <para> 1046 In Samba-3.0.11 there were some functional changes to the <parameter>ldap user 1047 suffix</parameter> and to the <parameter>ldap machine suffix</parameter> behaviors. 1048 The following information has been extracted from the WHATSNEW.txt file from this 1049 release: 1050<screen> 1051============ 1052LDAP Changes 1053============ 1054 1055If "ldap user suffix" or "ldap machine suffix" are defined in 1056smb.conf, all user-accounts must reside below the user suffix, 1057and all machine and inter-domain trust-accounts must be located 1058below the machine suffix. Previous Samba releases would fall 1059back to searching the 'ldap suffix' in some cases. 1060</screen> 1061 </para> 1062 1063 </sect3> 1064 </sect2> 1065 1066 <sect2> 1067 <title>Migrating Samba-3 to a New Server</title> 1068 1069 <para> 1070 The two most likely candidates for replacement of a server are 1071 domain member servers and domain controllers. Each needs to be 1072 handled slightly differently. 1073 </para> 1074 1075 <sect3> 1076 <title>Replacing a Domain Member Server</title> 1077 1078 <para> 1079 <indexterm><primary>DMS</primary></indexterm> 1080 Replacement of a domain member server should be done 1081 using the same procedure as outlined in <link linkend="unixclients"/>. 1082 </para> 1083 1084 <para> 1085 Usually the new server will be introduced with a temporary name. After 1086 the old server data has been migrated to the new server, it is customary 1087 that the new server be renamed to that of the old server. This will 1088 change its SID and will necessitate rejoining to the domain. 1089 </para> 1090 1091 <para> 1092 <indexterm><primary>smbd</primary></indexterm> 1093 <indexterm><primary>nmbd</primary></indexterm> 1094 <indexterm><primary>winbindd</primary></indexterm> 1095 <indexterm><primary>wins.dat</primary></indexterm> 1096 <indexterm><primary>browse.dat</primary></indexterm> 1097 <indexterm><primary>resolution</primary></indexterm> 1098 Following a change of hostname (NetBIOS name) it is a good idea on all servers 1099 to shut down the Samba <command>smbd</command>, <command>nmbd</command>, and 1100 <command>winbindd</command> services, delete the <filename>wins.dat</filename> 1101 and <filename>browse.dat</filename> files, then restart Samba. This will ensure 1102 that the old name and IP address information is no longer able to interfere with 1103 name to IP address resolution. If this is not done, there can be temporary name 1104 resolution problems. These problems usually clear within 45 minutes of a name 1105 change, but can persist for a longer period of time. 1106 </para> 1107 1108 <para> 1109 <indexterm><primary>DMS</primary></indexterm> 1110 <indexterm><primary>/etc/passwd</primary></indexterm> 1111 <indexterm><primary>/etc/shadow</primary></indexterm> 1112 <indexterm><primary>/etc/group</primary></indexterm> 1113 If the old domain member server had local accounts, it is necessary to create 1114 on the new domain member server the same accounts with the same UID and GID 1115 for each account. Where the <parameter>passdb backend</parameter> database 1116 is stored in the <constant>smbpasswd</constant> or in the 1117 <constant>tdbsam</constant> format, the user and group account information 1118 for UNIX accounts that match the Samba accounts will reside in the system 1119 <filename>/etc/passwd</filename>, <filename>/etc/shadow</filename>, and 1120 <filename>/etc/group</filename> files. In this case, be sure to copy these 1121 account entries to the new target server. 1122 </para> 1123 1124 <para> 1125 <indexterm><primary>nss_ldap</primary></indexterm> 1126 Where the user accounts for both UNIX and Samba are stored in LDAP, the new 1127 target server must be configured to use the <command>nss_ldap</command> tool set. 1128 This will automatically ensure that the appropriate user entities are 1129 available on the new server. 1130 </para> 1131 1132 </sect3> 1133 1134 <sect3> 1135 <title>Replacing a Domain Controller</title> 1136 1137 <para> 1138 <indexterm><primary>domain</primary><secondary>controller</secondary></indexterm> 1139 In the past, people who replaced a Windows NT4 domain controller typically 1140 installed a new server, created printers and file shares on it, then migrate across 1141 all data that was destined to reside on it. The same can of course be done with 1142 Samba. 1143 </para> 1144 1145 <para> 1146 From recent mailing list postings it would seem that some administrators 1147 have the intent to just replace the old Samba server with a new one with 1148 the same name as the old one. In this case, simply follow the same process 1149 as for upgrading a Samba 2.x system and do the following: 1150 </para> 1151 1152 <itemizedlist> 1153 <listitem><para> 1154 Where UNIX (POSIX) user and group accounts are stored in the system 1155 <filename>/etc/passwd</filename>, <filename>/etc/shadow</filename>, and 1156 <filename>/etc/group</filename> files, be sure to add the same accounts 1157 with identical UID and GID values for each user. 1158 </para> 1159 1160 <para> 1161 Where LDAP is used, if the new system is intended to be the LDAP server, 1162 migrate it across by configuring the LDAP server 1163 (<filename>/etc/openldap/slapd.conf</filename>). The directory can 1164 be populated either initially by setting this LDAP server up as a slave or 1165 by dumping the data from the old LDAP server using the <command>slapcat</command> 1166 command and then reloading the same data into the new LDAP server using the 1167 <command>slapadd</command> command. Do not forget to install and configure 1168 the <command>nss_ldap</command> tool and the <filename>/etc/nsswitch.conf</filename> 1169 (as shown in <link linkend="happy"/>). 1170 </para></listitem> 1171 1172 <listitem><para> 1173 Copy the &smb.conf; file from the old server to the new server into the correct 1174 location as indicated previously in this chapter. 1175 </para></listitem> 1176 1177 <listitem><para> 1178 Copy the <filename>secrets.tdb</filename> file, the <filename>smbpasswd</filename> 1179 file (if it is used), the <filename>/etc/samba/passdb.tdb</filename> file (only 1180 used by the <constant>tdbsam</constant> backend), and all the tdb control files 1181 from the old system to the correct location on the new system. 1182 </para></listitem> 1183 1184 <listitem><para> 1185 Before starting the Samba daemons, verify that the hostname of the new server 1186 is identical to that of the old one. Note: The IP address can be different 1187 from that of the old server. 1188 </para></listitem> 1189 1190 <listitem><para> 1191 Copy all files from the old server to the new server, taking precaution to 1192 preserve all file ownership and permissions as well as any POSIX ACLs that 1193 may have been created on the old server. 1194 </para></listitem> 1195 </itemizedlist> 1196 1197 <para> 1198 When replacing a Samba domain controller (PDC or BDC) that uses LDAP, the new server 1199 need simply be configured to use the LDAP directory, and for the rest it should just 1200 work. The domain SID is obtained from the LDAP directory as part of the first connect 1201 to the LDAP directory server. 1202 </para> 1203 1204 <para> 1205 All Samba servers, other than one that uses LDAP, depend on the tdb files, and 1206 particularly on the <filename>secrets.tdb</filename> file. So long as the tdb files are 1207 all in place, the &smb.conf; file is preserved, and either the hostname is identical 1208 or the <parameter>netbios name</parameter> is set to the original server name, Samba 1209 should correctly pick up the original SID and preserve all other settings. It is 1210 sound advice to validate this before turning the system over to users. 1211 </para> 1212 1213 </sect3> 1214 1215 </sect2> 1216 1217 <sect2> 1218 <title>Migration of Samba Accounts to Active Directory</title> 1219 1220 <para> 1221 Yes, it works. The Windows ADMT tool can be used to migrate Samba accounts 1222 to MS Active Directory. There are a few pitfalls to be aware of: 1223 </para> 1224 1225 <procedure> 1226 <title>Migration to Active Directory</title> 1227 1228 <step><para> 1229 Administrator password must be THE SAME on the Samba server, 1230 the 2003 ADS, and the local Administrator account on the workstations. 1231 Perhaps this goes without saying, but there needs to be an account 1232 called <constant>Administrator</constant> in your Samba domain, with 1233 full administrative (root) rights to that domain. 1234 </para></step> 1235 1236 <step><para> 1237 In the Advanced/DNS section of the TCP/IP settings on your Windows 1238 workstations, make sure the <parameter>DNS suffix for this 1239 connection</parameter> field is blank. 1240 </para></step> 1241 1242 <step><para> 1243 Because you are migrating from Samba, user passwords cannot be 1244 migrated. You'll have to reset everyone's passwords. (If you were 1245 migrating from NT4 to ADS, you could migrate passwords as well.) 1246 </para> 1247 1248 <para> 1249 To date this has not been attempted with roaming profile support; 1250 it has been documented as working with local profiles. 1251 </para></step> 1252 1253 <step><para> 1254 Disable the Windows Firewall on all workstations. Otherwise, 1255 workstations won't be migrated to the new domain. 1256 </para></step> 1257 1258 <step><para> 1259 <indexterm><primary>ADMT</primary></indexterm> 1260 When migrating machines, always test first (using ADMT's test mode) 1261 and satisfy all errors before committing the migration. Note that the 1262 test will always fail, because the machine will not have been actually 1263 migrated. You'll need to interpret the errors to know whether the 1264 failure was due to a problem or simply to the fact that it was just 1265 a test. 1266 </para></step> 1267 1268 </procedure> 1269 1270 1271 <para> 1272 <indexterm><primary>ADMT</primary></indexterm> 1273 There are some significant benefits of using the ADMT, besides just 1274 migrating user accounts. ADMT can be found on the Windows 2003 CD. 1275 </para> 1276 1277 <itemizedlist> 1278 <listitem><para> 1279 You can migrate workstations remotely. You can specify that SIDs 1280 be simply added instead of replaced, giving you the option of joining a 1281 workstation back to the old domain if something goes awry. The 1282 workstations will be joined to the new domain. 1283 </para></listitem> 1284 1285 <listitem><para> 1286 Not only are user accounts migrated from the old domain to the new 1287 domain, but ACLs on the workstations are migrated as well. Like SIDs, 1288 ACLs can be added instead of replaced. 1289 </para></listitem> 1290 1291 <listitem><para> 1292 Locally stored user profiles on workstations are migrated as well, 1293 presenting almost no disruption to the user. Saved passwords will be 1294 lost, just as when you administratively reset the password in Windows ADS. 1295 </para></listitem> 1296 1297 <listitem><para> 1298 The ADMT lets you test all operations before actually performing the 1299 migration. Accounts and workstations can be migrated individually or in 1300 batches. User accounts can be safely migrated all at once (since no 1301 changes are made on the original domain). It is recommended to migrate only one 1302 or two workstations as a test before committing them all. 1303 </para></listitem> 1304 1305 </itemizedlist> 1306 1307 </sect2> 1308 1309</sect1> 1310 1311</chapter> 1312