summaryrefslogtreecommitdiff
path: root/docs/htmldocs/samba-bdc.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/htmldocs/samba-bdc.html')
-rw-r--r--docs/htmldocs/samba-bdc.html356
1 files changed, 0 insertions, 356 deletions
diff --git a/docs/htmldocs/samba-bdc.html b/docs/htmldocs/samba-bdc.html
deleted file mode 100644
index 13a35e5198..0000000000
--- a/docs/htmldocs/samba-bdc.html
+++ /dev/null
@@ -1,356 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 6. Backup Domain Control</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="type.html" title="Part II. Server Configuration Basics"><link rel="previous" href="samba-pdc.html" title="Chapter 5. Domain Control"><link rel="next" href="domain-member.html" title="Chapter 7. 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 6. 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 6. 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><tt class="email">&lt;<a href="mailto:jht@samba.org">jht@samba.org</a>&gt;</tt></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><tt class="email">&lt;<a href="mailto:Volker.Lendecke@SerNet.DE">Volker.Lendecke@SerNet.DE</a>&gt;</tt></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><tt class="email">&lt;<a href="mailto:gd@suse.de">gd@suse.de</a>&gt;</tt></p></div></div></div></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="samba-bdc.html#id2891162">Features and Benefits</a></dt><dt><a href="samba-bdc.html#id2891552">Essential Background Information</a></dt><dd><dl><dt><a href="samba-bdc.html#id2891580">MS Windows NT4-style Domain Control</a></dt><dt><a href="samba-bdc.html#id2891874">LDAP Configuration Notes</a></dt><dt><a href="samba-bdc.html#id2892094">Active Directory Domain Control</a></dt><dt><a href="samba-bdc.html#id2892115">What Qualifies a Domain Controller on the Network?</a></dt><dt><a href="samba-bdc.html#id2892157">How does a Workstation find its Domain Controller?</a></dt></dl></dd><dt><a href="samba-bdc.html#id2892268">Backup Domain Controller Configuration</a></dt><dd><dl><dt><a href="samba-bdc.html#id2892538">Example Configuration</a></dt></dl></dd><dt><a href="samba-bdc.html#id2892768">Common Errors</a></dt><dd><dl><dt><a href="samba-bdc.html#id2892791">Machine Accounts Keep Expiring</a></dt><dt><a href="samba-bdc.html#id2892845">Can Samba Be a Backup Domain Controller to an NT4 PDC?</a></dt><dt><a href="samba-bdc.html#id2892880">How Do I Replicate the smbpasswd File?</a></dt><dt><a href="samba-bdc.html#id2892948">Can I Do This All with LDAP?</a></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 <link linkend="samba-pdc">.
-</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2891162"></a>Features and Benefits</h2></div></div><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 <ulink url="mailto:jht@samba.org">John H. Terpstra</ulink>
-clearly setting out your requirements and/or question and we will do our best to provide a solution.
-</p><p>
-<a class="indexterm" name="id2891195"></a>
-Samba-3 is capable of acting 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. Do not use an LDAP slave server for a PDC, this may cause serious
-stability and operational problems.
-</p><p>
-<a class="indexterm" name="id2891221"></a>
-While it is possible to run a Samba-3 BDC with non-LDAP backend, the administrator will
-need to figure out precisely what is the best way to replicate (copy/distribute) the
-user and machine accounts' backend.
-</p><p>
-<a class="indexterm" name="id2891240"></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>
-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.
-<link linkend="pdc-bdc-table"> lists possible design configurations for a PDC/BDC infrastructure.
-<a class="indexterm" name="id2891281"></a>
-<a class="indexterm" name="id2891291"></a>
-<a class="indexterm" name="id2891302"></a>
-<a class="indexterm" name="id2891313"></a>
-</p><div class="table"><a name="pdc-bdc-table"></a><p class="title"><b>Table 6.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 fail-over ability. This is a useable solution, but not optimal.
- </p></td></tr><tr><td align="center"><p>tdbsam</p></td><td align="center"><p>tdbsam + <b class="command">net rpc vampire</b></p></td><td align="left"><p>
- Does not work with Samba-3.0.0; may be implemented in a later release. The downside of this solution
- is that an external process will control account database integrity. This solution may appeal to sites
- that wish to avoid the complexity of LDAP. The <b class="command">net rpc vampire</b> is used to
- synchronize domain accounts from the PDC to the BDC.
- </p></td></tr><tr><td align="center"><p>tdbsam</p></td><td align="center"><p>tdbsam + <b class="command">rsync</b></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.
- Use <b class="command">rsync</b> to synchronize the TDB database files from the PDC to the BDC.
- </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.
- Use <b class="command">rsync</b> to synchronize the TDB database files from the PDC to the BDC.
- Can be made to work using a <b class="command">cron</b> job to synchronize data from the PDC to the BDC.
- </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="id2891552"></a>Essential Background Information</h2></div></div><div></div></div><p>
-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>
-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="id2891580"></a>MS Windows NT4-style Domain Control</h3></div></div><div></div></div><p>
-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>
-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="id2891624"></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 <tt class="filename">C:\Windows NT\System32\config</tt> directory. These
-are the files that are involved in replication of the SAM database where Backup Domain
-Controllers are present on the network.
-</p><p>
-There are two situations in which it is desirable to install Backup Domain Controllers:
-</p><div class="itemizedlist"><ul type="disc"><li><p>
- On the local network that the Primary Domain Controller 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>
- At each remote site, to reduce wide area network traffic and to add stability to
- remote network operations. The design of the network, the strategic placement of
- Backup Domain Controllers, 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>
-The inter-operation of a PDC and its BDCs in a true Windows NT4 environemt 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>
-Samba-3 can not 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 inter-operate with a PDC (NT4 or Samba)
-to synchronize the SAM from delta files that are held by BDCs.
-</p><p>
-Samba-3 cannot function as a BDC to an MS Windows NT4 PDC, and Samba-3 can not
-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>
-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>
-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 on
-line, 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 can not be promoted
-in this manner because reconfiguration of Samba requires changes to the <tt class="filename">smb.conf</tt> file.
-</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2891756"></a>Example PDC Configuration</h4></div></div><div></div></div><p>
-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 <i class="parameter"><tt>[global]</tt></i>-section of the <tt class="filename">smb.conf</tt> have to be set.
-Refer to <link linkend="minimalPDC"> for an example of the minimum required settings.
-</p><div class="example"><a name="minimalPDC"></a><p class="title"><b>Example 6.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><i class="parameter"><tt>workgroup = MIDEARTH</tt></i></td></tr><tr><td><i class="parameter"><tt>passdb backend = ldapsam://localhost:389</tt></i></td></tr><tr><td><i class="parameter"><tt>domain master = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>domain logons = yes</tt></i></td></tr></table></div><p>
-Several other things like a <i class="parameter"><tt>[homes]</tt></i> and a
-<i class="parameter"><tt>[netlogon]</tt></i> 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 <link linkend="samba-pdc">.
-</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2891874"></a>LDAP Configuration Notes</h3></div></div><div></div></div><p>
-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>
-When configuring a master LDAP server that will have slave LDAP servers, do not forget to configure
-this in the <tt class="filename">/etc/openldap/slapd.conf</tt> 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>
-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 <tt class="filename">/etc/ssl/certs/slapd.pem</tt> must be the
-same as in <tt class="filename">/etc/openldap/sldap.conf</tt>. The Red Hat Linux startup script
-creates the <tt class="filename">slapd.pem</tt> file with hostname &#8220;<span class="quote">localhost.localdomain.</span>&#8221;
-It is impossible to access this LDAP server from a slave LDAP server (i.e., a Samba BDC) unless the
-certificate is recreated with a correct hostname.
-</p><p>
-Do not install a Samba PDC on a OpenLDAP 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 therfore 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.
-</p><p>
-Possible PDC/BDC plus LDAP configurations include:
-</p><div class="itemizedlist"><ul type="disc"><li><p>
- PDC+BDC -&gt; One Central LDAP Server.
- </p></li><li><p>
- PDC -&gt; LDAP master server, BDC -&gt; LDAP slave server.
- </p></li><li><p>
- PDC -&gt; LDAP master, with secondary slave LDAP server.
- </p><p>
- BDC -&gt; LDAP master, with secondary slave LDAP server.
- </p></li><li><p>
- PDC -&gt; LDAP master, with secondary slave LDAP server.
- </p><p>
- BDC -&gt; LDAP slave server, with secondary master LDAP server.
- </p></li></ul></div><p>
-In order to have a fall-back configuration (secondary) LDAP server one would specify
-the secondary LDAP server in the <tt class="filename">smb.conf</tt> file as shown in <link linkend="mulitldapcfg">.
-</p><p>
-</p><div class="example"><a name="mulitldapcfg"></a><p class="title"><b>Example 6.2. Multiple LDAP Servers in smb.conf</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td>...</td></tr><tr><td><i class="parameter"><tt>passdb backend = ldapsam:ldap://master.quenya.org</tt></i></td></tr><tr><td><i class="parameter"><tt>ldapsam:ldap://slave.quenya.org</tt></i></td></tr><tr><td>...</td></tr></table></div><p>
-</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2892094"></a>Active Directory Domain Control</h3></div></div><div></div></div><p>
-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 Backup Domain Controller to an Active Directory Domain Controller.
-</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2892115"></a>What Qualifies a Domain Controller on the Network?</h3></div></div><div></div></div><p>
-Every machine that is a Domain Controller for the domain MIDEARTH has to register the NetBIOS
-group name MIDEARTH&lt;#1c&gt; with the WINS server and/or by broadcast on the local network.
-The PDC also registers the unique NetBIOS name MIDEARTH&lt;#1b&gt; with the WINS server.
-The name type &lt;#1b&gt; name is normally reserved for the Domain Master Browser, a role
-that has nothing to do with anything related to authentication, but the Microsoft Domain
-implementation requires the Domain Master Browser to be on the same machine as the PDC.
-</p><p>
-Where a WINS server is not used, broadcast name registrations alone must suffice. Refer to
-<link linkend="netdiscuss"> 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="id2892157"></a>How does a Workstation find its Domain Controller?</h3></div></div><div></div></div><p>
-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>
-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
-<link linkend="adsdnstech">.
-</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2892189"></a>NetBIOS Over TCP/IP Enabled</h4></div></div><div></div></div><p>
-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&lt;#1c&gt;. 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="id2892201"></a>NetBIOS Over TCP/IP Disabled</h4></div></div><div></div></div><p>
-An MS Windows NT4/200x/XP Professional workstation in the realm <tt class="constant">quenya.org</tt>
-that has a need to affect user logon authentication will locate the Domain Controller by
-requerying DNS servers for the <tt class="constant">_ldap._tcp.pdc.ms-dcs.quenya.org</tt> record.
-More information regarding this subject may be found in <link linkend="adsdnstech">.
-</p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2892268"></a>Backup Domain Controller Configuration</h2></div></div><div></div></div><p>
-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 outlines as follows:
-<a class="indexterm" name="id2892289"></a>
-</p><div class="itemizedlist"><ul type="disc"><li><p>
- 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 <tt class="filename">private/MACHINE.SID</tt>.
- The domain SID is now stored in the file <tt class="filename">private/secrets.tdb</tt>. This file
- is unique to each server and can not be copied from a PDC to a BDC, the BDC will generate
- a new SID at start-up. It will over-write 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>
- To retrieve the domain SID from the PDC or an existing BDC and store it in the
- <tt class="filename">secrets.tdb</tt>, execute:
- </p><pre class="screen">
-<tt class="prompt">root# </tt><b class="userinput"><tt>net rpc getsid</tt></b>
-</pre></li><li><p>
- Specification of the <a class="indexterm" name="id2892368"></a><i class="parameter"><tt>ldap admin dn</tt></i> is obligatory.
- This also requires the LDAP administration password to be set in the <tt class="filename">secrets.tdb</tt>
- using the <b class="command">smbpasswd -w <i class="replaceable"><tt>mysecret</tt></i></b>.
- </p></li><li><p>
- Either <a class="indexterm" name="id2892405"></a><i class="parameter"><tt>ldap suffix</tt></i> or
- <a class="indexterm" name="id2892419"></a><i class="parameter"><tt>ldap idmap suffix</tt></i> must be specified in
- the <tt class="filename">smb.conf</tt> file.
- </p></li><li><p>
-<a class="indexterm" name="id2892446"></a>
- The UNIX user database has to be synchronized from the PDC to the
- BDC. This means that both the <tt class="filename">/etc/passwd</tt> and
- <tt class="filename">/etc/group</tt> 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>
- The Samba password database must be replicated from the PDC to the BDC.
- Although it is possible to synchronize the <tt class="filename">smbpasswd</tt>
- file with <b class="command">rsync</b> and <b class="command">ssh</b>, 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.
- </p></li><li><p>
- 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 <b class="command">cron</b> job
- that will replicate the directory structure in this share using a tool
- like <b class="command">rsync</b>.
- </p></li></ul></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2892538"></a>Example Configuration</h3></div></div><div></div></div><p>
-Finally, the BDC has to be found by the workstations. This can be done by setting Samba as shown in <link linkend="minim-bdc">.
-</p><div class="example"><a name="minim-bdc"></a><p class="title"><b>Example 6.3. Minimal setup for being a BDC</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>workgroup = MIDEARTH</tt></i></td></tr><tr><td><i class="parameter"><tt>passdb backend = ldapsam:ldap://slave-ldap.quenya.org</tt></i></td></tr><tr><td><i class="parameter"><tt>domain master = no</tt></i></td></tr><tr><td><i class="parameter"><tt>domain logons = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>idmap backend = ldapsam:ldap://slave-ldap.quenya.org</tt></i></td></tr></table></div><p>
-In the <i class="parameter"><tt>[global]</tt></i>-section of the <tt class="filename">smb.conf</tt> of the BDC. This makes the BDC
-only register the name SAMBA&lt;#1c&gt; with the WINS server. This is no
-problem as the name SAMBA&lt;#1c&gt; is a NetBIOS group name that is meant to
-be registered by more than one machine. The parameter
-<a class="indexterm" name="id2892643"></a><i class="parameter"><tt>domain master</tt></i> = no
-forces the BDC not to register SAMBA&lt;#1b&gt; which as a unique NetBIOS
-name is reserved for the Primary Domain Controller.
-</p><p>
-<a class="indexterm" name="id2892668"></a>
-<a class="indexterm" name="id2892677"></a>
-The <i class="parameter"><tt>idmap backend</tt></i> will redirect the <b class="command">winbindd</b> utility to
-use the LDAP database to resolve all UIDs and GIDs for UNIX accounts.
-</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
-<a class="indexterm" name="id2892706"></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 <i class="parameter"><tt>idmap backend</tt></i>. Please refer to the man page for <tt class="filename">smb.conf</tt> for more information
-regarding its behavior.
-</p></div><p>
-The use of the <a class="indexterm" name="id2892744"></a><i class="parameter"><tt>idmap backend</tt></i> = ldap://master.quenya/org
-option on a BDC only make sense where ldapsam is used on a PDC. The purpose for 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="id2892768"></a>Common Errors</h2></div></div><div></div></div><p>
-As this is a rather new area for Samba, there are not many examples that we may refer to.
-Updates will be published as they become available and may be found in later Samba releases or
-from the Samba web <ulink url="http://samba.org">site.</ulink>
-</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2892791"></a>Machine Accounts Keep Expiring</h3></div></div><div></div></div><p>
-<a class="indexterm" name="id2892802"></a>
-This problem will occur when the passdb (SAM) files are copied from a central
-server but the local Backup Domain Controller 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 over
-written when the SAM is re-copied from the PDC. The result is that the Domain Member machine
-on start up 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="id2892845"></a>Can Samba Be a Backup Domain Controller to an NT4 PDC?</h3></div></div><div></div></div><p>
-<a class="indexterm" name="id2892857"></a>
-No. The native NT4 SAM replication protocols have not yet been fully implemented.
-</p><p>
-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="id2892880"></a>How Do I Replicate the smbpasswd File?</h3></div></div><div></div></div><p>
-<a class="indexterm" name="id2892891"></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>
-As the smbpasswd file contains plain text 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.
-<b class="command">ssh</b> itself can be set up to accept <span class="emphasis"><em>only</em></span>
-<b class="command">rsync</b> transfer without requiring the user to type a password.
-</p><p>
-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="id2892948"></a>Can I Do This All with LDAP?</h3></div></div><div></div></div><p>
-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 5. 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 7. Domain Membership</td></tr></table></div></body></html>