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

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