--- /dev/null
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 5. Backup Domain Control</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.68.1"><link rel="start" href="index.html" title="The Official Samba-3 HOWTO and Reference Guide"><link rel="up" href="type.html" title="Part II. Server Configuration Basics"><link rel="prev" href="samba-pdc.html" title="Chapter 4. Domain Control"><link rel="next" href="domain-member.html" title="Chapter 6. Domain Membership"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 5. Backup Domain Control</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="samba-pdc.html">Prev</a> </td><th width="60%" align="center">Part II. Server Configuration Basics</th><td width="20%" align="right"> <a accesskey="n" href="domain-member.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="samba-bdc"></a>Chapter 5. Backup Domain Control</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Volker</span> <span class="surname">Lendecke</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><code class="email"><<a href="mailto:Volker.Lendecke@SerNet.DE">Volker.Lendecke@SerNet.DE</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Guenther</span> <span class="surname">Deschner</span></h3><span class="contrib">LDAP updates</span><div class="affiliation"><span class="orgname">SuSE<br></span><div class="address"><p><code class="email"><<a href="mailto:gd@suse.de">gd@suse.de</a>></code></p></div></div></div></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="samba-bdc.html#id2533545">Features and Benefits</a></span></dt><dt><span class="sect1"><a href="samba-bdc.html#id2533951">Essential Background Information</a></span></dt><dd><dl><dt><span class="sect2"><a href="samba-bdc.html#id2534021">MS Windows NT4-style Domain Control</a></span></dt><dt><span class="sect2"><a href="samba-bdc.html#id2534706">LDAP Configuration Notes</a></span></dt><dt><span class="sect2"><a href="samba-bdc.html#id2535062">Active Directory Domain Control</a></span></dt><dt><span class="sect2"><a href="samba-bdc.html#id2535120">What Qualifies a Domain Controller on the Network?</a></span></dt><dt><span class="sect2"><a href="samba-bdc.html#id2535211">How Does a Workstation find its Domain Controller?</a></span></dt></dl></dd><dt><span class="sect1"><a href="samba-bdc.html#id2535392">Backup Domain Controller Configuration</a></span></dt><dd><dl><dt><span class="sect2"><a href="samba-bdc.html#id2535881">Example Configuration</a></span></dt></dl></dd><dt><span class="sect1"><a href="samba-bdc.html#id2536342">Common Errors</a></span></dt><dd><dl><dt><span class="sect2"><a href="samba-bdc.html#id2536387">Machine Accounts Keep Expiring</a></span></dt><dt><span class="sect2"><a href="samba-bdc.html#id2536442">Can Samba Be a Backup Domain Controller to an NT4 PDC?</a></span></dt><dt><span class="sect2"><a href="samba-bdc.html#id2536497">How Do I Replicate the smbpasswd File?</a></span></dt><dt><span class="sect2"><a href="samba-bdc.html#id2536602">Can I Do This All with LDAP?</a></span></dt></dl></dd></dl></div><p>
+Before you continue reading this section, please make sure that you are comfortable
+with configuring a Samba domain controller as described in <a href="samba-pdc.html" title="Chapter 4. Domain Control">Domain Control</a>.
+</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2533545"></a>Features and Benefits</h2></div></div></div><p>
+This is one of the most difficult chapters to summarize. It does not matter what we say here, for someone will
+still draw conclusions and/or approach the Samba Team with expectations that are either not yet capable of
+being delivered or that can be achieved far more effectively using a totally different approach. In the event
+that you should have a persistent concern that is not addressed in this book, please email <a href="mailto:jht@samba.org" target="_top">John H. Terpstra</a> clearly setting out your requirements and/or question, and
+we will do our best to provide a solution.
+</p><p>
+<a class="indexterm" name="id2533572"></a>
+<a class="indexterm" name="id2533580"></a>
+<a class="indexterm" name="id2533587"></a>
+<a class="indexterm" name="id2533594"></a>
+<a class="indexterm" name="id2533603"></a>
+Samba-3 can act as a Backup Domain Controller (BDC) to another Samba Primary Domain Controller (PDC). A
+Samba-3 PDC can operate with an LDAP account backend. The LDAP backend can be either a common master LDAP
+server or a slave server. The use of a slave LDAP server has the benefit that when the master is down, clients
+may still be able to log onto the network. This effectively gives Samba a high degree of scalability and is
+an effective solution for large organizations. If you use an LDAP slave server for a PDC, you will need to
+ensure the master's continued availability if the slave finds its master down at the wrong time,
+you will have stability and operational problems.
+</p><p>
+<a class="indexterm" name="id2533628"></a>
+<a class="indexterm" name="id2533636"></a>
+<a class="indexterm" name="id2533645"></a>
+<a class="indexterm" name="id2533654"></a>
+While it is possible to run a Samba-3 BDC with a non-LDAP backend, that backend must allow some form of
+"two-way" propagation of changes from the BDC to the master. At this time only LDAP delivers the capability
+to propagate identity database changes from the BDC to the PDC. The BDC can use a slave LDAP server, while it
+is preferable for the PDC to use as its primary an LDAP master server.
+</p><p>
+<a class="indexterm" name="id2533671"></a>
+<a class="indexterm" name="id2533680"></a>
+<a class="indexterm" name="id2533689"></a>
+<a class="indexterm" name="id2533701"></a>
+<a class="indexterm" name="id2533708"></a>
+<a class="indexterm" name="id2533714"></a>
+<a class="indexterm" name="id2533721"></a>
+The use of a non-LDAP backend SAM database is particularly problematic because domain member
+servers and workstations periodically change the Machine Trust Account password. The new
+password is then stored only locally. This means that in the absence of a centrally stored
+accounts database (such as that provided with an LDAP-based solution) if Samba-3 is running
+as a BDC, the BDC instance of the domain member trust account password will not reach the
+PDC (master) copy of the SAM. If the PDC SAM is then replicated to BDCs, this results in
+overwriting the SAM that contains the updated (changed) trust account password with resulting
+breakage of the domain trust.
+</p><p>
+<a class="indexterm" name="id2533743"></a>
+<a class="indexterm" name="id2533751"></a>
+<a class="indexterm" name="id2533760"></a>
+<a class="indexterm" name="id2533770"></a>
+Considering the number of comments and questions raised concerning how to configure a BDC,
+let's consider each possible option and look at the pros and cons for each possible solution.
+<a href="samba-bdc.html#pdc-bdc-table" title="Table 5.1. Domain Backend Account Distribution Options">The Domain Backend Account Distribution Options table below</a> lists
+possible design configurations for a PDC/BDC infrastructure.
+</p><div class="table"><a name="pdc-bdc-table"></a><p class="title"><b>Table 5.1. Domain Backend Account Distribution Options</b></p><table summary="Domain Backend Account Distribution Options" border="1"><colgroup><col align="center"><col align="center"><col align="left"></colgroup><thead><tr><th align="center">PDC Backend</th><th align="center">BDC Backend</th><th align="left">Notes/Discussion</th></tr></thead><tbody><tr><td align="center"><p>Master LDAP Server</p></td><td align="center"><p>Slave LDAP Server</p></td><td align="left"><p>The optimal solution that provides high integrity. The SAM will be
+ replicated to a common master LDAP server.</p></td></tr><tr><td align="center"><p>Single Central LDAP Server</p></td><td align="center"><p>Single Central LDAP Server</p></td><td align="left"><p>
+ A workable solution without failover ability. This is a usable solution, but not optimal.
+ </p></td></tr><tr><td align="center"><p>tdbsam</p></td><td align="center"><p>tdbsam + <span><strong class="command">net rpc vampire</strong></span></p></td><td align="left"><p>
+ Does not work with Samba-3.0; Samba does not implement the
+ server-side protocols required.
+ </p></td></tr><tr><td align="center"><p>tdbsam</p></td><td align="center"><p>tdbsam + <span><strong class="command">rsync</strong></span></p></td><td align="left"><p>
+ Do not use this configuration.
+ Does not work because the TDB files are live and data may not
+ have been flushed to disk. Furthermore, this will cause
+ domain trust breakdown.
+ </p></td></tr><tr><td align="center"><p>smbpasswd file</p></td><td align="center"><p>smbpasswd file</p></td><td align="left"><p>
+ Do not use this configuration.
+ Not an elegant solution due to the delays in synchronization
+ and also suffers
+ from the issue of domain trust breakdown.
+ </p></td></tr></tbody></table></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2533951"></a>Essential Background Information</h2></div></div></div><p>
+<a class="indexterm" name="id2533959"></a>
+<a class="indexterm" name="id2533966"></a>
+<a class="indexterm" name="id2533973"></a>
+<a class="indexterm" name="id2533980"></a>
+A domain controller is a machine that is able to answer logon requests from network
+workstations. Microsoft LanManager and IBM LanServer were two early products that
+provided this capability. The technology has become known as the LanMan Netlogon service.
+</p><p>
+<a class="indexterm" name="id2533994"></a>
+<a class="indexterm" name="id2534006"></a>
+When MS Windows NT3.10 was first released, it supported a new style of Domain Control
+and with it a new form of the network logon service that has extended functionality.
+This service became known as the NT NetLogon Service. The nature of this service has
+changed with the evolution of MS Windows NT and today provides a complex array of
+services that are implemented over an intricate spectrum of technologies.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2534021"></a>MS Windows NT4-style Domain Control</h3></div></div></div><p>
+<a class="indexterm" name="id2534029"></a>
+<a class="indexterm" name="id2534036"></a>
+<a class="indexterm" name="id2534043"></a>
+<a class="indexterm" name="id2534050"></a>
+<a class="indexterm" name="id2534057"></a>
+<a class="indexterm" name="id2534063"></a>
+<a class="indexterm" name="id2534073"></a>
+Whenever a user logs into a Windows NT4/200x/XP Professional workstation,
+the workstation connects to a domain controller (authentication server) to validate that
+the username and password the user entered are valid. If the information entered
+does not match account information that has been stored in the domain
+control database (the SAM, or Security Account Manager database), a set of error
+codes is returned to the workstation that has made the authentication request.
+</p><p>
+<a class="indexterm" name="id2534093"></a>
+<a class="indexterm" name="id2534100"></a>
+<a class="indexterm" name="id2534107"></a>
+<a class="indexterm" name="id2534114"></a>
+<a class="indexterm" name="id2534121"></a>
+When the username/password pair has been validated, the domain controller
+(authentication server) will respond with full enumeration of the account information
+that has been stored regarding that user in the user and machine accounts database
+for that domain. This information contains a complete network access profile for
+the user but excludes any information that is particular to the user's desktop profile,
+or for that matter it excludes all desktop profiles for groups that the user may
+belong to. It does include password time limits, password uniqueness controls,
+network access time limits, account validity information, machine names from which the
+user may access the network, and much more. All this information was stored in the SAM
+in all versions of MS Windows NT (3.10, 3.50, 3.51, 4.0).
+</p><p>
+<a class="indexterm" name="id2534145"></a>
+<a class="indexterm" name="id2534154"></a>
+<a class="indexterm" name="id2534161"></a>
+<a class="indexterm" name="id2534168"></a>
+<a class="indexterm" name="id2534174"></a>
+The account information (user and machine) on domain controllers is stored in two files,
+one containing the security information and the other the SAM. These are stored in files
+by the same name in the <code class="filename">%SystemRoot%\System32\config</code> directory.
+This normally translates to the path <code class="filename">C:\WinNT\System32\config</code>. These
+are the files that are involved in replication of the SAM database where BDCs are present
+on the network.
+</p><p>
+There are two situations in which it is desirable to install BDCs:
+</p><div class="itemizedlist"><ul type="disc"><li><p>
+ <a class="indexterm" name="id2534210"></a>
+ <a class="indexterm" name="id2534217"></a>
+ On the local network that the PDC is on, if there are many
+ workstations and/or where the PDC is generally very busy. In this case the BDCs
+ will pick up network logon requests and help to add robustness to network services.
+ </p></li><li><p>
+ <a class="indexterm" name="id2534232"></a>
+ At each remote site, to reduce wide-area network traffic and to add stability to
+ remote network operations. The design of the network, and the strategic placement of
+ BDCs, together with an implementation that localizes as much of network to client
+ interchange as possible, will help to minimize wide-area network bandwidth needs
+ (and thus costs).
+ </p></li></ul></div><p>
+<a class="indexterm" name="id2534251"></a>
+<a class="indexterm" name="id2534258"></a>
+<a class="indexterm" name="id2534264"></a>
+<a class="indexterm" name="id2534271"></a>
+<a class="indexterm" name="id2534278"></a>
+The interoperation of a PDC and its BDCs in a true Windows NT4 environment is worth
+mentioning here. The PDC contains the master copy of the SAM. In the event that an
+administrator makes a change to the user account database while physically present
+on the local network that has the PDC, the change will likely be made directly to
+the PDC instance of the master copy of the SAM. In the event that this update may
+be performed in a branch office, the change will likely be stored in a delta file
+on the local BDC. The BDC will then send a trigger to the PDC to commence the process
+of SAM synchronization. The PDC will then request the delta from the BDC and apply
+it to the master SAM. The PDC will then contact all the BDCs in the domain and
+trigger them to obtain the update and then apply that to their own copy of the SAM.
+</p><p>
+<a class="indexterm" name="id2534302"></a>
+<a class="indexterm" name="id2534311"></a>
+<a class="indexterm" name="id2534320"></a>
+<a class="indexterm" name="id2534326"></a>
+Samba-3 cannot participate in true SAM replication and is therefore not able to
+employ precisely the same protocols used by MS Windows NT4. A Samba-3 BDC will
+not create SAM update delta files. It will not interoperate with a PDC (NT4 or Samba)
+to synchronize the SAM from delta files that are held by BDCs.
+</p><p>
+<a class="indexterm" name="id2534341"></a>
+<a class="indexterm" name="id2534348"></a>
+Samba-3 cannot function as a BDC to an MS Windows NT4 PDC, and Samba-3 cannot
+function correctly as a PDC to an MS Windows NT4 BDC. Both Samba-3 and MS Windows
+NT4 can function as a BDC to its own type of PDC.
+</p><p>
+<a class="indexterm" name="id2534361"></a>
+<a class="indexterm" name="id2534368"></a>
+<a class="indexterm" name="id2534374"></a>
+The BDC is said to hold a <span class="emphasis"><em>read-only</em></span> of the SAM from which
+it is able to process network logon requests and authenticate users. The BDC can
+continue to provide this service, particularly while, for example, the wide-area
+network link to the PDC is down. A BDC plays a very important role in both the
+maintenance of domain security as well as in network integrity.
+</p><p>
+<a class="indexterm" name="id2534394"></a>
+<a class="indexterm" name="id2534400"></a>
+<a class="indexterm" name="id2534407"></a>
+<a class="indexterm" name="id2534414"></a>
+In the event that the NT4 PDC should need to be taken out of service, or if it dies, one of the NT4 BDCs can
+be promoted to a PDC. If this happens while the original NT4 PDC is online, it is automatically demoted to an
+NT4 BDC. This is an important aspect of domain controller management. The tool that is used to effect a
+promotion or a demotion is the Server Manager for Domains. It should be noted that Samba-3 BDCs cannot be
+promoted in this manner because reconfiguration of Samba requires changes to the <code class="filename">smb.conf</code> file. It is easy
+enough to manuall change the <code class="filename">smb.conf</code> file and then restart relevant Samba network services.
+</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2534444"></a>Example PDC Configuration</h4></div></div></div><p>
+<a class="indexterm" name="id2534452"></a>
+<a class="indexterm" name="id2534459"></a>
+Beginning with Version 2.2, Samba officially supports domain logons for all current Windows clients, including
+Windows NT4, 2003, and XP Professional. For Samba to be enabled as a PDC, some parameters in the
+<em class="parameter"><code>[global]</code></em> section of the <code class="filename">smb.conf</code> have to be set. Refer to <a href="samba-bdc.html#minimalPDC" title="Example 5.1. Minimal smb.conf for a PDC in Use with a BDC LDAP Server on PDC">the Minimal smb.conf for a PDC in Use with a BDC LDAP Server on PDC
+section</a> for an example of the minimum required settings.
+</p><div class="example"><a name="minimalPDC"></a><p class="title"><b>Example 5.1. Minimal smb.conf for a PDC in Use with a BDC LDAP Server on PDC</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2534513"></a><em class="parameter"><code>workgroup = MIDEARTH</code></em></td></tr><tr><td><a class="indexterm" name="id2534525"></a><em class="parameter"><code>passdb backend = ldapsam://localhost:389</code></em></td></tr><tr><td><a class="indexterm" name="id2534539"></a><em class="parameter"><code>domain master = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2534551"></a><em class="parameter"><code>domain logons = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2534564"></a><em class="parameter"><code>ldap suffix = dc=quenya,dc=org</code></em></td></tr><tr><td><a class="indexterm" name="id2534577"></a><em class="parameter"><code>ldap user suffix = ou=Users</code></em></td></tr><tr><td><a class="indexterm" name="id2534590"></a><em class="parameter"><code>ldap group suffix = ou=Groups</code></em></td></tr><tr><td><a class="indexterm" name="id2534603"></a><em class="parameter"><code>ldap machine suffix = ou=Computers</code></em></td></tr><tr><td><a class="indexterm" name="id2534616"></a><em class="parameter"><code>ldap idmap suffix = ou=Idmap</code></em></td></tr><tr><td><a class="indexterm" name="id2534629"></a><em class="parameter"><code>ldap admin dn = cn=sambadmin,dc=quenya,dc=org</code></em></td></tr></table></div><p>
+<a class="indexterm" name="id2534646"></a>
+<a class="indexterm" name="id2534653"></a>
+Several other things like a <em class="parameter"><code>[homes]</code></em> and a <em class="parameter"><code>[netlogon]</code></em> share
+also need to be set along with settings for the profile path, the user's home drive, and so on. This is not
+covered in this chapter; for more information please refer to <a href="samba-pdc.html" title="Chapter 4. Domain Control">Domain Control</a>.
+Refer to <a href="samba-pdc.html" title="Chapter 4. Domain Control">the Domain Control chapter</a> for specific recommendations for PDC
+configuration. Alternately, fully documented working example network configurations using OpenLDAP and Samba
+as available in the <a href="http://www.samba.org/samba/docs/Samba3-ByExample" target="_top">book</a> “<span class="quote">Samba-3
+by Example</span>” that may be obtained from local and on-line book stores.
+</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2534706"></a>LDAP Configuration Notes</h3></div></div></div><p>
+<a class="indexterm" name="id2534714"></a>
+<a class="indexterm" name="id2534723"></a>
+<a class="indexterm" name="id2534733"></a>
+When configuring a master and a slave LDAP server, it is advisable to use the master LDAP server
+for the PDC and slave LDAP servers for the BDCs. It is not essential to use slave LDAP servers; however,
+many administrators will want to do so in order to provide redundant services. Of course, one or more BDCs
+may use any slave LDAP server. Then again, it is entirely possible to use a single LDAP server for the
+entire network.
+</p><p>
+<a class="indexterm" name="id2534750"></a>
+<a class="indexterm" name="id2534759"></a>
+<a class="indexterm" name="id2534768"></a>
+<a class="indexterm" name="id2534775"></a>
+<a class="indexterm" name="id2534781"></a>
+When configuring a master LDAP server that will have slave LDAP servers, do not forget to configure this in
+the <code class="filename">/etc/openldap/slapd.conf</code> file. It must be noted that the DN of a server certificate
+must use the CN attribute to name the server, and the CN must carry the servers' fully qualified domain name.
+Additional alias names and wildcards may be present in the subjectAltName certificate extension. More details
+on server certificate names are in RFC2830.
+</p><p>
+<a class="indexterm" name="id2534805"></a>
+<a class="indexterm" name="id2534812"></a>
+<a class="indexterm" name="id2534818"></a>
+<a class="indexterm" name="id2534825"></a>
+<a class="indexterm" name="id2534834"></a>
+<a class="indexterm" name="id2534841"></a>
+<a class="indexterm" name="id2534848"></a>
+It does not really fit within the scope of this document, but a working LDAP installation is basic to
+LDAP-enabled Samba operation. When using an OpenLDAP server with Transport Layer Security (TLS), the machine
+name in <code class="filename">/etc/ssl/certs/slapd.pem</code> must be the same as in
+<code class="filename">/etc/openldap/sldap.conf</code>. The Red Hat Linux startup script creates the
+<code class="filename">slapd.pem</code> file with hostname “<span class="quote">localhost.localdomain.</span>” It is impossible to
+access this LDAP server from a slave LDAP server (i.e., a Samba BDC) unless the certificate is re-created with
+a correct hostname.
+</p><p>
+<a class="indexterm" name="id2534888"></a>
+<a class="indexterm" name="id2534895"></a>
+<a class="indexterm" name="id2534901"></a>
+<a class="indexterm" name="id2534908"></a>
+<a class="indexterm" name="id2534915"></a>
+<a class="indexterm" name="id2534922"></a>
+Do not install a Samba PDC so that is uses an LDAP slave server. Joining client machines to the domain
+will fail in this configuration because the change to the machine account in the LDAP tree must take place on
+the master LDAP server. This is not replicated rapidly enough to the slave server that the PDC queries. It
+therefore gives an error message on the client machine about not being able to set up account credentials. The
+machine account is created on the LDAP server, but the password fields will be empty. Unfortunately, some
+sites are unable to avoid such configurations, and these sites should review the <a class="indexterm" name="id2534939"></a>ldap replication sleep parameter, intended to slow down Samba sufficiently for the replication to catch up.
+This is a kludge, and one that the administrator must manually duplicate in any scripts (such as the
+<a class="indexterm" name="id2534950"></a>add machine script) that they use.
+</p><p>
+Possible PDC/BDC plus LDAP configurations include:
+</p><div class="itemizedlist"><ul type="disc"><li><p>
+ PDC+BDC -> One Central LDAP Server.
+ </p></li><li><p>
+ PDC -> LDAP master server, BDC -> LDAP slave server.
+ </p></li><li><p>
+ PDC -> LDAP master, with secondary slave LDAP server.
+ </p><p>
+ BDC -> LDAP master, with secondary slave LDAP server.
+ </p></li><li><p>
+ PDC -> LDAP master, with secondary slave LDAP server.
+ </p><p>
+ BDC -> LDAP slave server, with secondary master LDAP server.
+ </p></li></ul></div><p>
+In order to have a fallback configuration (secondary) LDAP server, you would specify
+the secondary LDAP server in the <code class="filename">smb.conf</code> file as shown in <a href="samba-bdc.html#mulitldapcfg" title="Example 5.2. Multiple LDAP Servers in smb.conf">the Multiple LDAP
+Servers in <code class="filename">smb.conf</code> example</a>.
+</p><div class="example"><a name="mulitldapcfg"></a><p class="title"><b>Example 5.2. Multiple LDAP Servers in <code class="filename">smb.conf</code></b></p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2535046"></a><em class="parameter"><code>passdb backend = ldapsam:"ldap://master.quenya.org ldap://slave.quenya.org"</code></em></td></tr></table></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2535062"></a>Active Directory Domain Control</h3></div></div></div><p>
+<a class="indexterm" name="id2535070"></a>
+<a class="indexterm" name="id2535077"></a>
+<a class="indexterm" name="id2535084"></a>
+<a class="indexterm" name="id2535090"></a>
+<a class="indexterm" name="id2535097"></a>
+<a class="indexterm" name="id2535104"></a>
+As of the release of MS Windows 2000 and Active Directory, this information is now stored
+in a directory that can be replicated and for which partial or full administrative control
+can be delegated. Samba-3 is not able to be a domain controller within an Active Directory
+tree, and it cannot be an Active Directory server. This means that Samba-3 also cannot
+act as a BDC to an Active Directory domain controller.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2535120"></a>What Qualifies a Domain Controller on the Network?</h3></div></div></div><p>
+<a class="indexterm" name="id2535128"></a>
+<a class="indexterm" name="id2535135"></a>
+<a class="indexterm" name="id2535141"></a>
+<a class="indexterm" name="id2535148"></a>
+Every machine that is a domain controller for the domain MIDEARTH has to register the NetBIOS
+group name MIDEARTH<1C> with the WINS server and/or by broadcast on the local network.
+The PDC also registers the unique NetBIOS name MIDEARTH<1B> with the WINS server.
+The name type <1B> name is normally reserved for the Domain Master Browser (DMB), a role
+that has nothing to do with anything related to authentication, but the Microsoft domain
+implementation requires the DMB to be on the same machine as the PDC.
+</p><p>
+<a class="indexterm" name="id2535170"></a>
+<a class="indexterm" name="id2535177"></a>
+<a class="indexterm" name="id2535184"></a>
+Where a WINS server is not used, broadcast name registrations alone must suffice. Refer to
+<a href="NetworkBrowsing.html" title="Chapter 9. Network Browsing">Network Browsing</a>,<a href="NetworkBrowsing.html#netdiscuss" title="Discussion">Discussion</a>
+for more information regarding TCP/IP network protocols and how SMB/CIFS names are handled.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2535211"></a>How Does a Workstation find its Domain Controller?</h3></div></div></div><p>
+<a class="indexterm" name="id2535219"></a>
+<a class="indexterm" name="id2535226"></a>
+There are two different mechanisms to locate a domain controller: one method is used when
+NetBIOS over TCP/IP is enabled and the other when it has been disabled in the TCP/IP
+network configuration.
+</p><p>
+<a class="indexterm" name="id2535240"></a>
+<a class="indexterm" name="id2535246"></a>
+Where NetBIOS over TCP/IP is disabled, all name resolution involves the use of DNS, broadcast
+messaging over UDP, as well as Active Directory communication technologies. In this type of
+environment all machines require appropriate DNS entries. More information may be found in
+<a href="NetworkBrowsing.html#adsdnstech" title="DNS and Active Directory">DNS and Active Directory</a>.
+</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2535268"></a>NetBIOS Over TCP/IP Enabled</h4></div></div></div><p>
+<a class="indexterm" name="id2535276"></a>
+<a class="indexterm" name="id2535282"></a>
+<a class="indexterm" name="id2535289"></a>
+<a class="indexterm" name="id2535296"></a>
+An MS Windows NT4/200x/XP Professional workstation in the domain MIDEARTH that wants a
+local user to be authenticated has to find the domain controller for MIDEARTH. It does this
+by doing a NetBIOS name query for the group name MIDEARTH<1C>. It assumes that each
+of the machines it gets back from the queries is a domain controller and can answer logon
+requests. To not open security holes, both the workstation and the selected domain controller
+authenticate each other. After that the workstation sends the user's credentials (name and
+password) to the local domain controller for validation.
+</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2535333"></a>NetBIOS Over TCP/IP Disabled</h4></div></div></div><p>
+<a class="indexterm" name="id2535341"></a>
+<a class="indexterm" name="id2535348"></a>
+<a class="indexterm" name="id2535355"></a>
+<a class="indexterm" name="id2535362"></a>
+An MS Windows NT4/200x/XP Professional workstation in the realm <code class="constant">quenya.org</code>
+that has a need to affect user logon authentication will locate the domain controller by
+re-querying DNS servers for the <code class="constant">_ldap._tcp.pdc._msdcs.quenya.org</code> record.
+More information regarding this subject may be found in <a href="NetworkBrowsing.html#adsdnstech" title="DNS and Active Directory">DNS and Active Directory</a>.
+</p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2535392"></a>Backup Domain Controller Configuration</h2></div></div></div><p>
+<a class="indexterm" name="id2535401"></a>
+The creation of a BDC requires some steps to prepare the Samba server before
+<span class="application">smbd</span> is executed for the first time. These steps are as follows:
+</p><div class="itemizedlist"><ul type="disc"><li><p>
+ <a class="indexterm" name="id2535422"></a>
+ <a class="indexterm" name="id2535428"></a>
+ <a class="indexterm" name="id2535435"></a>
+ <a class="indexterm" name="id2535441"></a>
+ <a class="indexterm" name="id2535448"></a>
+ <a class="indexterm" name="id2535455"></a>
+ 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
+ stored in the file <code class="filename">private/MACHINE.SID</code>. For all versions of Samba released since 2.2.5
+ the domain SID is stored in the file <code class="filename">private/secrets.tdb</code>. This file is unique to each
+ server and cannot be copied from a PDC to a BDC; the BDC will generate a new SID at startup. It will overwrite
+ the PDC domain SID with the newly created BDC SID. There is a procedure that will allow the BDC to aquire the
+ domain SID. This is described here.
+ </p><p>
+ <a class="indexterm" name="id2535486"></a>
+ <a class="indexterm" name="id2535493"></a>
+ <a class="indexterm" name="id2535499"></a>
+ <a class="indexterm" name="id2535506"></a>
+ <a class="indexterm" name="id2535512"></a>
+ To retrieve the domain SID from the PDC or an existing BDC and store it in the
+ <code class="filename">secrets.tdb</code>, execute:
+ </p><pre class="screen">
+<code class="prompt">root# </code><strong class="userinput"><code>net rpc getsid</code></strong>
+</pre></li><li><p>
+ <a class="indexterm" name="id2535553"></a>
+ <a class="indexterm" name="id2535559"></a>
+ <a class="indexterm" name="id2535566"></a>
+ Specification of the <a class="indexterm" name="id2535574"></a>ldap admin dn is obligatory.
+ This also requires the LDAP administration password to be set in the <code class="filename">secrets.tdb</code>
+ using the <span><strong class="command">smbpasswd -w <em class="replaceable"><code>mysecret</code></em></strong></span>.
+ </p></li><li><p>
+ The <a class="indexterm" name="id2535602"></a>ldap suffix parameter and the <a class="indexterm" name="id2535609"></a>ldap idmap suffix
+ parameter must be specified in the <code class="filename">smb.conf</code> file.
+ </p></li><li><p>
+ <a class="indexterm" name="id2535627"></a>
+ <a class="indexterm" name="id2535636"></a>
+ <a class="indexterm" name="id2535643"></a>
+ <a class="indexterm" name="id2535650"></a>
+ The UNIX user database has to be synchronized from the PDC to the
+ BDC. This means that both the <code class="filename">/etc/passwd</code> and
+ <code class="filename">/etc/group</code> have to be replicated from the PDC
+ to the BDC. This can be done manually whenever changes are made.
+ Alternately, the PDC is set up as an NIS master server and the BDC as an NIS slave
+ server. To set up the BDC as a mere NIS client would not be enough,
+ as the BDC would not be able to access its user database in case of
+ a PDC failure. NIS is by no means the only method to synchronize
+ passwords. An LDAP solution would also work.
+ </p></li><li><p>
+ <a class="indexterm" name="id2535683"></a>
+ <a class="indexterm" name="id2535690"></a>
+ <a class="indexterm" name="id2535697"></a>
+ <a class="indexterm" name="id2535703"></a>
+ <a class="indexterm" name="id2535710"></a>
+ <a class="indexterm" name="id2535716"></a>
+ <a class="indexterm" name="id2535723"></a>
+ <a class="indexterm" name="id2535730"></a>
+ The Samba password database must be replicated from the PDC to the BDC.
+ Although it is possible to synchronize the <code class="filename">smbpasswd</code>
+ file with <span><strong class="command">rsync</strong></span> and <span><strong class="command">ssh</strong></span>, this method
+ is broken and flawed, and is therefore not recommended. A better solution
+ is to set up slave LDAP servers for each BDC and a master LDAP server for the PDC.
+ The use of rsync is inherently flawed by the fact that the data will be replicated
+ at timed intervals. There is no guarantee that the BDC will be operating at all
+ times with correct and current machine and user account information. This means that
+ this method runs the risk of users being inconvenienced by discontinuity of access
+ to network services due to inconsistent security data. It must be born in mind that
+ Windows workstations update (change) the machine trust account password at regular
+ intervals administrators are not normally aware that this is happening
+ or when it takes place.
+ </p><p>
+ <a class="indexterm" name="id2535776"></a>
+ <a class="indexterm" name="id2535782"></a>
+ <a class="indexterm" name="id2535789"></a>
+ <a class="indexterm" name="id2535796"></a>
+ The use of LDAP for both the POSIX (UNIX user and group) accounts and for the
+ SambaSAMAccount data automatically ensures that all account change information
+ will be written to the shared directory. This eliminates the need for any special
+ action to synchronize account information because LDAP will meet that requirement.
+ </p></li><li><p>
+ <a class="indexterm" name="id2535813"></a>
+ <a class="indexterm" name="id2535820"></a>
+ <a class="indexterm" name="id2535827"></a>
+ <a class="indexterm" name="id2535833"></a>
+ <a class="indexterm" name="id2535840"></a>
+ <a class="indexterm" name="id2535846"></a>
+ The netlogon share has to be replicated from the PDC to the BDC. This can be done manually whenever login
+ scripts are changed, or it can be done automatically using a <span><strong class="command">cron</strong></span> job that will replicate
+ the directory structure in this share using a tool like <span><strong class="command">rsync</strong></span>. The use of
+ <span><strong class="command">rsync</strong></span> for replication of the netlogon data is not critical to network security and is one
+ that can be manually managed given that the administrator will make all changes to the netlogon share as part
+ of a conscious move.
+ </p></li></ul></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2535881"></a>Example Configuration</h3></div></div></div><p>
+Finally, the BDC has to be capable of being found by the workstations. This can be done by configuring the
+Samba <code class="filename">smb.conf</code> file <em class="parameter"><code>[global]</code></em> section as shown in <a href="samba-bdc.html#minim-bdc" title="Example 5.3. Minimal Setup for Being a BDC">Minimal
+Setup for Being a BDC</a>.
+</p><div class="example"><a name="minim-bdc"></a><p class="title"><b>Example 5.3. Minimal Setup for Being a BDC</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td><a class="indexterm" name="id2535927"></a><em class="parameter"><code>workgroup = MIDEARTH</code></em></td></tr><tr><td><a class="indexterm" name="id2535940"></a><em class="parameter"><code>passdb backend = ldapsam:ldap://slave-ldap.quenya.org</code></em></td></tr><tr><td><a class="indexterm" name="id2535953"></a><em class="parameter"><code>domain master = no</code></em></td></tr><tr><td><a class="indexterm" name="id2535966"></a><em class="parameter"><code>domain logons = yes</code></em></td></tr><tr><td><a class="indexterm" name="id2535979"></a><em class="parameter"><code>ldap suffix = dc=abmas,dc=biz</code></em></td></tr><tr><td><a class="indexterm" name="id2535992"></a><em class="parameter"><code>ldap user suffix = ou=Users</code></em></td></tr><tr><td><a class="indexterm" name="id2536005"></a><em class="parameter"><code>ldap group suffix = ou=Groups</code></em></td></tr><tr><td><a class="indexterm" name="id2536018"></a><em class="parameter"><code>ldap machine suffix = ou=Computers</code></em></td></tr><tr><td><a class="indexterm" name="id2536031"></a><em class="parameter"><code>ldap idmap suffix = ou=Idmap</code></em></td></tr><tr><td><a class="indexterm" name="id2536044"></a><em class="parameter"><code>ldap admin dn = cn=sambadmin,dc=quenya,dc=org</code></em></td></tr><tr><td><a class="indexterm" name="id2536057"></a><em class="parameter"><code>idmap backend = ldap:ldap://master-ldap.quenya.org</code></em></td></tr><tr><td><a class="indexterm" name="id2536071"></a><em class="parameter"><code>idmap uid = 10000-20000</code></em></td></tr><tr><td><a class="indexterm" name="id2536083"></a><em class="parameter"><code>idmap gid = 10000-20000</code></em></td></tr></table></div><p>
+Fully documented working example network configurations using OpenLDAP and Samba
+as available in the <a href="http://www.samba.org/samba/docs/Samba3-ByExample" target="_top">book</a> “<span class="quote">Samba-3
+by Example</span>” that may be obtained from local and on-line book stores.
+</p><p>
+<a class="indexterm" name="id2536116"></a>
+<a class="indexterm" name="id2536122"></a>
+<a class="indexterm" name="id2536129"></a>
+<a class="indexterm" name="id2536136"></a>
+This configuration causes the BDC to register only the name MIDEARTH<1C> with the WINS server. This is
+not a problem, as the name MIDEARTH<1C> is a NetBIOS group name that is meant to be registered by more
+than one machine. The parameter <a class="indexterm" name="id2536147"></a>domain master = no forces the BDC not to
+register MIDEARTH<1B>, which is a unique NetBIOS name that is reserved for the PDC.
+</p><p>
+<a class="indexterm" name="id2536164"></a>
+<a class="indexterm" name="id2536170"></a>
+<a class="indexterm" name="id2536177"></a>
+<a class="indexterm" name="id2536184"></a>
+<a class="indexterm" name="id2536191"></a>
+<a class="indexterm" name="id2536198"></a>
+<a class="indexterm" name="id2536204"></a>
+<a class="indexterm" name="id2536211"></a>
+<a class="indexterm" name="id2536217"></a>
+The <em class="parameter"><code>idmap backend</code></em> will redirect the <span><strong class="command">winbindd</strong></span> utility to use the LDAP
+database to store all mappings for Windows SIDs to UIDs and GIDs for UNIX accounts in a repository that is
+shared. The BDC will however depend on local resolution of UIDs and GIDs via NSS and the
+<span><strong class="command">nss_ldap</strong></span> utility.
+</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
+<a class="indexterm" name="id2536251"></a>
+<a class="indexterm" name="id2536260"></a>
+<a class="indexterm" name="id2536267"></a>
+<a class="indexterm" name="id2536274"></a>
+Samba-3 has introduced a new ID mapping facility. One of the features of this facility is that it
+allows greater flexibility in how user and group IDs are handled in respect to NT domain user and group
+SIDs. One of the new facilities provides for explicitly ensuring that UNIX/Linux UID and GID values
+will be consistent on the PDC, all BDCs, and all domain member servers. The parameter that controls this
+is called <em class="parameter"><code>idmap backend</code></em>. Please refer to the man page for <code class="filename">smb.conf</code> for more information
+regarding its behavior.
+</p></div><p>
+<a class="indexterm" name="id2536304"></a>
+<a class="indexterm" name="id2536311"></a>
+<a class="indexterm" name="id2536318"></a>
+The use of the <a class="indexterm" name="id2536325"></a>idmap backend = ldap:ldap://master.quenya.org
+option on a BDC only makes sense where ldapsam is used on a PDC. The purpose of an LDAP-based idmap backend is
+also to allow a domain member (without its own passdb backend) to use winbindd to resolve Windows network users
+and groups to common UID/GIDs. In other words, this option is generally intended for use on BDCs and on domain
+member servers.
+</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2536342"></a>Common Errors</h2></div></div></div><p>
+<a class="indexterm" name="id2536350"></a>
+Domain control was a new area for Samba, but there are now many examples that we may refer to.
+Updated information will be published as they become available and may be found in later Samba releases or
+from the Samba Web <a href="http://samba.org" target="_top">site</a>; refer in particular to the
+<code class="filename">WHATSNEW.txt</code> in the Samba release tarball. The book, “<span class="quote">Samba-3 by Example</span>”
+documents well tested and proven configuration examples. You can obtain a copy of this
+<a href="http://www.samba.org/samba/docs/Samba3-ByExample.pdf" target="_top">book</a> for the Samba web site.
+</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2536387"></a>Machine Accounts Keep Expiring</h3></div></div></div><p>
+<a class="indexterm" name="id2536395"></a>
+<a class="indexterm" name="id2536402"></a>
+<a class="indexterm" name="id2536409"></a>
+<a class="indexterm" name="id2536416"></a>
+This problem will occur when the passdb (SAM) files are copied from a central
+server but the local BDC is acting as a PDC. This results in the application of
+Local Machine Trust Account password updates to the local SAM. Such updates
+are not copied back to the central server. The newer machine account password is then
+overwritten when the SAM is recopied from the PDC. The result is that the domain member machine
+on startup will find that its passwords do not match the one now in the database, and
+since the startup security check will now fail, this machine will not allow logon attempts
+to proceed and the account expiry error will be reported.
+</p><p>
+The solution is to use a more robust passdb backend, such as the ldapsam backend, setting up
+a slave LDAP server for each BDC and a master LDAP server for the PDC.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2536442"></a>Can Samba Be a Backup Domain Controller to an NT4 PDC?</h3></div></div></div><p>
+<a class="indexterm" name="id2536451"></a>
+<a class="indexterm" name="id2536460"></a>
+No. The native NT4 SAM replication protocols have not yet been fully implemented.
+</p><p>
+<a class="indexterm" name="id2536471"></a>
+<a class="indexterm" name="id2536477"></a>
+<a class="indexterm" name="id2536484"></a>
+Can I get the benefits of a BDC with Samba? Yes, but only to a Samba PDC.The
+main reason for implementing a BDC is availability. If the PDC is a Samba
+machine, a second Samba machine can be set up to service logon requests whenever
+the PDC is down.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2536497"></a>How Do I Replicate the smbpasswd File?</h3></div></div></div><p>
+<a class="indexterm" name="id2536505"></a>
+<a class="indexterm" name="id2536514"></a>
+<a class="indexterm" name="id2536521"></a>
+Replication of the smbpasswd file is sensitive. It has to be done whenever changes
+to the SAM are made. Every user's password change is done in the smbpasswd file and
+has to be replicated to the BDC. So replicating the smbpasswd file very often is necessary.
+</p><p>
+<a class="indexterm" name="id2536535"></a>
+<a class="indexterm" name="id2536542"></a>
+<a class="indexterm" name="id2536549"></a>
+As the smbpasswd file contains plaintext password equivalents, it must not be
+sent unencrypted over the wire. The best way to set up smbpasswd replication from
+the PDC to the BDC is to use the utility rsync. rsync can use ssh as a transport.
+<span><strong class="command">ssh</strong></span> itself can be set up to accept <span class="emphasis"><em>only</em></span>
+<span><strong class="command">rsync</strong></span> transfer without requiring the user to type a password.
+</p><p>
+<a class="indexterm" name="id2536579"></a>
+<a class="indexterm" name="id2536586"></a>
+As said a few times before, use of this method is broken and flawed. Machine trust
+accounts will go out of sync, resulting in a broken domain. This method is
+<span class="emphasis"><em>not</em></span> recommended. Try using LDAP instead.
+</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2536602"></a>Can I Do This All with LDAP?</h3></div></div></div><p>
+<a class="indexterm" name="id2536610"></a>
+<a class="indexterm" name="id2536617"></a>
+The simple answer is yes. Samba's pdb_ldap code supports binding to a replica
+LDAP server and will also follow referrals and rebind to the master if it ever
+needs to make a modification to the database. (Normally BDCs are read-only, so
+this will not occur often).
+</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="samba-pdc.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="type.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="domain-member.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 4. Domain Control </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 6. Domain Membership</td></tr></table></div></body></html>
projects / samba / blobdiff