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">
8 <author>&person.gd;<contrib>LDAP updates</contrib></author>
11 <title>Backup Domain Control</title>
14 Before you continue reading this section, please make sure that you are comfortable
15 with configuring a Samba Domain Controller as described in <link linkend="samba-pdc">Domain Control</link>.
19 <title>Features and Benefits</title>
22 This is one of the most difficult chapters to summarize. It does not matter what we say here
23 for someone will still draw conclusions and/or approach the Samba Team with expectations
24 that are either not yet capable of being delivered, or that can be achieved far more
25 effectively using a totally different approach. In the event that you should have a persistent
26 concern that is not addressed in this book, please email <ulink url="mailto:jht@samba.org">John H. Terpstra</ulink>
27 clearly setting out your requirements and/or question and we will do our best to provide a solution.
31 <indexterm><primary>SAM backend</primary><secondary>LDAP</secondary></indexterm>
32 Samba-3 is capable of acting as a Backup Domain Controller (BDC) to another Samba Primary Domain
33 Controller (PDC). A Samba-3 PDC can operate with an LDAP Account backend. The LDAP backend can be
34 either a common master LDAP server, or a slave server. The use of a slave LDAP server has the
35 benefit that when the master is down, clients may still be able to log onto the network.
36 This effectively gives Samba a high degree of scalability and is an effective solution
37 for large organizations. If you use an LDAP slave server for a PDC,
38 you will need to ensure the master's continued availability - if the
39 slave finds it's master down at the wrong time, you will have
40 stability and operational problems.
44 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
45 While it is possible to run a Samba-3 BDC with non-LDAP backend, that
46 backend must allow some form of 'two way' propagation, of changes
47 from the BDC to the master. Only LDAP is capable of this at this stage.
51 <indexterm><primary>SAM backend</primary><secondary>non-LDAP</secondary></indexterm>
52 The use of a non-LDAP backend SAM database is particularly problematic because Domain Member
53 servers and workstations periodically change the Machine Trust Account password. The new
54 password is then stored only locally. This means that in the absence of a centrally stored
55 accounts database (such as that provided with an LDAP-based solution) if Samba-3 is running
56 as a BDC, the BDC instance of the Domain Member trust account password will not reach the
57 PDC (master) copy of the SAM. If the PDC SAM is then replicated to BDCs, this results in
58 overwriting the SAM that contains the updated (changed) trust account password with resulting
59 breakage of the domain trust.
63 Considering the number of comments and questions raised concerning how to configure a BDC,
64 let's consider each possible option and look at the pros and cons for each possible solution.
65 <link linkend="pdc-bdc-table">Following table</link> lists possible design configurations for a PDC/BDC infrastructure.
66 <indexterm><primary>net</primary><secondary>rpc</secondary></indexterm>
67 <indexterm><primary>SAM backend</primary><secondary>ldapsam</secondary></indexterm>
68 <indexterm><primary>SAM backend</primary><secondary>tdbsam</secondary></indexterm>
69 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
72 <table frame="all" id="pdc-bdc-table"><title>Domain Backend Account Distribution Options</title>
74 <colspec align="center" colwidth="1*"/>
75 <colspec align="center" colwidth="1*"/>
76 <colspec align="left" colwidth="3*"/>
79 <row><entry>PDC Backend</entry><entry>BDC Backend</entry><entry>Notes/Discussion</entry></row>
83 <entry><para>Master LDAP Server</para></entry>
84 <entry><para>Slave LDAP Server</para></entry>
85 <entry><para>The optimal solution that provides high integrity. The SAM will be
86 replicated to a common master LDAP server.</para></entry>
89 <entry><para>Single Central LDAP Server</para></entry>
90 <entry><para>Single Central LDAP Server</para></entry>
92 A workable solution without fail-over ability. This is a usable solution, but not optimal.
96 <entry><para>tdbsam</para></entry>
97 <entry><para>tdbsam + <command>net rpc vampire</command></para></entry>
99 Does not work with Samba-3.0; as Samba does not implement the
100 server-side protocols required.
104 <entry><para>tdbsam</para></entry>
105 <entry><para>tdbsam + <command>rsync</command></para></entry>
107 Do not use this configuration.
108 Does not work because the TDB files are live and data may not
109 have been flushed to disk. Furthermore, this will cause
110 domain trust breakdown.
114 <entry><para>smbpasswd file</para></entry>
115 <entry><para>smbpasswd file</para></entry>
117 Do not use this configuration.
118 Not an elegant solution due to the delays in synchronization
120 from the issue of domain trust breakdown.
130 <title>Essential Background Information</title>
133 A Domain Controller is a machine that is able to answer logon requests from network
134 workstations. Microsoft LanManager and IBM LanServer were two early products that
135 provided this capability. The technology has become known as the LanMan Netlogon service.
139 When MS Windows NT3.10 was first released, it supported a new style of Domain Control
140 and with it a new form of the network logon service that has extended functionality.
141 This service became known as the NT NetLogon Service. The nature of this service has
142 changed with the evolution of MS Windows NT and today provides a complex array of
143 services that are implemented over an intricate spectrum of technologies.
147 <title>MS Windows NT4-style Domain Control</title>
150 Whenever a user logs into a Windows NT4/200x/XP Professional Workstation,
151 the workstation connects to a Domain Controller (authentication server) to validate that
152 the username and password the user entered are valid. If the information entered
153 does not match account information that has been stored in the Domain
154 Control database (the SAM, or Security Account Manager database), a set of error
155 codes is returned to the workstation that has made the authentication request.
159 When the username/password pair has been validated, the Domain Controller
160 (authentication server) will respond with full enumeration of the account information
161 that has been stored regarding that user in the User and Machine Accounts database
162 for that Domain. This information contains a complete network access profile for
163 the user but excludes any information that is particular to the user's desktop profile,
164 or for that matter it excludes all desktop profiles for groups that the user may
165 belong to. It does include password time limits, password uniqueness controls,
166 network access time limits, account validity information, machine names from which the
167 user may access the network, and much more. All this information was stored in the SAM
168 in all versions of MS Windows NT (3.10, 3.50, 3.51, 4.0).
172 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
173 The account information (user and machine) on Domain Controllers is stored in two files,
174 one containing the Security information and the other the SAM. These are stored in files
175 by the same name in the <filename>%SystemRoot%\System32\config</filename> directory.
176 This normally translates to the path <filename>C:\WinNT\System32\config</filename>. These
177 are the files that are involved in replication of the SAM database where Backup Domain
178 Controllers are present on the network.
182 There are two situations in which it is desirable to install Backup Domain Controllers:
187 On the local network that the Primary Domain Controller is on, if there are many
188 workstations and/or where the PDC is generally very busy. In this case the BDCs
189 will pick up network logon requests and help to add robustness to network services.
193 At each remote site, to reduce wide area network traffic and to add stability to
194 remote network operations. The design of the network, the strategic placement of
195 Backup Domain Controllers, together with an implementation that localizes as much
196 of network to client interchange as possible will help to minimize wide area network
197 bandwidth needs (and thus costs).
202 The inter-operation of a PDC and its BDCs in a true Windows NT4 environment is worth
203 mentioning here. The PDC contains the master copy of the SAM. In the event that an
204 administrator makes a change to the user account database while physically present
205 on the local network that has the PDC, the change will likely be made directly to
206 the PDC instance of the master copy of the SAM. In the event that this update may
207 be performed in a branch office, the change will likely be stored in a delta file
208 on the local BDC. The BDC will then send a trigger to the PDC to commence the process
209 of SAM synchronization. The PDC will then request the delta from the BDC and apply
210 it to the master SAM. The PDC will then contact all the BDCs in the Domain and
211 trigger them to obtain the update and then apply that to their own copy of the SAM.
215 Samba-3 can not participate in true SAM replication and is therefore not able to
216 employ precisely the same protocols used by MS Windows NT4. A Samba-3 BDC will
217 not create SAM update delta files. It will not inter-operate with a PDC (NT4 or Samba)
218 to synchronize the SAM from delta files that are held by BDCs.
222 Samba-3 cannot function as a BDC to an MS Windows NT4 PDC, and Samba-3 can not
223 function correctly as a PDC to an MS Windows NT4 BDC. Both Samba-3 and MS Windows
224 NT4 can function as a BDC to its own type of PDC.
228 The BDC is said to hold a <emphasis>read-only</emphasis> of the SAM from which
229 it is able to process network logon requests and authenticate users. The BDC can
230 continue to provide this service, particularly while, for example, the wide area
231 network link to the PDC is down. A BDC plays a very important role in both the
232 maintenance of Domain Security as well as in network integrity.
236 In the event that the NT4 PDC should need to be taken out of service, or if it dies,
237 one of the NT4 BDCs can be promoted to a PDC. If this happens while the original NT4 PDC is on
238 line, it is automatically demoted to an NT4 BDC. This is an important aspect of Domain
239 Controller management. The tool that is used to effect a promotion or a demotion is the
240 Server Manager for Domains. It should be noted that Samba-3 BDCs can not be promoted
241 in this manner because reconfiguration of Samba requires changes to the &smb.conf; file.
245 <title>Example PDC Configuration</title>
248 Beginning with Version 2.2, Samba officially supports domain logons for all current Windows clients,
249 including Windows NT4, 2003 and XP Professional. For Samba to be enabled as a PDC, some
250 parameters in the <smbconfsection name="[global]"/>-section of the &smb.conf; have to be set.
251 Refer to <link linkend="minimalPDC">following configuration</link> for an example of the minimum required settings.
254 <para><smbconfexample id="minimalPDC">
255 <title>Minimal smb.conf for a PDC in Use With a BDC &smbmdash; LDAP Server on PDC.</title>
256 <smbconfoption name="workgroup">&example.workgroup;</smbconfoption>
257 <smbconfoption name="passdb backend">ldapsam://localhost:389</smbconfoption>
258 <smbconfoption name="domain master">yes</smbconfoption>
259 <smbconfoption name="domain logons">yes</smbconfoption>
260 </smbconfexample></para>
263 Several other things like a <smbconfsection name="[homes]"/> and a
264 <smbconfsection name="[netlogon]"/> share also need to be set along with
265 settings for the profile path, the user's home drive, and so on. This is not covered in this
266 chapter; for more information please refer to <link linkend="samba-pdc">Domain Control</link>.
273 <title>LDAP Configuration Notes</title>
276 When configuring a master and a slave LDAP server, it is advisable to use the master LDAP server
277 for the PDC and slave LDAP servers for the BDCs. It is not essential to use slave LDAP servers, however,
278 many administrators will want to do so in order to provide redundant services. Of course, one or more BDCs
279 may use any slave LDAP server. Then again, it is entirely possible to use a single LDAP server for the
284 When configuring a master LDAP server that will have slave LDAP servers, do not forget to configure
285 this in the <filename>/etc/openldap/slapd.conf</filename> file. It must be noted that the DN of a
286 server certificate must use the CN attribute to name the server, and the CN must carry the servers'
287 fully qualified domain name. Additional alias names and wildcards may be present in the
288 subjectAltName certificate extension. More details on server certificate names are in RFC2830.
292 It does not really fit within the scope of this document, but a working LDAP installation is
293 basic to LDAP enabled Samba operation. When using an OpenLDAP server with Transport Layer Security
294 (TLS), the machine name in <filename>/etc/ssl/certs/slapd.pem</filename> must be the
295 same as in <filename>/etc/openldap/sldap.conf</filename>. The Red Hat Linux startup script
296 creates the <filename>slapd.pem</filename> file with hostname <quote>localhost.localdomain.</quote>
297 It is impossible to access this LDAP server from a slave LDAP server (i.e., a Samba BDC) unless the
298 certificate is recreated with a correct hostname.
302 For preference, do not install a Samba PDC on a OpenLDAP slave server. Joining client machines to the domain
303 will fail in this configuration because the change to the machine account in the LDAP tree
304 must take place on the master LDAP server. This is not replicated rapidly enough to the slave
305 server that the PDC queries. It therefore gives an error message on the client machine about
306 not being able to set up account credentials. The machine account is created on the LDAP server
307 but the password fields will be empty. Unfortunately, some sites are
308 unable to avoid such configurations, and these sites should review the
309 <smbconfoption name="ldap replication sleep"/> parameter, intended to slow down Samba sufficiently
310 for the replication to catch up. This is a kludge, and one that the
311 administrator must manually duplicate in any scripts (such as the
312 <smbconfoption name="add machine script"/>) that
317 Possible PDC/BDC plus LDAP configurations include:
322 PDC+BDC -> One Central LDAP Server.
325 PDC -> LDAP master server, BDC -> LDAP slave server.
328 PDC -> LDAP master, with secondary slave LDAP server.
330 BDC -> LDAP master, with secondary slave LDAP server.
333 PDC -> LDAP master, with secondary slave LDAP server.
335 BDC -> LDAP slave server, with secondary master LDAP server.
340 In order to have a fall-back configuration (secondary) LDAP server one would specify
341 the secondary LDAP server in the &smb.conf; file as shown in <link linkend="mulitldapcfg">following example</link>.
345 <smbconfexample id="mulitldapcfg">
346 <title>Multiple LDAP Servers in &smb.conf;</title>
348 <smbconfoption name="passdb backend"> </smbconfoption>
349 <member><parameter>ldapsam:"ldap://master.quenya.org ldap://slave.quenya.org"</parameter></member>
357 <title>Active Directory Domain Control</title>
360 As of the release of MS Windows 2000 and Active Directory, this information is now stored
361 in a directory that can be replicated and for which partial or full administrative control
362 can be delegated. Samba-3 is not able to be a Domain Controller within an Active Directory
363 tree, and it cannot be an Active Directory server. This means that Samba-3 also cannot
364 act as a Backup Domain Controller to an Active Directory Domain Controller.
370 <title>What Qualifies a Domain Controller on the Network?</title>
373 Every machine that is a Domain Controller for the domain MIDEARTH has to register the NetBIOS
374 group name MIDEARTH<#1c> with the WINS server and/or by broadcast on the local network.
375 The PDC also registers the unique NetBIOS name MIDEARTH<#1b> with the WINS server.
376 The name type <#1b> name is normally reserved for the Domain Master Browser, a role
377 that has nothing to do with anything related to authentication, but the Microsoft Domain
378 implementation requires the Domain Master Browser to be on the same machine as the PDC.
382 Where a WINS server is not used, broadcast name registrations alone must suffice. Refer to
383 <link linkend="netdiscuss">Network Browsing: Discussion</link> for more information regarding TCP/IP network protocols and how
384 SMB/CIFS names are handled.
390 <title>How does a Workstation find its Domain Controller?</title>
393 There are two different mechanisms to locate a domain controller, one method is used when
394 NetBIOS over TCP/IP is enabled and the other when it has been disabled in the TCP/IP
395 network configuration.
399 Where NetBIOS over TCP/IP is disabled, all name resolution involves the use of DNS, broadcast
400 messaging over UDP, as well as Active Directory communication technologies. In this type of
401 environment all machines require appropriate DNS entries. More information may be found in
402 <link linkend="adsdnstech">DNS and Active Directory</link>.
406 <title>NetBIOS Over TCP/IP Enabled</title>
408 An MS Windows NT4/200x/XP Professional workstation in the domain MIDEARTH that wants a
409 local user to be authenticated has to find the Domain Controller for MIDEARTH. It does this
410 by doing a NetBIOS name query for the group name MIDEARTH<#1c>. It assumes that each
411 of the machines it gets back from the queries is a Domain Controller and can answer logon
412 requests. To not open security holes, both the workstation and the selected Domain Controller
413 authenticate each other. After that the workstation sends the user's credentials (name and
414 password) to the local Domain Controller for validation.
420 <title>NetBIOS Over TCP/IP Disabled</title>
423 An MS Windows NT4/200x/XP Professional workstation in the realm <constant>quenya.org</constant>
424 that has a need to affect user logon authentication will locate the Domain Controller by
425 re-querying DNS servers for the <constant>_ldap._tcp.pdc._msdcs.quenya.org</constant> record.
426 More information regarding this subject may be found in <link linkend="adsdnstech">DNS and Active Directory</link>.
434 <title>Backup Domain Controller Configuration</title>
437 The creation of a BDC requires some steps to prepare the Samba server before
438 &smbd; is executed for the first time. These steps are outlines as follows:
439 <indexterm><primary>SID</primary></indexterm>
444 The domain SID has to be the same on the PDC and the BDC. In Samba versions
445 pre-2.2.5, the domain SID was stored in the file <filename>private/MACHINE.SID</filename>.
446 The domain SID is now stored in the file <filename>private/secrets.tdb</filename>. This file
447 is unique to each server and can not be copied from a PDC to a BDC, the BDC will generate
448 a new SID at start-up. It will over-write the PDC domain SID with the newly created BDC SID.
449 There is a procedure that will allow the BDC to aquire the Domain SID. This is described here.
453 To retrieve the domain SID from the PDC or an existing BDC and store it in the
454 <filename>secrets.tdb</filename>, execute:
457 &rootprompt;<userinput>net rpc getsid</userinput>
462 Specification of the <smbconfoption name="ldap admin dn"/> is obligatory.
463 This also requires the LDAP administration password to be set in the <filename>secrets.tdb</filename>
464 using the <command>smbpasswd -w <replaceable>mysecret</replaceable></command>.
468 Either <smbconfoption name="ldap suffix"/> or
469 <smbconfoption name="ldap idmap suffix"/> must be specified in
474 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
475 The UNIX user database has to be synchronized from the PDC to the
476 BDC. This means that both the <filename>/etc/passwd</filename> and
477 <filename>/etc/group</filename> have to be replicated from the PDC
478 to the BDC. This can be done manually whenever changes are made.
479 Alternately, the PDC is set up as an NIS master server and the BDC as an NIS slave
480 server. To set up the BDC as a mere NIS client would not be enough,
481 as the BDC would not be able to access its user database in case of
482 a PDC failure. NIS is by no means the only method to synchronize
483 passwords. An LDAP solution would also work.
488 The Samba password database must be replicated from the PDC to the BDC.
489 Although it is possible to synchronize the <filename>smbpasswd</filename>
490 file with <command>rsync</command> and <command>ssh</command>, this method
491 is broken and flawed, and is therefore not recommended. A better solution
492 is to set up slave LDAP servers for each BDC and a master LDAP server for the PDC.
496 The netlogon share has to be replicated from the PDC to the
497 BDC. This can be done manually whenever login scripts are changed,
498 or it can be done automatically using a <command>cron</command> job
499 that will replicate the directory structure in this share using a tool
500 like <command>rsync</command>.
506 <title>Example Configuration</title>
508 <para> Finally, the BDC has to be found by the workstations. This can be
509 done by setting Samba as shown in <link linkend="minim-bdc">the next example</link>.
512 <para><smbconfexample id="minim-bdc">
513 <title>Minimal setup for being a BDC</title>
514 <smbconfoption name="workgroup">&example.workgroup;</smbconfoption>
515 <smbconfoption name="passdb backend">ldapsam:ldap://slave-ldap.quenya.org</smbconfoption>
516 <smbconfoption name="domain master">no</smbconfoption>
517 <smbconfoption name="domain logons">yes</smbconfoption>
518 <smbconfoption name="idmap backend">ldap:ldap://slave-ldap.quenya.org</smbconfoption>
519 </smbconfexample></para>
522 In the <smbconfsection name="[global]"/>-section of the &smb.conf; of the BDC. This makes the BDC
523 only register the name MIDEARTH<#1c> with the WINS server. This is no
524 problem as the name MIDEARTH<#1c> is a NetBIOS group name that is meant to
525 be registered by more than one machine. The parameter
526 <smbconfoption name="domain master">no</smbconfoption>
527 forces the BDC not to register <?latex \linebreak ?>MIDEARTH<#1b> which as a unique NetBIOS
528 name is reserved for the Primary Domain Controller.
532 <indexterm><primary>idmap backend</primary></indexterm>
533 <indexterm><primary>winbindd</primary></indexterm>
534 The <parameter>idmap backend</parameter> will redirect the <command>winbindd</command> utility to
535 use the LDAP database to resolve all UIDs and GIDs for UNIX accounts.
539 <indexterm><primary>Server Type</primary><secondary>Domain Member</secondary></indexterm>
540 Samba-3 has introduced a new ID mapping facility. One of the features of this facility is that it
541 allows greater flexibility in how user and group IDs are handled in respect to NT Domain User and Group
542 SIDs. One of the new facilities provides for explicitly ensuring that UNIX/Linux UID and GID values
543 will be consistent on the PDC, all BDCs and all Domain Member servers. The parameter that controls this
544 is called <parameter>idmap backend</parameter>. Please refer to the man page for &smb.conf; for more information
545 regarding its behavior.
549 The use of the <smbconfoption name="idmap backend">ldap:ldap://master.quenya.org</smbconfoption>
550 option on a BDC only make sense where ldapsam is used on a PDC. The purpose for an LDAP based idmap backend is
551 also to allow a domain-member (without its own passdb backend) to use winbindd to resolve Windows network users
552 and groups to common UID/GIDs. In other words, this option is generally intended for use on BDCs and on Domain
560 <title>Common Errors</title>
563 As this is a rather new area for Samba, there are not many examples that we may refer to.
564 Updates will be published as they become available and may be found in later Samba releases or
565 from the Samba web <ulink url="http://samba.org">site.</ulink>
569 <title>Machine Accounts Keep Expiring</title>
572 <indexterm><primary>Machine Trust Accounts</primary></indexterm>
573 This problem will occur when the passdb (SAM) files are copied from a central
574 server but the local Backup Domain Controller is acting as a PDC. This results in the application of
575 Local Machine Trust Account password updates to the local SAM. Such updates
576 are not copied back to the central server. The newer machine account password is then over
577 written when the SAM is re-copied from the PDC. The result is that the Domain Member machine
578 on start up will find that its passwords do not match the one now in the database and
579 since the startup security check will now fail, this machine will not allow logon attempts
580 to proceed and the account expiry error will be reported.
584 The solution is to use a more robust passdb backend, such as the ldapsam backend, setting up
585 a slave LDAP server for each BDC, and a master LDAP server for the PDC.
591 <title>Can Samba Be a Backup Domain Controller to an NT4 PDC?</title>
594 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
595 No. The native NT4 SAM replication protocols have not yet been fully implemented.
599 Can I get the benefits of a BDC with Samba? Yes, but only to a Samba PDC.The
600 main reason for implementing a BDC is availability. If the PDC is a Samba
601 machine, a second Samba machine can be set up to service logon requests whenever
608 <title>How Do I Replicate the smbpasswd File?</title>
611 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
612 Replication of the smbpasswd file is sensitive. It has to be done whenever changes
613 to the SAM are made. Every user's password change is done in the smbpasswd file and
614 has to be replicated to the BDC. So replicating the smbpasswd file very often is necessary.
618 As the smbpasswd file contains plain text password equivalents, it must not be
619 sent unencrypted over the wire. The best way to set up smbpasswd replication from
620 the PDC to the BDC is to use the utility rsync. rsync can use ssh as a transport.
621 <command>ssh</command> itself can be set up to accept <emphasis>only</emphasis>
622 <command>rsync</command> transfer without requiring the user to type a password.
626 As said a few times before, use of this method is broken and flawed. Machine trust
627 accounts will go out of sync, resulting in a broken domain. This method is
628 <emphasis>not</emphasis> recommended. Try using LDAP instead.
634 <title>Can I Do This All with LDAP?</title>
637 The simple answer is yes. Samba's pdb_ldap code supports binding to a replica
638 LDAP server, and will also follow referrals and re-bind to the master if it ever
639 needs to make a modification to the database. (Normally BDCs are read only, so
640 this will not occur often).