docs/docbook/projdoc/Samba-BDC-HOWTO.sgml

   1 <chapter id="samba-bdc">
   2
   3 <chapterinfo>
   4         &author.vl;
   5         <pubdate> (26 Apr 2001) </pubdate>
   6 </chapterinfo>
   7
   8 <title>
   9 Samba Backup Domain Controller to Samba Domain Control
  10 </title>
  11
  12 <sect1>
  13 <title>Prerequisite Reading</title>
  14
  15 <para>
  16 Before you continue reading in this chapter, please make sure
  17 that you are comfortable with configuring a Samba PDC
  18 as described in the <ulink url="Samba-PDC-HOWTO.html">Samba-PDC-HOWTO</ulink>.
  19 </para>
  20
  21
  22 </sect1>
  23
  24 <sect1>
  25
  26 <title>Background</title>
  27
  28 <para>
  29 What is a Domain Controller? It is a machine that is able to answer
  30 logon requests from workstations in a Windows NT Domain. Whenever a
  31 user logs into a Windows NT Workstation, the workstation connects to a
  32 Domain Controller and asks him whether the username and password the
  33 user typed in is correct.  The Domain Controller replies with a lot of
  34 information about the user, for example the place where the users
  35 profile is stored, the users full name of the user. All this
  36 information is stored in the NT user database, the so-called SAM.
  37 </para>
  38
  39 <para>
  40 There are two kinds of Domain Controller in a NT 4 compatible Domain:
  41 A Primary Domain Controller (PDC) and one or more Backup Domain
  42 Controllers (BDC). The PDC contains the master copy of the
  43 SAM. Whenever the SAM has to change, for example when a user changes
  44 his password, this change has to be done on the PDC. A Backup Domain
  45 Controller is a machine that maintains a read-only copy of the
  46 SAM. This way it is able to reply to logon requests and authenticate
  47 users in case the PDC is not available. During this time no changes to
  48 the SAM are possible. Whenever changes to the SAM are done on the PDC,
  49 all BDC receive the changes from the PDC.
  50 </para>
  51
  52 <para>
  53 Since version 2.2 Samba officially supports domain logons for all
  54 current Windows Clients, including Windows 2000 and XP. This text
  55 assumes the domain to be named SAMBA. To be able to act as a PDC, some
  56 parameters in the [global]-section of the smb.conf have to be set:
  57 </para>
  58
  59 <para><programlisting>
  60         workgroup = SAMBA
  61         domain master = yes
  62         domain logons = yes
  63 </programlisting></para>
  64
  65 <para>
  66 Several other things like a [homes] and a [netlogon] share also may be
  67 set along with settings for the profile path, the users home drive and
  68 others. This will not be covered in this document.
  69 </para>
  70
  71 </sect1>
  72
  73
  74 <sect1>
  75 <title>What qualifies a Domain Controller on the network?</title>
  76
  77 <para>
  78 Every machine that is a Domain Controller for the domain SAMBA has to
  79 register the NetBIOS group name SAMBA#1c with the WINS server and/or
  80 by broadcast on the local network. The PDC also registers the unique
  81 NetBIOS name SAMBA#1b with the WINS server. The name type #1b is
  82 normally reserved for the domain master browser, a role that has
  83 nothing to do with anything related to authentication, but the
  84 Microsoft Domain implementation requires the domain master browser to
  85 be on the same machine as the PDC.
  86 </para>
  87
  88
  89 <sect2>
  90 <title>How does a Workstation find its domain controller?</title>
  91
  92 <para>
  93 A NT workstation in the domain SAMBA that wants a local user to be
  94 authenticated has to find the domain controller for SAMBA. It does
  95 this by doing a NetBIOS name query for the group name SAMBA#1c. It
  96 assumes that each of the machines it gets back from the queries is a
  97 domain controller and can answer logon requests. To not open security
  98 holes both the workstation and the selected (TODO: How is the DC
  99 chosen) domain controller authenticate each other. After that the
 100 workstation sends the user's credentials (his name and password) to
 101 the domain controller, asking for approval.
 102 </para>
 103
 104 </sect2>
 105
 106
 107 <sect2>
 108 <title>When is the PDC needed?</title>
 109
 110 <para>
 111 Whenever a user wants to change his password, this has to be done on
 112 the PDC. To find the PDC, the workstation does a NetBIOS name query
 113 for SAMBA#1b, assuming this machine maintains the master copy of the
 114 SAM. The workstation contacts the PDC, both mutually authenticate and
 115 the password change is done.
 116 </para>
 117
 118 </sect2>
 119
 120 </sect1>
 121
 122
 123 <sect1>
 124 <title>Can Samba be a Backup Domain Controller to an NT PDC?</title>
 125
 126 <para>
 127 With version 2.2, no. The native NT SAM replication protocols have
 128 not yet been fully implemented. The Samba Team is working on
 129 understanding and implementing the protocols, but this work has not
 130 been finished for version 2.2.
 131 </para>
 132
 133 <para>
 134 With version 3.0, the work on both the replication protocols and a
 135 suitable storage mechanism has progressed, and some form of NT4 BDC
 136 support is expected soon.
 137 </para>
 138
 139 <para>
 140 Can I get the benefits of a BDC with Samba?  Yes. The main reason for
 141 implementing a BDC is availability. If the PDC is a Samba machine,
 142 a second Samba machine can be set up to
 143 service logon requests whenever the PDC is down.
 144 </para>
 145
 146 </sect1>
 147
 148
 149 <sect1>
 150 <title>How do I set up a Samba BDC?</title>
 151
 152 <para>
 153 Several things have to be done:
 154 </para>
 155
 156 <itemizedlist>
 157
 158 <listitem><para>
 159 The domain SID has to be the same on the PDC and the BDC. This used to
 160 be stored in the file private/MACHINE.SID. This file is not created
 161 anymore since Samba 2.2.5 or even earlier. Nowadays the domain SID is
 162 stored in the file private/secrets.tdb. Simply copying the secrets.tdb
 163 from the PDC to the BDC does not work, as the BDC would
 164 generate a new SID for itself and override the domain SID with this
 165 new BDC SID.</para>
 166
 167 <para>
 168 To retrieve the domain SID from the PDC or an existing BDC and store it in the
 169 secrets.tdb, execute 'net rpc getsid' on the BDC.
 170 </para></listitem>
 171
 172 <listitem><para>
 173 The Unix user database has to be synchronized from the PDC to the
 174 BDC. This means that both the /etc/passwd and /etc/group have to be
 175 replicated from the PDC to the BDC. This can be done manually
 176 whenever changes are made, or the PDC is set up as a NIS master
 177 server and the BDC as a NIS slave server. To set up the BDC as a
 178 mere NIS client would not be enough, as the BDC would not be able to
 179 access its user database in case of a PDC failure.
 180 </para>
 181 </listitem>
 182
 183 <listitem><para>
 184 The Samba password database in the file private/smbpasswd has to be
 185 replicated from the PDC to the BDC. This is a bit tricky, see the
 186 next section.
 187 </para></listitem>
 188
 189 <listitem><para>
 190 Any netlogon share has to be replicated from the PDC to the
 191 BDC. This can be done manually whenever login scripts are changed,
 192 or it can be done automatically together with the smbpasswd
 193 synchronization.
 194 </para></listitem>
 195
 196 </itemizedlist>
 197
 198 <para>
 199 Finally, the BDC has to be found by the workstations. This can be done
 200 by setting
 201 </para>
 202
 203 <para><programlisting>
 204         workgroup = samba
 205         domain master = no
 206         domain logons = yes
 207 </programlisting></para>
 208
 209 <para>
 210 in the [global]-section of the smb.conf of the BDC. This makes the BDC
 211 only register the name SAMBA#1c with the WINS server. This is no
 212 problem as the name SAMBA#1c is a NetBIOS group name that is meant to
 213 be registered by more than one machine. The parameter 'domain master =
 214 no' forces the BDC not to register SAMBA#1b which as a unique NetBIOS
 215 name is reserved for the Primary Domain Controller.
 216 </para>
 217
 218 <sect2>
 219 <title>How do I replicate the smbpasswd file?</title>
 220
 221 <para>
 222 Replication of the smbpasswd file is sensitive. It has to be done
 223 whenever changes to the SAM are made. Every user's password change is
 224 done in the smbpasswd file and has to be replicated to the BDC. So
 225 replicating the smbpasswd file very often is necessary.
 226 </para>
 227
 228 <para>
 229 As the smbpasswd file contains plain text password equivalents, it
 230 must not be sent unencrypted over the wire. The best way to set up
 231 smbpasswd replication from the PDC to the BDC is to use the utility
 232 rsync. rsync can use ssh as a transport. ssh itself can be set up to
 233 accept *only* rsync transfer without requiring the user to type a
 234 password.
 235 </para>
 236
 237
 238 </sect2>
 239 <sect2>
 240 <title>Can I do this all with LDAP?</title>
 241 <para>The simple answer is YES.  Samba's pdb_ldap code supports
 242 binding to a replica LDAP server, and will also follow referrals and
 243 rebind to the master if it ever needs to make a modification to the
 244 database.  (Normally BDCs are read only, so this will not occur
 245 often).
 246 </para>
 247 </sect2>
 248
 249 </sect1>
 250 </chapter>