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="samba-bdc"> 4 5<chapterinfo> 6 &author.jht; 7 &author.vl; 8 <author>&person.gd;<contrib>LDAP updates</contrib></author> 9</chapterinfo> 10 11<title>Backup Domain Control</title> 12 13<para> 14Before you continue reading this section, please make sure that you are comfortable 15with configuring a Samba domain controller as described in <link linkend="samba-pdc">Domain Control</link>. 16</para> 17 18<sect1> 19<title>Features and Benefits</title> 20 21<para> 22This is one of the most difficult chapters to summarize. It does not matter what we say here, for someone will 23still draw conclusions and/or approach the Samba Team with expectations that are either not yet capable of 24being delivered or that can be achieved far more effectively using a totally different approach. In the event 25that you should have a persistent concern that is not addressed in this book, please email <ulink 26url="mailto:jht@samba.org">John H. Terpstra</ulink> clearly setting out your requirements and/or question, and 27we will do our best to provide a solution. 28</para> 29 30<para> 31<indexterm><primary>SAM backend</primary><secondary>LDAP</secondary></indexterm> 32<indexterm><primary>PDC</primary></indexterm> 33<indexterm><primary>BDC</primary></indexterm> 34<indexterm><primary>LDAP</primary><secondary>slave</secondary></indexterm> 35<indexterm><primary>scalability</primary></indexterm> 36Samba-3 can act as a Backup Domain Controller (BDC) to another Samba Primary Domain Controller (PDC). A 37Samba-3 PDC can operate with an LDAP account backend. The LDAP backend can be either a common master LDAP 38server or a slave server. The use of a slave LDAP server has the benefit that when the master is down, clients 39may still be able to log onto the network. This effectively gives Samba a high degree of scalability and is 40an effective solution for large organizations. If you use an LDAP slave server for a PDC, you will need to 41ensure the master's continued availability &smbmdash; if the slave finds its master down at the wrong time, 42you will have stability and operational problems. 43</para> 44 45<para> 46<indexterm><primary>two-way</primary><secondary>propagation</secondary></indexterm> 47<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm> 48<indexterm><primary>non-LDAP</primary><secondary>backend</secondary></indexterm> 49<indexterm><primary>propagate</primary></indexterm> 50While it is possible to run a Samba-3 BDC with a non-LDAP backend, that backend must allow some form of 51"two-way" propagation of changes from the BDC to the master. At this time only LDAP delivers the capability 52to propagate identity database changes from the BDC to the PDC. The BDC can use a slave LDAP server, while it 53is preferable for the PDC to use as its primary an LDAP master server. 54</para> 55 56<para> 57<indexterm><primary>non-LDAP</primary><secondary>backend</secondary></indexterm> 58<indexterm><primary>SAM backend</primary><secondary>non-LDAP</secondary></indexterm> 59<indexterm><primary>domain</primary><secondary>member</secondary><tertiary>server</tertiary></indexterm> 60<indexterm><primary>BDC</primary></indexterm> 61<indexterm><primary>PDC</primary></indexterm> 62<indexterm><primary>trust account password</primary></indexterm> 63<indexterm><primary>domain trust</primary></indexterm> 64The use of a non-LDAP backend SAM database is particularly problematic because domain member 65servers and workstations periodically change the Machine Trust Account password. The new 66password is then stored only locally. This means that in the absence of a centrally stored 67accounts database (such as that provided with an LDAP-based solution) if Samba-3 is running 68as a BDC, the BDC instance of the domain member trust account password will not reach the 69PDC (master) copy of the SAM. If the PDC SAM is then replicated to BDCs, this results in 70overwriting the SAM that contains the updated (changed) trust account password with resulting 71breakage of the domain trust. 72</para> 73 74<para> 75<indexterm><primary>net</primary><secondary>rpc</secondary></indexterm> 76<indexterm><primary>SAM backend</primary><secondary>ldapsam</secondary></indexterm> 77<indexterm><primary>SAM backend</primary><secondary>tdbsam</secondary></indexterm> 78<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm> 79Considering the number of comments and questions raised concerning how to configure a BDC, 80let's consider each possible option and look at the pros and cons for each possible solution. 81<link linkend="pdc-bdc-table">The Domain Backend Account Distribution Options table below</link> lists 82possible design configurations for a PDC/BDC infrastructure. 83</para> 84 85<table frame="all" id="pdc-bdc-table"><title>Domain Backend Account Distribution Options</title> 86<tgroup cols="3"> 87 <colspec align="center" colwidth="1*"/> 88 <colspec align="center" colwidth="1*"/> 89 <colspec align="left" colwidth="3*"/> 90 91 <thead> 92 <row><entry>PDC Backend</entry><entry>BDC Backend</entry><entry>Notes/Discussion</entry></row> 93 </thead> 94 <tbody> 95 <row> 96 <entry><para>Master LDAP Server</para></entry> 97 <entry><para>Slave LDAP Server</para></entry> 98 <entry><para>The optimal solution that provides high integrity. The SAM will be 99 replicated to a common master LDAP server.</para></entry> 100 </row> 101 <row> 102 <entry><para>Single Central LDAP Server</para></entry> 103 <entry><para>Single Central LDAP Server</para></entry> 104 <entry><para> 105 A workable solution without failover ability. This is a usable solution, but not optimal. 106 </para></entry> 107 </row> 108 <row> 109 <entry><para>tdbsam</para></entry> 110 <entry><para>tdbsam + <command>net rpc vampire</command></para></entry> 111 <entry><para> 112 Does not work with Samba-3.0; Samba does not implement the 113 server-side protocols required. 114 </para></entry> 115 </row> 116 <row> 117 <entry><para>tdbsam</para></entry> 118 <entry><para>tdbsam + <command>rsync</command></para></entry> 119 <entry><para> 120 Do not use this configuration. 121 Does not work because the TDB files are live and data may not 122 have been flushed to disk. Furthermore, this will cause 123 domain trust breakdown. 124 </para></entry> 125 </row> 126 <row> 127 <entry><para>smbpasswd file</para></entry> 128 <entry><para>smbpasswd file</para></entry> 129 <entry><para> 130 Do not use this configuration. 131 Not an elegant solution due to the delays in synchronization 132 and also suffers 133 from the issue of domain trust breakdown. 134 </para></entry> 135 </row> 136 </tbody> 137</tgroup> 138</table> 139 140</sect1> 141 142<sect1> 143<title>Essential Background Information</title> 144 145<para> 146<indexterm><primary>domain controller</primary></indexterm> 147<indexterm><primary>logon requests</primary></indexterm> 148<indexterm><primary>LanMan</primary></indexterm> 149<indexterm><primary>Netlogon</primary></indexterm> 150A domain controller is a machine that is able to answer logon requests from network 151workstations. Microsoft LanManager and IBM LanServer were two early products that 152provided this capability. The technology has become known as the LanMan Netlogon service. 153</para> 154 155<para> 156<indexterm><primary>network</primary><secondary>logon</secondary><tertiary>service</tertiary></indexterm> 157<indexterm><primary>Windows NT3.10</primary></indexterm> 158When MS Windows NT3.10 was first released, it supported a new style of Domain Control 159and with it a new form of the network logon service that has extended functionality. 160This service became known as the NT NetLogon Service. The nature of this service has 161changed with the evolution of MS Windows NT and today provides a complex array of 162services that are implemented over an intricate spectrum of technologies. 163</para> 164 165<sect2> 166<title>MS Windows NT4-style Domain Control</title> 167 168<para> 169<indexterm><primary>domain controller</primary></indexterm> 170<indexterm><primary>authentication server</primary></indexterm> 171<indexterm><primary>username</primary></indexterm> 172<indexterm><primary>password</primary></indexterm> 173<indexterm><primary>SAM</primary></indexterm> 174<indexterm><primary>Security Account Manager</primary><see>SAM</see></indexterm> 175<indexterm><primary>domain control database</primary><see>SAM</see></indexterm> 176Whenever a user logs into a Windows NT4/200x/XP Professional workstation, 177the workstation connects to a domain controller (authentication server) to validate that 178the username and password the user entered are valid. If the information entered 179does not match account information that has been stored in the domain 180control database (the SAM, or Security Account Manager database), a set of error 181codes is returned to the workstation that has made the authentication request. 182</para> 183 184<para> 185<indexterm><primary>account information</primary></indexterm> 186<indexterm><primary>machine accounts database</primary></indexterm> 187<indexterm><primary>profile</primary></indexterm> 188<indexterm><primary>network access profile</primary></indexterm> 189<indexterm><primary>desktop profile</primary></indexterm> 190When the username/password pair has been validated, the domain controller 191(authentication server) will respond with full enumeration of the account information 192that has been stored regarding that user in the user and machine accounts database 193for that domain. This information contains a complete network access profile for 194the user but excludes any information that is particular to the user's desktop profile, 195or for that matter it excludes all desktop profiles for groups that the user may 196belong to. It does include password time limits, password uniqueness controls, 197network access time limits, account validity information, machine names from which the 198user may access the network, and much more. All this information was stored in the SAM 199in all versions of MS Windows NT (3.10, 3.50, 3.51, 4.0). 200</para> 201 202<para> 203<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm> 204<indexterm><primary>%SystemRoot%\System32\config</primary></indexterm> 205<indexterm><primary>C:\WinNT\System32\config</primary></indexterm> 206<indexterm><primary>BDC</primary></indexterm> 207<indexterm><primary>SAM</primary></indexterm> 208The account information (user and machine) on domain controllers is stored in two files, 209one containing the security information and the other the SAM. These are stored in files 210by the same name in the <filename>%SystemRoot%\System32\config</filename> directory. 211This normally translates to the path <filename>C:\WinNT\System32\config</filename>. These 212are the files that are involved in replication of the SAM database where BDCs are present 213on the network. 214</para> 215 216<para> 217There are two situations in which it is desirable to install BDCs: 218</para> 219 220<itemizedlist> 221 <listitem><para> 222 <indexterm><primary>PDC</primary></indexterm> 223 <indexterm><primary>BDC</primary></indexterm> 224 On the local network that the PDC is on, if there are many 225 workstations and/or where the PDC is generally very busy. In this case the BDCs 226 will pick up network logon requests and help to add robustness to network services. 227 </para></listitem> 228 229 <listitem><para> 230 <indexterm><primary>network</primary><secondary>wide-area</secondary></indexterm> 231 At each remote site, to reduce wide-area network traffic and to add stability to 232 remote network operations. The design of the network, and the strategic placement of 233 BDCs, together with an implementation that localizes as much of network to client 234 interchange as possible, will help to minimize wide-area network bandwidth needs 235 (and thus costs). 236 </para></listitem> 237</itemizedlist> 238 239<para> 240<indexterm><primary>PDC</primary></indexterm> 241<indexterm><primary>SAM</primary></indexterm> 242<indexterm><primary>user account database</primary></indexterm> 243<indexterm><primary>BDC</primary></indexterm> 244<indexterm><primary>trigger</primary></indexterm> 245The interoperation of a PDC and its BDCs in a true Windows NT4 environment is worth 246mentioning here. The PDC contains the master copy of the SAM. In the event that an 247administrator makes a change to the user account database while physically present 248on the local network that has the PDC, the change will likely be made directly to 249the PDC instance of the master copy of the SAM. In the event that this update may 250be performed in a branch office, the change will likely be stored in a delta file 251on the local BDC. The BDC will then send a trigger to the PDC to commence the process 252of SAM synchronization. The PDC will then request the delta from the BDC and apply 253it to the master SAM. The PDC will then contact all the BDCs in the domain and 254trigger them to obtain the update and then apply that to their own copy of the SAM. 255</para> 256 257<para> 258<indexterm><primary>SAM</primary><secondary>replication</secondary></indexterm> 259<indexterm><primary>SAM</primary><secondary>delta file</secondary></indexterm> 260<indexterm><primary>PDC</primary></indexterm> 261<indexterm><primary>BDC</primary></indexterm> 262Samba-3 cannot participate in true SAM replication and is therefore not able to 263employ precisely the same protocols used by MS Windows NT4. A Samba-3 BDC will 264not create SAM update delta files. It will not interoperate with a PDC (NT4 or Samba) 265to synchronize the SAM from delta files that are held by BDCs. 266</para> 267 268<para> 269<indexterm><primary>PDC</primary></indexterm> 270<indexterm><primary>BDC</primary></indexterm> 271Samba-3 cannot function as a BDC to an MS Windows NT4 PDC, and Samba-3 cannot 272function correctly as a PDC to an MS Windows NT4 BDC. Both Samba-3 and MS Windows 273NT4 can function as a BDC to its own type of PDC. 274</para> 275 276<para> 277<indexterm><primary>SAM</primary></indexterm> 278<indexterm><primary>BDC</primary></indexterm> 279<indexterm><primary>domain security</primary></indexterm> 280The BDC is said to hold a <emphasis>read-only</emphasis> of the SAM from which 281it is able to process network logon requests and authenticate users. The BDC can 282continue to provide this service, particularly while, for example, the wide-area 283network link to the PDC is down. A BDC plays a very important role in both the 284maintenance of domain security as well as in network integrity. 285</para> 286 287<para> 288<indexterm><primary>PDC</primary></indexterm> 289<indexterm><primary>promoted</primary></indexterm> 290<indexterm><primary>demoted</primary></indexterm> 291<indexterm><primary>reconfiguration</primary></indexterm> 292In the event that the NT4 PDC should need to be taken out of service, or if it dies, one of the NT4 BDCs can 293be promoted to a PDC. If this happens while the original NT4 PDC is online, it is automatically demoted to an 294NT4 BDC. This is an important aspect of domain controller management. The tool that is used to effect a 295promotion or a demotion is the Server Manager for Domains. It should be noted that Samba-3 BDCs cannot be 296promoted in this manner because reconfiguration of Samba requires changes to the &smb.conf; file. It is easy 297enough to manuall change the &smb.conf; file and then restart relevant Samba network services. 298</para> 299 300<sect3> 301<title>Example PDC Configuration</title> 302 303<para> 304<indexterm><primary>domain logon</primary></indexterm> 305<indexterm><primary>PDC</primary></indexterm> 306Beginning with Version 2.2, Samba officially supports domain logons for all current Windows clients, including 307Windows NT4, 2003, and XP Professional. For Samba to be enabled as a PDC, some parameters in the 308<smbconfsection name="[global]"/> section of the &smb.conf; have to be set. Refer to <link 309linkend="minimalPDC">the Minimal smb.conf for a PDC in Use with a BDC &smbmdash; LDAP Server on PDC 310section</link> for an example of the minimum required settings. 311</para> 312 313<example id="minimalPDC"> 314<title>Minimal smb.conf for a PDC in Use with a BDC &smbmdash; LDAP Server on PDC</title> 315<smbconfblock> 316<smbconfoption name="workgroup">&example.workgroup;</smbconfoption> 317<smbconfoption name="passdb backend">ldapsam://localhost:389</smbconfoption> 318<smbconfoption name="domain master">yes</smbconfoption> 319<smbconfoption name="domain logons">yes</smbconfoption> 320<smbconfoption name="ldap suffix">dc=quenya,dc=org</smbconfoption> 321<smbconfoption name="ldap user suffix">ou=Users</smbconfoption> 322<smbconfoption name="ldap group suffix">ou=Groups</smbconfoption> 323<smbconfoption name="ldap machine suffix">ou=Computers</smbconfoption> 324<smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption> 325<smbconfoption name="ldap admin dn">cn=sambadmin,dc=quenya,dc=org</smbconfoption> 326</smbconfblock> 327</example> 328 329<para> 330<indexterm><primary>profile path</primary></indexterm> 331<indexterm><primary>home drive</primary></indexterm> 332Several other things like a <smbconfsection name="[homes]"/> and a <smbconfsection name="[netlogon]"/> share 333also need to be set along with settings for the profile path, the user's home drive, and so on. This is not 334covered in this chapter; for more information please refer to <link linkend="samba-pdc">Domain Control</link>. 335Refer to <link linkend="samba-pdc">the Domain Control chapter</link> for specific recommendations for PDC 336configuration. Alternately, fully documented working example network configurations using OpenLDAP and Samba 337as available in the <ulink url="http://www.samba.org/samba/docs/Samba3-ByExample">book</ulink> <quote>Samba-3 338by Example</quote> that may be obtained from local and on-line book stores. 339</para> 340 341</sect3> 342</sect2> 343 344<sect2> 345<title>LDAP Configuration Notes</title> 346 347<para> 348<indexterm><primary>LDAP</primary><secondary>master</secondary></indexterm> 349<indexterm><primary>LDAP</primary><secondary>slave</secondary></indexterm> 350<indexterm><primary>BDC</primary></indexterm> 351When configuring a master and a slave LDAP server, it is advisable to use the master LDAP server 352for the PDC and slave LDAP servers for the BDCs. It is not essential to use slave LDAP servers; however, 353many administrators will want to do so in order to provide redundant services. Of course, one or more BDCs 354may use any slave LDAP server. Then again, it is entirely possible to use a single LDAP server for the 355entire network. 356</para> 357 358<para> 359<indexterm><primary>LDAP</primary><secondary>master</secondary></indexterm> 360<indexterm><primary>LDAP</primary><secondary>server</secondary></indexterm> 361<indexterm><primary>CN</primary></indexterm> 362<indexterm><primary>DN</primary></indexterm> 363<indexterm><primary>RFC2830</primary></indexterm> 364When configuring a master LDAP server that will have slave LDAP servers, do not forget to configure this in 365the <filename>/etc/openldap/slapd.conf</filename> file. It must be noted that the DN of a server certificate 366must use the CN attribute to name the server, and the CN must carry the servers' fully qualified domain name. 367Additional alias names and wildcards may be present in the subjectAltName certificate extension. More details 368on server certificate names are in RFC2830. 369</para> 370 371<para> 372<indexterm><primary>LDAP</primary></indexterm> 373<indexterm><primary>BDC</primary></indexterm> 374<indexterm><primary>OpenLDAP</primary></indexterm> 375<indexterm><primary>transport layer security</primary><see>TLS</see></indexterm> 376<indexterm><primary>/etc/ssl/certs/slapd.pem</primary></indexterm> 377<indexterm><primary>slapd.pem</primary></indexterm> 378<indexterm><primary>Red Hat Linux</primary></indexterm> 379It does not really fit within the scope of this document, but a working LDAP installation is basic to 380LDAP-enabled Samba operation. When using an OpenLDAP server with Transport Layer Security (TLS), the machine 381name in <filename>/etc/ssl/certs/slapd.pem</filename> must be the same as in 382<filename>/etc/openldap/sldap.conf</filename>. The Red Hat Linux startup script creates the 383<filename>slapd.pem</filename> file with hostname <quote>localhost.localdomain.</quote> It is impossible to 384access this LDAP server from a slave LDAP server (i.e., a Samba BDC) unless the certificate is re-created with 385a correct hostname. 386</para> 387 388<para> 389<indexterm><primary>PDC</primary></indexterm> 390<indexterm><primary>OpenLDAP</primary></indexterm> 391<indexterm><primary>machine account</primary></indexterm> 392<indexterm><primary>credentials</primary></indexterm> 393<indexterm><primary>replication</primary></indexterm> 394<indexterm><primary>duplicate</primary></indexterm> 395Do not install a Samba PDC so that is uses an LDAP slave server. Joining client machines to the domain 396will fail in this configuration because the change to the machine account in the LDAP tree must take place on 397the master LDAP server. This is not replicated rapidly enough to the slave server that the PDC queries. It 398therefore gives an error message on the client machine about not being able to set up account credentials. The 399machine account is created on the LDAP server, but the password fields will be empty. Unfortunately, some 400sites are unable to avoid such configurations, and these sites should review the <smbconfoption name="ldap 401replication sleep"/> parameter, intended to slow down Samba sufficiently for the replication to catch up. 402This is a kludge, and one that the administrator must manually duplicate in any scripts (such as the 403<smbconfoption name="add machine script"/>) that they use. 404</para> 405 406<para> 407Possible PDC/BDC plus LDAP configurations include: 408</para> 409 410<itemizedlist> 411 <listitem><para> 412 PDC+BDC -> One Central LDAP Server. 413 </para></listitem> 414 <listitem><para> 415 PDC -> LDAP master server, BDC -> LDAP slave server. 416 </para></listitem> 417 <listitem><para> 418 PDC -> LDAP master, with secondary slave LDAP server. 419 </para><para> 420 BDC -> LDAP master, with secondary slave LDAP server. 421 </para></listitem> 422 <listitem><para> 423 PDC -> LDAP master, with secondary slave LDAP server. 424 </para><para> 425 BDC -> LDAP slave server, with secondary master LDAP server. 426 </para></listitem> 427</itemizedlist> 428 429<para> 430In order to have a fallback configuration (secondary) LDAP server, you would specify 431the secondary LDAP server in the &smb.conf; file as shown in <link linkend="mulitldapcfg">the Multiple LDAP 432Servers in &smb.conf; example</link>. 433</para> 434 435<example id="mulitldapcfg"> 436<title>Multiple LDAP Servers in &smb.conf;</title> 437<smbconfblock> 438<smbconfoption name="passdb backend">ldapsam:"ldap://master.quenya.org ldap://slave.quenya.org"</smbconfoption> 439</smbconfblock> 440</example> 441 442</sect2> 443 444<sect2> 445<title>Active Directory Domain Control</title> 446 447<para> 448<indexterm><primary>MS Windows 2000</primary></indexterm> 449<indexterm><primary>Active Directory</primary></indexterm> 450<indexterm><primary>directory</primary></indexterm> 451<indexterm><primary>replicated</primary></indexterm> 452<indexterm><primary>BDC</primary></indexterm> 453<indexterm><primary>domain controller</primary></indexterm> 454As of the release of MS Windows 2000 and Active Directory, this information is now stored 455in a directory that can be replicated and for which partial or full administrative control 456can be delegated. Samba-3 is not able to be a domain controller within an Active Directory 457tree, and it cannot be an Active Directory server. This means that Samba-3 also cannot 458act as a BDC to an Active Directory domain controller. 459</para> 460 461</sect2> 462 463<sect2> 464<title>What Qualifies a Domain Controller on the Network?</title> 465 466<para> 467<indexterm><primary>DMB</primary></indexterm> 468<indexterm><primary>PDC</primary></indexterm> 469<indexterm><primary>WINS</primary></indexterm> 470<indexterm><primary>NetBIOS</primary></indexterm> 471Every machine that is a domain controller for the domain MIDEARTH has to register the NetBIOS 472group name MIDEARTH<1C> with the WINS server and/or by broadcast on the local network. 473The PDC also registers the unique NetBIOS name MIDEARTH<1B> with the WINS server. 474The name type <1B> name is normally reserved for the Domain Master Browser (DMB), a role 475that has nothing to do with anything related to authentication, but the Microsoft domain 476implementation requires the DMB to be on the same machine as the PDC. 477</para> 478 479<para> 480<indexterm><primary>broadcast</primary></indexterm> 481<indexterm><primary>name registration</primary></indexterm> 482<indexterm><primary>SMB/CIFS</primary></indexterm> 483Where a WINS server is not used, broadcast name registrations alone must suffice. Refer to 484<link linkend="NetworkBrowsing">Network Browsing</link>,<link linkend="netdiscuss">Discussion</link> 485for more information regarding TCP/IP network protocols and how SMB/CIFS names are handled. 486</para> 487 488</sect2> 489 490<sect2> 491<title>How Does a Workstation find its Domain Controller?</title> 492 493<para> 494<indexterm><primary>locate domain controller</primary></indexterm> 495<indexterm><primary>NetBIOS</primary></indexterm> 496There are two different mechanisms to locate a domain controller: one method is used when 497NetBIOS over TCP/IP is enabled and the other when it has been disabled in the TCP/IP 498network configuration. 499</para> 500 501<para> 502<indexterm><primary>DNS</primary></indexterm> 503<indexterm><primary>broadcast messaging</primary></indexterm> 504Where NetBIOS over TCP/IP is disabled, all name resolution involves the use of DNS, broadcast 505messaging over UDP, as well as Active Directory communication technologies. In this type of 506environment all machines require appropriate DNS entries. More information may be found in 507<link linkend="adsdnstech">DNS and Active Directory</link>. 508</para> 509 510<sect3> 511<title>NetBIOS Over TCP/IP Enabled</title> 512<para> 513<indexterm><primary>Windows NT4/200x/XP</primary></indexterm> 514<indexterm><primary>domain controller</primary></indexterm> 515<indexterm><primary>logon requests</primary></indexterm> 516<indexterm><primary>credentials validation</primary></indexterm> 517An MS Windows NT4/200x/XP Professional workstation in the domain MIDEARTH that wants a 518local user to be authenticated has to find the domain controller for MIDEARTH. It does this 519by doing a NetBIOS name query for the group name MIDEARTH<1C>. It assumes that each 520of the machines it gets back from the queries is a domain controller and can answer logon 521requests. To not open security holes, both the workstation and the selected domain controller 522authenticate each other. After that the workstation sends the user's credentials (name and 523password) to the local domain controller for validation. 524</para> 525 526</sect3> 527 528<sect3> 529<title>NetBIOS Over TCP/IP Disabled</title> 530 531<para> 532<indexterm><primary>realm</primary></indexterm> 533<indexterm><primary>logon authentication</primary></indexterm> 534<indexterm><primary>DNS</primary></indexterm> 535<indexterm><primary>_ldap._tcp.pdc._msdcs.quenya.org</primary></indexterm> 536An MS Windows NT4/200x/XP Professional workstation in the realm <constant>quenya.org</constant> 537that has a need to affect user logon authentication will locate the domain controller by 538re-querying DNS servers for the <constant>_ldap._tcp.pdc._msdcs.quenya.org</constant> record. 539More information regarding this subject may be found in <link linkend="adsdnstech">DNS and Active Directory</link>. 540</para> 541 542</sect3> 543</sect2> 544</sect1> 545 546<sect1> 547<title>Backup Domain Controller Configuration</title> 548 549<para> 550<indexterm><primary>BDC</primary></indexterm> 551The creation of a BDC requires some steps to prepare the Samba server before 552&smbd; is executed for the first time. These steps are as follows: 553</para> 554 555<itemizedlist> 556 <listitem><para> 557 <indexterm><primary>SID</primary></indexterm> 558 <indexterm><primary>PDC</primary></indexterm> 559 <indexterm><primary>BDC</primary></indexterm> 560 <indexterm><primary>private/secrets.tdb</primary></indexterm> 561 <indexterm><primary>private/MACHINE.SID</primary></indexterm> 562 <indexterm><primary>domain SID</primary></indexterm> 563 The domain SID has to be the same on the PDC and the BDC. In Samba versions pre-2.2.5, the domain SID was 564 stored in the file <filename>private/MACHINE.SID</filename>. For all versions of Samba released since 2.2.5 565 the domain SID is stored in the file <filename>private/secrets.tdb</filename>. This file is unique to each 566 server and cannot be copied from a PDC to a BDC; the BDC will generate a new SID at startup. It will overwrite 567 the PDC domain SID with the newly created BDC SID. There is a procedure that will allow the BDC to acquire the 568 domain SID. This is described here. 569 </para> 570 571 <para> 572 <indexterm><primary>domain SID</primary></indexterm> 573 <indexterm><primary>PDC</primary></indexterm> 574 <indexterm><primary>BDC</primary></indexterm> 575 <indexterm><primary>secrets.tdb</primary></indexterm> 576 <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>getsid</tertiary></indexterm> 577 To retrieve the domain SID from the PDC or an existing BDC and store it in the 578 <filename>secrets.tdb</filename>, execute: 579 </para> 580<screen> 581&rootprompt;<userinput>net rpc getsid</userinput> 582</screen> 583 </listitem> 584 585 <listitem><para> 586 <indexterm><primary>secrets.tdb</primary></indexterm> 587 <indexterm><primary>smbpasswd</primary></indexterm> 588 <indexterm><primary>LDAP administration password</primary></indexterm> 589 Specification of the <smbconfoption name="ldap admin dn"/> is obligatory. 590 This also requires the LDAP administration password to be set in the <filename>secrets.tdb</filename> 591 using the <command>smbpasswd -w <replaceable>mysecret</replaceable></command>. 592 </para></listitem> 593 594 <listitem><para> 595 The <smbconfoption name="ldap suffix"/> parameter and the <smbconfoption name="ldap idmap suffix"/> 596 parameter must be specified in the &smb.conf; file. 597 </para></listitem> 598 599 <listitem><para> 600 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm> 601 <indexterm><primary>user database</primary></indexterm> 602 <indexterm><primary>synchronized</primary></indexterm> 603 <indexterm><primary>NIS</primary></indexterm> 604 The UNIX user database has to be synchronized from the PDC to the 605 BDC. This means that both the <filename>/etc/passwd</filename> and 606 <filename>/etc/group</filename> have to be replicated from the PDC 607 to the BDC. This can be done manually whenever changes are made. 608 Alternately, the PDC is set up as an NIS master server and the BDC as an NIS slave 609 server. To set up the BDC as a mere NIS client would not be enough, 610 as the BDC would not be able to access its user database in case of 611 a PDC failure. NIS is by no means the only method to synchronize 612 passwords. An LDAP solution would also work. 613 </para> 614 </listitem> 615 616 <listitem><para> 617 <indexterm><primary>password database</primary></indexterm> 618 <indexterm><primary>replicated</primary></indexterm> 619 <indexterm><primary>PDC</primary></indexterm> 620 <indexterm><primary>BDC</primary></indexterm> 621 <indexterm><primary>smbpasswd</primary></indexterm> 622 <indexterm><primary>rsync</primary></indexterm> 623 <indexterm><primary>ssh</primary></indexterm> 624 <indexterm><primary>LDAP</primary></indexterm> 625 The Samba password database must be replicated from the PDC to the BDC. 626 Although it is possible to synchronize the <filename>smbpasswd</filename> 627 file with <command>rsync</command> and <command>ssh</command>, this method 628 is broken and flawed, and is therefore not recommended. A better solution 629 is to set up slave LDAP servers for each BDC and a master LDAP server for the PDC. 630 The use of rsync is inherently flawed by the fact that the data will be replicated 631 at timed intervals. There is no guarantee that the BDC will be operating at all 632 times with correct and current machine and user account information. This means that 633 this method runs the risk of users being inconvenienced by discontinuity of access 634 to network services due to inconsistent security data. It must be born in mind that 635 Windows workstations update (change) the machine trust account password at regular 636 intervals &smbmdash; administrators are not normally aware that this is happening 637 or when it takes place. 638 </para> 639 640 <para> 641 <indexterm><primary>POSIX</primary></indexterm> 642 <indexterm><primary>LDAP</primary></indexterm> 643 <indexterm><primary>SambaSAMAccount</primary></indexterm> 644 <indexterm><primary>synchronize</primary></indexterm> 645 The use of LDAP for both the POSIX (UNIX user and group) accounts and for the 646 SambaSAMAccount data automatically ensures that all account change information 647 will be written to the shared directory. This eliminates the need for any special 648 action to synchronize account information because LDAP will meet that requirement. 649 </para></listitem> 650 651 <listitem><para> 652 <indexterm><primary>netlogon share</primary></indexterm> 653 <indexterm><primary>replicate</primary></indexterm> 654 <indexterm><primary>PDC</primary></indexterm> 655 <indexterm><primary>BDC</primary></indexterm> 656 <indexterm><primary>cron</primary></indexterm> 657 <indexterm><primary>rsync</primary></indexterm> 658 The netlogon share has to be replicated from the PDC to the BDC. This can be done manually whenever login 659 scripts are changed, or it can be done automatically using a <command>cron</command> job that will replicate 660 the directory structure in this share using a tool like <command>rsync</command>. The use of 661 <command>rsync</command> for replication of the netlogon data is not critical to network security and is one 662 that can be manually managed given that the administrator will make all changes to the netlogon share as part 663 of a conscious move. 664 </para></listitem> 665 666</itemizedlist> 667 668<sect2> 669<title>Example Configuration</title> 670 671<para> 672Finally, the BDC has to be capable of being found by the workstations. This can be done by configuring the 673Samba &smb.conf; file <smbconfsection name="[global]"/> section as shown in <link linkend="minim-bdc">Minimal 674Setup for Being a BDC</link>. 675</para> 676 677<example id="minim-bdc"> 678<title>Minimal Setup for Being a BDC</title> 679<smbconfblock> 680<smbconfoption name="workgroup">&example.workgroup;</smbconfoption> 681<smbconfoption name="passdb backend">ldapsam:ldap://slave-ldap.quenya.org</smbconfoption> 682<smbconfoption name="domain master">no</smbconfoption> 683<smbconfoption name="domain logons">yes</smbconfoption> 684<smbconfoption name="ldap suffix">dc=abmas,dc=biz</smbconfoption> 685<smbconfoption name="ldap user suffix">ou=Users</smbconfoption> 686<smbconfoption name="ldap group suffix">ou=Groups</smbconfoption> 687<smbconfoption name="ldap machine suffix">ou=Computers</smbconfoption> 688<smbconfoption name="ldap idmap suffix">ou=Idmap</smbconfoption> 689<smbconfoption name="ldap admin dn">cn=sambadmin,dc=quenya,dc=org</smbconfoption> 690<smbconfoption name="idmap backend">ldap:ldap://master-ldap.quenya.org</smbconfoption> 691<smbconfoption name="idmap uid">10000-20000</smbconfoption> 692<smbconfoption name="idmap gid">10000-20000</smbconfoption> 693</smbconfblock> 694</example> 695 696<para> 697Fully documented working example network configurations using OpenLDAP and Samba 698as available in the <ulink url="http://www.samba.org/samba/docs/Samba3-ByExample">book</ulink> <quote>Samba-3 699by Example</quote> that may be obtained from local and on-line book stores. 700</para> 701 702<para> 703<indexterm><primary>BDC</primary></indexterm> 704<indexterm><primary>NetBIOS</primary></indexterm> 705<indexterm><primary>group</primary></indexterm> 706<indexterm><primary>PDC</primary></indexterm> 707This configuration causes the BDC to register only the name MIDEARTH<1C> with the WINS server. This is 708not a problem, as the name MIDEARTH<1C> is a NetBIOS group name that is meant to be registered by more 709than one machine. The parameter <smbconfoption name="domain master">no</smbconfoption> forces the BDC not to 710register MIDEARTH<1B>, which is a unique NetBIOS name that is reserved for the PDC. 711</para> 712 713<para> 714<indexterm><primary>idmap backend</primary></indexterm> 715<indexterm><primary>winbindd</primary></indexterm> 716<indexterm><primary>redirect</primary></indexterm> 717<indexterm><primary>winbindd</primary></indexterm> 718<indexterm><primary>LDAP database</primary></indexterm> 719<indexterm><primary>UID</primary></indexterm> 720<indexterm><primary>GID</primary></indexterm> 721<indexterm><primary>SID</primary></indexterm> 722<indexterm><primary>nss_ldap</primary></indexterm> 723The <parameter>idmap backend</parameter> will redirect the <command>winbindd</command> utility to use the LDAP 724database to store all mappings for Windows SIDs to UIDs and GIDs for UNIX accounts in a repository that is 725shared. The BDC will however depend on local resolution of UIDs and GIDs via NSS and the 726<command>nss_ldap</command> utility. 727</para> 728 729<note><para> 730<indexterm><primary>Server Type</primary><secondary>Domain Member</secondary></indexterm> 731<indexterm><primary>ID mapping</primary></indexterm> 732<indexterm><primary>domain member server</primary></indexterm> 733<indexterm><primary>idmap backend</primary></indexterm> 734Samba-3 has introduced a new ID mapping facility. One of the features of this facility is that it 735allows greater flexibility in how user and group IDs are handled in respect to NT domain user and group 736SIDs. One of the new facilities provides for explicitly ensuring that UNIX/Linux UID and GID values 737will be consistent on the PDC, all BDCs, and all domain member servers. The parameter that controls this 738is called <parameter>idmap backend</parameter>. Please refer to the man page for &smb.conf; for more information 739regarding its behavior. 740</para></note> 741 742<para> 743<indexterm><primary>BDC</primary></indexterm> 744<indexterm><primary>winbindd</primary></indexterm> 745<indexterm><primary>domain member servers</primary></indexterm> 746The use of the <smbconfoption name="idmap backend">ldap:ldap://master.quenya.org</smbconfoption> 747option on a BDC only makes sense where ldapsam is used on a PDC. The purpose of an LDAP-based idmap backend is 748also to allow a domain member (without its own passdb backend) to use winbindd to resolve Windows network users 749and groups to common UID/GIDs. In other words, this option is generally intended for use on BDCs and on domain 750member servers. 751</para> 752 753</sect2> 754</sect1> 755 756<sect1> 757<title>Common Errors</title> 758 759<para> 760<indexterm><primary>domain control</primary></indexterm> 761Domain control was a new area for Samba, but there are now many examples that we may refer to. 762Updated information will be published as they become available and may be found in later Samba releases or 763from the Samba Web <ulink url="http://samba.org">site</ulink>; refer in particular to the 764<filename>WHATSNEW.txt</filename> in the Samba release tarball. The book, <quote>Samba-3 by Example</quote> 765documents well tested and proven configuration examples. You can obtain a copy of this 766<ulink url="http://www.samba.org/samba/docs/Samba3-ByExample.pdf">book</ulink> for the Samba web site. 767</para> 768 769<sect2> 770<title>Machine Accounts Keep Expiring</title> 771 772<para> 773<indexterm><primary>Machine Trust Accounts</primary></indexterm> 774<indexterm><primary>passdb</primary></indexterm> 775<indexterm><primary>SAM</primary></indexterm> 776<indexterm><primary>Local Machine Trust Account</primary></indexterm> 777This problem will occur when the passdb (SAM) files are copied from a central 778server but the local BDC is acting as a PDC. This results in the application of 779Local Machine Trust Account password updates to the local SAM. Such updates 780are not copied back to the central server. The newer machine account password is then 781overwritten when the SAM is recopied from the PDC. The result is that the domain member machine 782on startup will find that its passwords do not match the one now in the database, and 783since the startup security check will now fail, this machine will not allow logon attempts 784to proceed and the account expiry error will be reported. 785</para> 786 787<para> 788The solution is to use a more robust passdb backend, such as the ldapsam backend, setting up 789a slave LDAP server for each BDC and a master LDAP server for the PDC. 790</para> 791 792</sect2> 793 794<sect2> 795<title>Can Samba Be a Backup Domain Controller to an NT4 PDC?</title> 796 797<para> 798<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm> 799<indexterm><primary>SAM</primary></indexterm> 800No. The native NT4 SAM replication protocols have not yet been fully implemented. 801</para> 802 803<para> 804<indexterm><primary>BDC</primary></indexterm> 805<indexterm><primary>PDC</primary></indexterm> 806<indexterm><primary>logon requests</primary></indexterm> 807Can I get the benefits of a BDC with Samba? Yes, but only to a Samba PDC.The 808main reason for implementing a BDC is availability. If the PDC is a Samba 809machine, a second Samba machine can be set up to service logon requests whenever 810the PDC is down. 811</para> 812 813</sect2> 814 815<sect2> 816<title>How Do I Replicate the smbpasswd File?</title> 817 818<para> 819<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm> 820<indexterm><primary>smbpasswd</primary></indexterm> 821<indexterm><primary>SAM</primary></indexterm> 822Replication of the smbpasswd file is sensitive. It has to be done whenever changes 823to the SAM are made. Every user's password change is done in the smbpasswd file and 824has to be replicated to the BDC. So replicating the smbpasswd file very often is necessary. 825</para> 826 827<para> 828<indexterm><primary>plaintext password</primary></indexterm> 829<indexterm><primary>ssh</primary></indexterm> 830<indexterm><primary>rsync</primary></indexterm> 831As the smbpasswd file contains plaintext password equivalents, it must not be 832sent unencrypted over the wire. The best way to set up smbpasswd replication from 833the PDC to the BDC is to use the utility rsync. rsync can use ssh as a transport. 834<command>ssh</command> itself can be set up to accept <emphasis>only</emphasis> 835<command>rsync</command> transfer without requiring the user to type a password. 836</para> 837 838<para> 839<indexterm><primary>machine trust accounts</primary></indexterm> 840<indexterm><primary>LDAP</primary></indexterm> 841As said a few times before, use of this method is broken and flawed. Machine trust 842accounts will go out of sync, resulting in a broken domain. This method is 843<emphasis>not</emphasis> recommended. Try using LDAP instead. 844</para> 845 846</sect2> 847 848<sect2> 849<title>Can I Do This All with LDAP?</title> 850 851<para> 852<indexterm><primary>pdb_ldap</primary></indexterm> 853<indexterm><primary>LDAP</primary></indexterm> 854The simple answer is yes. Samba's pdb_ldap code supports binding to a replica 855LDAP server and will also follow referrals and rebind to the master if it ever 856needs to make a modification to the database. (Normally BDCs are read-only, so 857this will not occur often). 858</para> 859 860</sect2> 861</sect1> 862</chapter> 863