Changeset 988 for vendor/current/docs-xml/Samba3-HOWTO/TOSHARG-BDC.xml
- Timestamp:
- Nov 24, 2016, 1:14:11 PM (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
vendor/current/docs-xml/Samba3-HOWTO/TOSHARG-BDC.xml
r414 r988 34 34 <indexterm><primary>LDAP</primary><secondary>slave</secondary></indexterm> 35 35 <indexterm><primary>scalability</primary></indexterm> 36 Samba -3can act as a Backup Domain Controller (BDC) to another Samba Primary Domain Controller (PDC). A37 Samba -3PDC can operate with an LDAP account backend. The LDAP backend can be either a common master LDAP36 Samba can act as a Backup Domain Controller (BDC) to another Samba Primary Domain Controller (PDC). A 37 Samba PDC can operate with an LDAP account backend. The LDAP backend can be either a common master LDAP 38 38 server or a slave server. The use of a slave LDAP server has the benefit that when the master is down, clients 39 39 may still be able to log onto the network. This effectively gives Samba a high degree of scalability and is … … 48 48 <indexterm><primary>non-LDAP</primary><secondary>backend</secondary></indexterm> 49 49 <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 of50 It is not possible to run a Samba BDC with a non-LDAP backend, as that backend must allow some form of 51 51 "two-way" propagation of changes from the BDC to the master. At this time only LDAP delivers the capability 52 52 to propagate identity database changes from the BDC to the PDC. The BDC can use a slave LDAP server, while it 53 53 is preferable for the PDC to use as its primary an LDAP master server. 54 54 </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 member65 servers and workstations periodically change the Machine Trust Account password. The new66 password is then stored only locally. This means that in the absence of a centrally stored67 accounts database (such as that provided with an LDAP-based solution) if Samba-3 is running68 as a BDC, the BDC instance of the domain member trust account password will not reach the69 PDC (master) copy of the SAM. If the PDC SAM is then replicated to BDCs, this results in70 overwriting the SAM that contains the updated (changed) trust account password with resulting71 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> lists82 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 be99 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 the113 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 not122 have been flushed to disk. Furthermore, this will cause123 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 synchronization132 and also suffers133 from the issue of domain trust breakdown.134 </para></entry>135 </row>136 </tbody>137 </tgroup>138 </table>139 55 140 56 </sect1> … … 260 176 <indexterm><primary>PDC</primary></indexterm> 261 177 <indexterm><primary>BDC</primary></indexterm> 262 Samba -3cannot participate in true SAM replication and is therefore not able to263 employ precisely the same protocols used by MS Windows NT4. A Samba -3BDC will178 Samba cannot participate in true SAM replication and is therefore not able to 179 employ precisely the same protocols used by MS Windows NT4. A Samba BDC will 264 180 not create SAM update delta files. It will not interoperate with a PDC (NT4 or Samba) 265 181 to synchronize the SAM from delta files that are held by BDCs. … … 269 185 <indexterm><primary>PDC</primary></indexterm> 270 186 <indexterm><primary>BDC</primary></indexterm> 271 Samba -3cannot function as a BDC to an MS Windows NT4 PDC, and Samba-3 cannot272 function correctly as a PDC to an MS Windows NT4 BDC. Both Samba -3and MS Windows187 Samba cannot function as a BDC to an MS Windows NT4 PDC, and Samba-3 cannot 188 function correctly as a PDC to an MS Windows NT4 BDC. Both Samba and MS Windows 273 189 NT4 can function as a BDC to its own type of PDC. 274 190 </para> … … 293 209 be promoted to a PDC. If this happens while the original NT4 PDC is online, it is automatically demoted to an 294 210 NT4 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 -3BDCs cannot be211 promotion or a demotion is the Server Manager for Domains. It should be noted that Samba BDCs cannot be 296 212 promoted in this manner because reconfiguration of Samba requires changes to the &smb.conf; file. It is easy 297 213 enough to manuall change the &smb.conf; file and then restart relevant Samba network services. … … 454 370 As of the release of MS Windows 2000 and Active Directory, this information is now stored 455 371 in 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. 372 can be delegated. Samba-4.0 is able to be a domain controller within an Active Directory 373 tree, and it can be an Active Directory server. The details for how 374 this can be done are documented in the <ulink 375 url="https://wiki.samba.org/index.php/Samba4/HOWTO">Samba 4.0 as an 376 AD DC HOWTO</ulink> 377 459 378 </para> 460 379 … … 554 473 555 474 <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 was564 stored in the file <filename>private/MACHINE.SID</filename>. For all versions of Samba released since 2.2.5565 the domain SID is stored in the file <filename>private/secrets.tdb</filename>. This file is unique to each566 server and cannot be copied from a PDC to a BDC; the BDC will generate a new SID at startup. It will overwrite567 the PDC domain SID with the newly created BDC SID. There is a procedure that will allow the BDC to acquire the568 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 the578 <filename>secrets.tdb</filename>, execute:579 </para>580 <screen>581 &rootprompt;<userinput>net rpc getsid</userinput>582 </screen>583 </listitem>584 585 475 <listitem><para> 586 476 <indexterm><primary>secrets.tdb</primary></indexterm> … … 624 514 <indexterm><primary>LDAP</primary></indexterm> 625 515 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 629 517 is to set up slave LDAP servers for each BDC and a master LDAP server for the PDC. 630 518 The use of rsync is inherently flawed by the fact that the data will be replicated … … 732 620 <indexterm><primary>domain member server</primary></indexterm> 733 621 <indexterm><primary>idmap backend</primary></indexterm> 734 Samba -3has introduced a new ID mapping facility. One of the features of this facility is that it622 Samba has introduced a new ID mapping facility. One of the features of this facility is that it 735 623 allows greater flexibility in how user and group IDs are handled in respect to NT domain user and group 736 624 SIDs. One of the new facilities provides for explicitly ensuring that UNIX/Linux UID and GID values … … 805 693 <indexterm><primary>PDC</primary></indexterm> 806 694 <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 695 Can I get the benefits of a BDC with Samba? Yes, but only to a Samba 696 PDC or as a <ulink 697 url="https://wiki.samba.org/index.php/Samba4/HOWTO">Samba 4.0 Active 698 Directory domain controller.</ulink> The 808 699 main reason for implementing a BDC is availability. If the PDC is a Samba 809 700 machine, a second Samba machine can be set up to service logon requests whenever … … 813 704 </sect2> 814 705 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 changes823 to the SAM are made. Every user's password change is done in the smbpasswd file and824 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 be832 sent unencrypted over the wire. The best way to set up smbpasswd replication from833 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 trust842 accounts will go out of sync, resulting in a broken domain. This method is843 <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 replica855 LDAP server and will also follow referrals and rebind to the master if it ever856 needs to make a modification to the database. (Normally BDCs are read-only, so857 this will not occur often).858 </para>859 860 </sect2>861 706 </sect1> 862 707 </chapter>
Note:
See TracChangeset
for help on using the changeset viewer.