Ignore:
Timestamp:
Nov 24, 2016, 1:14:11 PM (9 years ago)
Author:
Silvan Scherrer
Message:

Samba Server: update vendor to version 4.4.3

File:
1 edited

Legend:

Unmodified
Added
Removed
  • vendor/current/docs-xml/Samba3-HOWTO/TOSHARG-BDC.xml

    r414 r988  
    3434<indexterm><primary>LDAP</primary><secondary>slave</secondary></indexterm>
    3535<indexterm><primary>scalability</primary></indexterm>
    36 Samba-3 can act as a Backup Domain Controller (BDC) to another Samba Primary Domain Controller (PDC). A
    37 Samba-3 PDC can operate with an LDAP account backend. The LDAP backend can be either a common master LDAP
     36Samba can act as a Backup Domain Controller (BDC) to another Samba Primary Domain Controller (PDC). A
     37Samba PDC can operate with an LDAP account backend. The LDAP backend can be either a common master LDAP
    3838server or a slave server. The use of a slave LDAP server has the benefit that when the master is down, clients
    3939may still be able to log onto the network.  This effectively gives Samba a high degree of scalability and is
     
    4848<indexterm><primary>non-LDAP</primary><secondary>backend</secondary></indexterm>
    4949<indexterm><primary>propagate</primary></indexterm>
    50 While it is possible to run a Samba-3 BDC with a non-LDAP backend, that backend must allow some form of
     50It is not possible to run a Samba BDC with a non-LDAP backend, as that backend must allow some form of
    5151"two-way" propagation of changes from the BDC to the master.  At this time only LDAP delivers the capability
    5252to propagate identity database changes from the BDC to the PDC. The BDC can use a slave LDAP server, while it
    5353is preferable for the PDC to use as its primary an LDAP master server.
    5454</para>
    55 
    56 <para>
    57 <indexterm><primary>non-LDAP</primary><secondary>backend</secondary></indexterm>
    58 <indexterm><primary>SAM backend</primary><secondary>non-LDAP</secondary></indexterm>
    59 <indexterm><primary>domain</primary><secondary>member</secondary><tertiary>server</tertiary></indexterm>
    60 <indexterm><primary>BDC</primary></indexterm>
    61 <indexterm><primary>PDC</primary></indexterm>
    62 <indexterm><primary>trust account password</primary></indexterm>
    63 <indexterm><primary>domain trust</primary></indexterm>
    64 The use of a non-LDAP backend SAM database is particularly problematic because domain member
    65 servers and workstations periodically change the Machine Trust Account password. The new
    66 password is then stored only locally. This means that in the absence of a centrally stored
    67 accounts database (such as that provided with an LDAP-based solution) if Samba-3 is running
    68 as a BDC, the BDC instance of the domain member trust account password will not reach the
    69 PDC (master) copy of the SAM. If the PDC SAM is then replicated to BDCs, this results in
    70 overwriting the SAM that contains the updated (changed) trust account password with resulting
    71 breakage of the domain trust.
    72 </para>
    73 
    74 <para>
    75 <indexterm><primary>net</primary><secondary>rpc</secondary></indexterm>
    76 <indexterm><primary>SAM backend</primary><secondary>ldapsam</secondary></indexterm>
    77 <indexterm><primary>SAM backend</primary><secondary>tdbsam</secondary></indexterm>
    78 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
    79 Considering the number of comments and questions raised concerning how to configure a BDC,
    80 let's consider each possible option and look at the pros and cons for each possible solution.
    81 <link linkend="pdc-bdc-table">The Domain Backend Account Distribution Options table below</link> lists
    82 possible design configurations for a PDC/BDC infrastructure.
    83 </para>
    84 
    85 <table frame="all" id="pdc-bdc-table"><title>Domain Backend Account Distribution Options</title>
    86 <tgroup cols="3">
    87         <colspec align="center" colwidth="1*"/>
    88         <colspec align="center" colwidth="1*"/>
    89         <colspec align="left" colwidth="3*"/>
    90 
    91         <thead>
    92         <row><entry>PDC Backend</entry><entry>BDC Backend</entry><entry>Notes/Discussion</entry></row>
    93         </thead>
    94         <tbody>
    95         <row>
    96         <entry><para>Master LDAP Server</para></entry>
    97         <entry><para>Slave LDAP Server</para></entry>
    98         <entry><para>The optimal solution that provides high integrity. The SAM will be
    99                 replicated to a common master LDAP server.</para></entry>
    100         </row>
    101         <row>
    102         <entry><para>Single Central LDAP Server</para></entry>
    103         <entry><para>Single Central LDAP Server</para></entry>
    104         <entry><para>
    105         A workable solution without failover ability. This is a usable solution, but not optimal.
    106         </para></entry>
    107         </row>
    108         <row>
    109         <entry><para>tdbsam</para></entry>
    110         <entry><para>tdbsam + <command>net rpc vampire</command></para></entry>
    111         <entry><para>
    112         Does not work with Samba-3.0; Samba does not implement the
    113         server-side protocols required.
    114         </para></entry>
    115         </row>
    116         <row>
    117         <entry><para>tdbsam</para></entry>
    118         <entry><para>tdbsam + <command>rsync</command></para></entry>
    119         <entry><para>
    120         Do not use this configuration.
    121         Does not work because the TDB files are live and data may not
    122         have been flushed to disk.  Furthermore, this will cause
    123         domain trust breakdown.
    124         </para></entry>
    125         </row>
    126         <row>
    127         <entry><para>smbpasswd file</para></entry>
    128         <entry><para>smbpasswd file</para></entry>
    129         <entry><para>
    130         Do not use this configuration.
    131         Not an elegant solution due to the delays in synchronization
    132         and also suffers
    133         from the issue of domain trust breakdown.
    134         </para></entry>
    135         </row>
    136         </tbody>
    137 </tgroup>
    138 </table>
    13955
    14056</sect1>
     
    260176<indexterm><primary>PDC</primary></indexterm>
    261177<indexterm><primary>BDC</primary></indexterm>
    262 Samba-3 cannot participate in true SAM replication and is therefore not able to
    263 employ precisely the same protocols used by MS Windows NT4. A Samba-3 BDC will
     178Samba cannot participate in true SAM replication and is therefore not able to
     179employ precisely the same protocols used by MS Windows NT4. A Samba BDC will
    264180not create SAM update delta files. It will not interoperate with a PDC (NT4 or Samba)
    265181to synchronize the SAM from delta files that are held by BDCs.
     
    269185<indexterm><primary>PDC</primary></indexterm>
    270186<indexterm><primary>BDC</primary></indexterm>
    271 Samba-3 cannot function as a BDC to an MS Windows NT4 PDC, and Samba-3 cannot
    272 function correctly as a PDC to an MS Windows NT4 BDC. Both Samba-3 and MS Windows
     187Samba cannot function as a BDC to an MS Windows NT4 PDC, and Samba-3 cannot
     188function correctly as a PDC to an MS Windows NT4 BDC. Both Samba and MS Windows
    273189NT4 can function as a BDC to its own type of PDC.
    274190</para>
     
    293209be promoted to a PDC. If this happens while the original NT4 PDC is online, it is automatically demoted to an
    294210NT4 BDC. This is an important aspect of domain controller management. The tool that is used to effect a
    295 promotion or a demotion is the Server Manager for Domains. It should be noted that Samba-3 BDCs cannot be
     211promotion or a demotion is the Server Manager for Domains. It should be noted that Samba BDCs cannot be
    296212promoted in this manner because reconfiguration of Samba requires changes to the &smb.conf; file. It is easy
    297213enough to manuall change the &smb.conf; file and then restart relevant Samba network services.
     
    454370As of the release of MS Windows 2000 and Active Directory, this information is now stored
    455371in a directory that can be replicated and for which partial or full administrative control
    456 can be delegated. Samba-3 is not able to be a domain controller within an Active Directory
    457 tree, and it cannot be an Active Directory server. This means that Samba-3 also cannot
    458 act as a BDC to an Active Directory domain controller.
     372can be delegated. Samba-4.0 is able to be a domain controller within an Active Directory
     373tree, and it can be an Active Directory server.  The details for how
     374this can be done are documented in the <ulink
     375url="https://wiki.samba.org/index.php/Samba4/HOWTO">Samba 4.0 as an
     376AD DC HOWTO</ulink>
     377
    459378</para>
    460379
     
    554473
    555474<itemizedlist>
    556         <listitem><para>
    557         <indexterm><primary>SID</primary></indexterm>
    558         <indexterm><primary>PDC</primary></indexterm>
    559         <indexterm><primary>BDC</primary></indexterm>
    560         <indexterm><primary>private/secrets.tdb</primary></indexterm>
    561         <indexterm><primary>private/MACHINE.SID</primary></indexterm>
    562         <indexterm><primary>domain SID</primary></indexterm>
    563         The domain SID has to be the same on the PDC and the BDC. In Samba versions pre-2.2.5, the domain SID was
    564         stored in the file <filename>private/MACHINE.SID</filename>.  For all versions of Samba released since 2.2.5
    565         the domain SID is stored in the file <filename>private/secrets.tdb</filename>. This file is unique to each
    566         server and cannot be copied from a PDC to a BDC; the BDC will generate a new SID at startup. It will overwrite
    567         the PDC domain SID with the newly created BDC SID.  There is a procedure that will allow the BDC to acquire the
    568         domain SID. This is described here.
    569         </para>
    570 
    571         <para>
    572         <indexterm><primary>domain SID</primary></indexterm>
    573         <indexterm><primary>PDC</primary></indexterm>
    574         <indexterm><primary>BDC</primary></indexterm>
    575         <indexterm><primary>secrets.tdb</primary></indexterm>
    576         <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>getsid</tertiary></indexterm>
    577         To retrieve the domain SID from the PDC or an existing BDC and store it in the
    578         <filename>secrets.tdb</filename>, execute:
    579         </para>
    580 <screen>
    581 &rootprompt;<userinput>net rpc getsid</userinput>
    582 </screen>
    583         </listitem>
    584 
    585475        <listitem><para>
    586476        <indexterm><primary>secrets.tdb</primary></indexterm>
     
    624514        <indexterm><primary>LDAP</primary></indexterm>
    625515        The Samba password database must be replicated from the PDC to the BDC.
    626         Although it is possible to synchronize the <filename>smbpasswd</filename>
    627         file with <command>rsync</command> and <command>ssh</command>, this method
    628         is broken and flawed, and is therefore not recommended. A better solution
     516        The solution
    629517        is to set up slave LDAP servers for each BDC and a master LDAP server for the PDC.
    630518        The use of rsync is inherently flawed by the fact that the data will be replicated
     
    732620<indexterm><primary>domain member server</primary></indexterm>
    733621<indexterm><primary>idmap backend</primary></indexterm>
    734 Samba-3 has introduced a new ID mapping facility. One of the features of this facility is that it
     622Samba has introduced a new ID mapping facility. One of the features of this facility is that it
    735623allows greater flexibility in how user and group IDs are handled in respect to NT domain user and group
    736624SIDs. One of the new facilities provides for explicitly ensuring that UNIX/Linux UID and GID values
     
    805693<indexterm><primary>PDC</primary></indexterm>
    806694<indexterm><primary>logon requests</primary></indexterm>
    807 Can I get the benefits of a BDC with Samba?  Yes, but only to a Samba PDC.The
     695Can I get the benefits of a BDC with Samba?  Yes, but only to a Samba
     696PDC or as a <ulink
     697url="https://wiki.samba.org/index.php/Samba4/HOWTO">Samba 4.0 Active
     698Directory domain controller.</ulink>  The
    808699main reason for implementing a BDC is availability. If the PDC is a Samba
    809700machine, a second Samba machine can be set up to service logon requests whenever
     
    813704</sect2>
    814705
    815 <sect2>
    816 <title>How Do I Replicate the smbpasswd File?</title>
    817 
    818 <para>
    819 <indexterm><primary>replication</primary><secondary>SAM</secondary></indexterm>
    820 <indexterm><primary>smbpasswd</primary></indexterm>
    821 <indexterm><primary>SAM</primary></indexterm>
    822 Replication of the smbpasswd file is sensitive. It has to be done whenever changes
    823 to the SAM are made. Every user's password change is done in the smbpasswd file and
    824 has to be replicated to the BDC. So replicating the smbpasswd file very often is necessary.
    825 </para>
    826 
    827 <para>
    828 <indexterm><primary>plaintext password</primary></indexterm>
    829 <indexterm><primary>ssh</primary></indexterm>
    830 <indexterm><primary>rsync</primary></indexterm>
    831 As the smbpasswd file contains plaintext password equivalents, it must not be
    832 sent unencrypted over the wire. The best way to set up smbpasswd replication from
    833 the PDC to the BDC is to use the utility rsync. rsync can use ssh as a transport.
    834 <command>ssh</command> itself can be set up to accept <emphasis>only</emphasis>
    835 <command>rsync</command> transfer without requiring the user to type a password.
    836 </para>
    837 
    838 <para>
    839 <indexterm><primary>machine trust accounts</primary></indexterm>
    840 <indexterm><primary>LDAP</primary></indexterm>
    841 As said a few times before, use of this method is broken and flawed. Machine trust
    842 accounts will go out of sync, resulting in a broken domain. This method is
    843 <emphasis>not</emphasis> recommended. Try using LDAP instead.
    844 </para>
    845 
    846 </sect2>
    847 
    848 <sect2>
    849 <title>Can I Do This All with LDAP?</title>
    850 
    851 <para>
    852 <indexterm><primary>pdb_ldap</primary></indexterm>
    853 <indexterm><primary>LDAP</primary></indexterm>
    854 The simple answer is yes. Samba's pdb_ldap code supports binding to a replica
    855 LDAP server and will also follow referrals and rebind to the master if it ever
    856 needs to make a modification to the database. (Normally BDCs are read-only, so
    857 this will not occur often).
    858 </para>
    859 
    860 </sect2>
    861706</sect1>
    862707</chapter>
Note: See TracChangeset for help on using the changeset viewer.