diff options
Diffstat (limited to 'docs/docbook/projdoc/Samba-BDC-HOWTO.xml')
| -rw-r--r-- | docs/docbook/projdoc/Samba-BDC-HOWTO.xml | 635 |
1 files changed, 0 insertions, 635 deletions
diff --git a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml b/docs/docbook/projdoc/Samba-BDC-HOWTO.xml deleted file mode 100644 index acdf284366..0000000000 --- a/docs/docbook/projdoc/Samba-BDC-HOWTO.xml +++ /dev/null @@ -1,635 +0,0 @@ -<chapter id="samba-bdc"> - -<chapterinfo> - &author.jht; - &author.vl; - <author>&person.gd;<contrib>LDAP updates</contrib></author> -</chapterinfo> - -<title>Backup Domain Control</title> - -<para> -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"/>. -</para> - -<sect1> -<title>Features and Benefits</title> - -<para> -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. -</para> - -<para> -<indexterm><primary>SAM backend</primary><secondary>LDAP</secondary></indexterm> -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. -</para> - -<para> -<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm> -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. -</para> - -<para> -<indexterm><primary>SAM backend</primary><secondary>non-LDAP</secondary></indexterm> -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. -</para> - -<para> -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. -<indexterm><primary>net</primary><secondary>rpc</secondary></indexterm> -<indexterm><primary>SAM backend</primary><secondary>ldapsam</secondary></indexterm> -<indexterm><primary>SAM backend</primary><secondary>tdbsam</secondary></indexterm> -<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm> -</para> - -<table frame="all" id="pdc-bdc-table"><title>Domain Backend Account Distribution Options</title> -<tgroup cols="3"> - <colspec align="center" colwidth="1*"/> - <colspec align="center" colwidth="1*"/> - <colspec align="left" colwidth="3*"/> - - <thead> - <row><entry>PDC Backend</entry><entry>BDC Backend</entry><entry>Notes/Discussion</entry></row> - </thead> - <tbody> - <row> - <entry><para>Master LDAP Server</para></entry> - <entry><para>Slave LDAP Server</para></entry> - <entry><para>The optimal solution that provides high integrity. The SAM will be - replicated to a common master LDAP server.</para></entry> - </row> - <row> - <entry><para>Single Central LDAP Server</para></entry> - <entry><para>Single Central LDAP Server</para></entry> - <entry><para> - A workable solution without fail-over ability. This is a useable solution, but not optimal. - </para></entry> - </row> - <row> - <entry><para>tdbsam</para></entry> - <entry><para>tdbsam + <command>net rpc vampire</command></para></entry> - <entry><para> - 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 <command>net rpc vampire</command> is used to - synchronize domain accounts from the PDC to the BDC. - </para></entry> - </row> - <row> - <entry><para>tdbsam</para></entry> - <entry><para>tdbsam + <command>rsync</command></para></entry> - <entry><para> - Do not use this configuration. - Does not work because the TDB files are live and data may not have been flushed to disk. - Use <command>rsync</command> to synchronize the TDB database files from the PDC to the BDC. - </para></entry> - </row> - <row> - <entry><para>smbpasswd file</para></entry> - <entry><para>smbpasswd file</para></entry> - <entry><para> - Do not use this configuration. - Not an elegant solution due to the delays in synchronization. - Use <command>rsync</command> to synchronize the TDB database files from the PDC to the BDC. - Can be made to work using a <command>cron</command> job to synchronize data from the PDC to the BDC. - </para></entry> - </row> - </tbody> -</tgroup> -</table> - -</sect1> - -<sect1> -<title>Essential Background Information</title> - -<para> -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. -</para> - -<para> -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. -</para> - -<sect2> -<title>MS Windows NT4-style Domain Control</title> - -<para> -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. -</para> - -<para> -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). -</para> - -<para> -<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm> -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 <filename>C:\Windows NT\System32\config</filename> directory. These -are the files that are involved in replication of the SAM database where Backup Domain -Controllers are present on the network. -</para> - -<para> -There are two situations in which it is desirable to install Backup Domain Controllers: -</para> - -<itemizedlist> - <listitem><para> - 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. - </para></listitem> - - <listitem><para> - 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). - </para></listitem> -</itemizedlist> - -<para> -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. -</para> - -<para> -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. -</para> - -<para> -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. -</para> - -<para> -The BDC is said to hold a <emphasis>read-only</emphasis> 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. -</para> - -<para> -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 &smb.conf; file. -</para> - -<sect3> -<title>Example PDC Configuration</title> - -<para> -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 <smbconfsection>[global]</smbconfsection>-section of the &smb.conf; have to be set. -Refer to <link linkend="minimalPDC"/> for an example of the minimum required settings. -</para> - -<para><smbconfexample id="minimalPDC"> -<title>Minimal smb.conf for a PDC in Use With a BDC &smbmdash; LDAP Server on PDC.</title> -<smbconfoption><name>workgroup</name><value>&example.workgroup;</value></smbconfoption> -<smbconfoption><name>passdb backend</name><value>ldapsam://localhost:389</value></smbconfoption> -<smbconfoption><name>domain master</name><value>yes</value></smbconfoption> -<smbconfoption><name>domain logons</name><value>yes</value></smbconfoption> -</smbconfexample></para> - -<para> -Several other things like a <smbconfsection>[homes]</smbconfsection> and a -<smbconfsection>[netlogon]</smbconfsection> 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"></link>. -</para> - -</sect3> -</sect2> - -<sect2> -<title>LDAP Configuration Notes</title> - -<para> -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. -</para> - -<para> -When configuring a master LDAP server that will have slave LDAP servers, do not forget to configure -this in the <filename>/etc/openldap/slapd.conf</filename> 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. -</para> - -<para> -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 <filename>/etc/ssl/certs/slapd.pem</filename> must be the -same as in <filename>/etc/openldap/sldap.conf</filename>. The Red Hat Linux startup script -creates the <filename>slapd.pem</filename> file with hostname <quote>localhost.localdomain.</quote> -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. -</para> - -<para> -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. -</para> - -<para> -Possible PDC/BDC plus LDAP configurations include: -</para> - -<itemizedlist> - <listitem><para> - PDC+BDC -> One Central LDAP Server. - </para></listitem> - <listitem><para> - PDC -> LDAP master server, BDC -> LDAP slave server. - </para></listitem> - <listitem><para> - PDC -> LDAP master, with secondary slave LDAP server. - </para><para> - BDC -> LDAP master, with secondary slave LDAP server. - </para></listitem> - <listitem><para> - PDC -> LDAP master, with secondary slave LDAP server. - </para><para> - BDC -> LDAP slave server, with secondary master LDAP server. - </para></listitem> -</itemizedlist> - -<para> -In order to have a fall-back configuration (secondary) LDAP server one would specify -the secondary LDAP server in the &smb.conf; file as shown in <link linkend="mulitldapcfg"/>. -</para> - -<para> -<smbconfexample id="mulitldapcfg"> -<title>Multiple LDAP Servers in &smb.conf;</title> -<member>...</member> -<smbconfoption><name>passdb backend</name><value>ldapsam:ldap://master.quenya.org</value></smbconfoption> -<member><parameter>ldapsam:ldap://slave.quenya.org</parameter></member> -<member>...</member> -</smbconfexample> -</para> - -</sect2> - -<sect2> -<title>Active Directory Domain Control</title> - -<para> -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. -</para> - -</sect2> - -<sect2> -<title>What Qualifies a Domain Controller on the Network?</title> - -<para> -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, 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. -</para> - -<para> -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. -</para> - -</sect2> - -<sect2> -<title>How does a Workstation find its Domain Controller?</title> - -<para> -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. -</para> - -<para> -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"/>. -</para> - -<sect3> -<title>NetBIOS Over TCP/IP Enabled</title> -<para> -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. -</para> - -</sect3> - -<sect3> -<title>NetBIOS Over TCP/IP Disabled</title> - -<para> -An MS Windows NT4/200x/XP Professional workstation in the realm <constant>quenya.org</constant> -that has a need to affect user logon authentication will locate the Domain Controller by -requerying DNS servers for the <constant>_ldap._tcp.pdc.ms-dcs.quenya.org</constant> record. -More information regarding this subject may be found in <link linkend="adsdnstech"/>. -</para> - -</sect3> -</sect2> -</sect1> - -<sect1> -<title>Backup Domain Controller Configuration</title> - -<para> -The creation of a BDC requires some steps to prepare the Samba server before -&smbd; is executed for the first time. These steps are outlines as follows: -<indexterm><primary>SID</primary></indexterm> -</para> - -<itemizedlist> -<listitem><para> - 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 <filename>private/MACHINE.SID</filename>. - The domain SID is now stored in the file <filename>private/secrets.tdb</filename>. 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. - </para> - - <para> - To retrieve the domain SID from the PDC or an existing BDC and store it in the - <filename>secrets.tdb</filename>, execute: - </para> -<screen> -&rootprompt;<userinput>net rpc getsid</userinput> -</screen> - </listitem> - - <listitem><para> - Specification of the <smbconfoption><name>ldap admin dn</name></smbconfoption> is obligatory. - This also requires the LDAP administration password to be set in the <filename>secrets.tdb</filename> - using the <command>smbpasswd -w <replaceable>mysecret</replaceable></command>. - </para></listitem> - - <listitem><para> - Either <smbconfoption><name>ldap suffix</name></smbconfoption> or - <smbconfoption><name>ldap idmap suffix</name></smbconfoption> must be specified in - the &smb.conf; file. - </para></listitem> - - <listitem><para> -<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm> - The UNIX user database has to be synchronized from the PDC to the - BDC. This means that both the <filename>/etc/passwd</filename> and - <filename>/etc/group</filename> 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. - </para> - </listitem> - - <listitem><para> - The Samba password database must be replicated from the PDC to the BDC. - Although it is possible to synchronize the <filename>smbpasswd</filename> - file with <command>rsync</command> and <command>ssh</command>, 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. - </para></listitem> - - <listitem><para> - 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 <command>cron</command> job - that will replicate the directory structure in this share using a tool - like <command>rsync</command>. - </para></listitem> - -</itemizedlist> - -<sect2> -<title>Example Configuration</title> - -<para> -Finally, the BDC has to be found by the workstations. This can be done by setting Samba as shown in <link linkend="minim-bdc"/>. -</para> - -<para><smbconfexample id="minim-bdc"> -<title>Minimal setup for being a BDC</title> -<smbconfoption><name>workgroup</name><value>&example.workgroup;</value></smbconfoption> -<smbconfoption><name>passdb backend</name><value>ldapsam:ldap://slave-ldap.quenya.org</value></smbconfoption> -<smbconfoption><name>domain master</name><value>no</value></smbconfoption> -<smbconfoption><name>domain logons</name><value>yes</value></smbconfoption> -<smbconfoption><name>idmap backend</name><value>ldapsam:ldap://slave-ldap.quenya.org</value></smbconfoption> -</smbconfexample></para> - -<para> -In the <smbconfsection>[global]</smbconfsection>-section of the &smb.conf; of the BDC. This makes the BDC -only register the name SAMBA<#1c> with the WINS server. This is no -problem as the name SAMBA<#1c> is a NetBIOS group name that is meant to -be registered by more than one machine. The parameter -<smbconfoption><name>domain master</name><value>no</value></smbconfoption> -forces the BDC not to register <?latex \linebreak ?>SAMBA<#1b> which as a unique NetBIOS -name is reserved for the Primary Domain Controller. -</para> - -<para> -<indexterm><primary>idmap backend</primary></indexterm> -<indexterm><primary>winbindd</primary></indexterm> -The <parameter>idmap backend</parameter> will redirect the <command>winbindd</command> utility to -use the LDAP database to resolve all UIDs and GIDs for UNIX accounts. -</para> - -<note><para> -<indexterm><primary>Server Type</primary><secondary>Domain Member</secondary></indexterm> -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 <parameter>idmap backend</parameter>. Please refer to the man page for &smb.conf; for more information -regarding its behavior. -</para></note> - -<para> -The use of the <smbconfoption><name>idmap backend</name><value>ldap://master.quenya/org</value></smbconfoption> -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. -</para> - -</sect2> -</sect1> - -<sect1> -<title>Common Errors</title> - -<para> -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> -</para> - -<sect2> -<title>Machine Accounts Keep Expiring</title> - -<para> -<indexterm><primary>Machine Trust Accounts</primary></indexterm> -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. -</para> - -<para> -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. -</para> - -</sect2> - -<sect2> -<title>Can Samba Be a Backup Domain Controller to an NT4 PDC?</title> - -<para> -<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm> -No. The native NT4 SAM replication protocols have not yet been fully implemented. -</para> - -<para> -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. -</para> - -</sect2> - -<sect2> -<title>How Do I Replicate the smbpasswd File?</title> - -<para> -<indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm> -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. -</para> - -<para> -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. -<command>ssh</command> itself can be set up to accept <emphasis>only</emphasis> -<command>rsync</command> transfer without requiring the user to type a password. -</para> - -<para> -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 -<emphasis>not</emphasis> recommended. Try using LDAP instead. -</para> - -</sect2> - -<sect2> -<title>Can I Do This All with LDAP?</title> - -<para> -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). -</para> - -</sect2> -</sect1> -</chapter> |