1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
|
<HTML
><HEAD
><TITLE
>How to Act as a Backup Domain Controller in a Purely Samba Controlled Domain</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD
><BODY
CLASS="ARTICLE"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="ARTICLE"
><DIV
CLASS="TITLEPAGE"
><H1
CLASS="TITLE"
><A
NAME="SAMBA-BDC"
>How to Act as a Backup Domain Controller in a Purely Samba Controlled Domain</A
></H1
><HR></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN3"
>Prerequisite Reading</A
></H1
><P
>Before you continue reading in this chapter, please make sure
that you are comfortable with configuring a Samba PDC
as described in the <A
HREF="Samba-PDC-HOWTO.html"
TARGET="_top"
>Samba-PDC-HOWTO</A
>.</P
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN7"
>Background</A
></H1
><P
>What is a Domain Controller? It is a machine that is able to answer
logon requests from workstations in a Windows NT Domain. Whenever a
user logs into a Windows NT Workstation, the workstation connects to a
Domain Controller and asks him whether the username and password the
user typed in is correct. The Domain Controller replies with a lot of
information about the user, for example the place where the users
profile is stored, the users full name of the user. All this
information is stored in the NT user database, the so-called SAM.</P
><P
>There are two kinds of Domain Controller in a NT 4 compatible Domain:
A Primary Domain Controller (PDC) and one or more Backup Domain
Controllers (BDC). The PDC contains the master copy of the
SAM. Whenever the SAM has to change, for example when a user changes
his password, this change has to be done on the PDC. A Backup Domain
Controller is a machine that maintains a read-only copy of the
SAM. This way it is able to reply to logon requests and authenticate
users in case the PDC is not available. During this time no changes to
the SAM are possible. Whenever changes to the SAM are done on the PDC,
all BDC receive the changes from the PDC.</P
><P
>Since version 2.2 Samba officially supports domain logons for all
current Windows Clients, including Windows 2000 and XP. This text
assumes the domain to be named SAMBA. To be able to act as a PDC, some
parameters in the [global]-section of the smb.conf have to be set:</P
><P
><PRE
CLASS="PROGRAMLISTING"
>[global]
workgroup = SAMBA
domain master = yes
domain logons = yes
encrypt passwords = yes
security = user
....</PRE
></P
><P
>Several other things like a [homes] and a [netlogon] share also may be
set along with settings for the profile path, the users home drive and
others. This will not be covered in this document.</P
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN15"
>What qualifies a Domain Controller on the network?</A
></H1
><P
>Every machine that is a Domain Controller for the domain SAMBA has to
register the NetBIOS group name SAMBA#1c with the WINS server and/or
by broadcast on the local network. The PDC also registers the unique
NetBIOS name SAMBA#1b with the WINS server. The name type #1b 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.</P
><DIV
CLASS="SECT2"
><HR><H2
CLASS="SECT2"
><A
NAME="AEN18"
>How does a Workstation find its domain controller?</A
></H2
><P
>A NT workstation in the domain SAMBA that wants a local user to be
authenticated has to find the domain controller for SAMBA. It does
this by doing a NetBIOS name query for the group name SAMBA#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 (TODO: How is the DC
chosen) domain controller authenticate each other. After that the
workstation sends the user's credentials (his name and password) to
the domain controller, asking for approval.</P
></DIV
><DIV
CLASS="SECT2"
><HR><H2
CLASS="SECT2"
><A
NAME="AEN21"
>When is the PDC needed?</A
></H2
><P
>Whenever a user wants to change his password, this has to be done on
the PDC. To find the PDC, the workstation does a NetBIOS name query
for SAMBA#1b, assuming this machine maintains the master copy of the
SAM. The workstation contacts the PDC, both mutually authenticate and
the password change is done.</P
></DIV
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN24"
>Can Samba be a Backup Domain Controller?</A
></H1
><P
>With version 2.2, no. The native NT SAM replication protocols have
not yet been fully implemented. The Samba Team is working on
understanding and implementing the protocols, but this work has not
been finished for version 2.2.</P
><P
>Can I get the benefits of a BDC with Samba? Yes. 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.</P
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN28"
>How do I set up a Samba BDC?</A
></H1
><P
>Several things have to be done:</P
><P
></P
><UL
><LI
><P
> The file <TT
CLASS="FILENAME"
>private/MACHINE.SID</TT
> identifies the domain. When a samba
server is first started, it is created on the fly and must never be
changed again. This file has to be the same on the PDC and the BDC,
so the MACHINE.SID has to be copied from the PDC to the BDC. Note that in the
latest Samba 2.2.x releases, the machine SID (and therefore domain SID) is stored
in the <TT
CLASS="FILENAME"
>private/secrets.tdb</TT
> database. This file cannot just
be copied because Samba looks under the key <TT
CLASS="CONSTANT"
>SECRETS/SID/<TT
CLASS="REPLACEABLE"
><I
>DOMAIN</I
></TT
></TT
>.
where <TT
CLASS="REPLACEABLE"
><I
>DOMAIN</I
></TT
> is the machine's netbios name. Since this name has
to be unique for each SAMBA server, this lookup will fail. </P
><P
> A new option has been added to the <B
CLASS="COMMAND"
>smbpasswd(8)</B
>
command to help ease this problem. When running <B
CLASS="COMMAND"
>smbpasswd -S</B
> as the root user,
the domain SID will be retrieved from a domain controller matching the value of the
<TT
CLASS="PARAMETER"
><I
>workgroup</I
></TT
> parameter in <TT
CLASS="FILENAME"
>smb.conf</TT
> and stored as the
new Samba server's machine SID. See the <A
HREF="smbpasswd.8.html"
TARGET="_top"
><B
CLASS="COMMAND"
>smbpasswd(8)</B
></A
>
man page for more details on this functionality.
</P
></LI
><LI
><P
> The Unix user database has to be synchronized from the PDC to the
BDC. This means that both the /etc/passwd and /etc/group have to be
replicated from the PDC to the BDC. This can be done manually
whenever changes are made, or the PDC is set up as a NIS master
server and the BDC as a 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. LDAP is also a
potential vehicle for sharing this information.
</P
></LI
><LI
><P
> The Samba password database in the file <TT
CLASS="FILENAME"
>private/smbpasswd</TT
>
has to be replicated from the PDC to the BDC. This is a bit tricky, see the
next section.
</P
></LI
><LI
><P
> Any 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 together with the smbpasswd
synchronization.
</P
></LI
></UL
><P
>Finally, the BDC has to be found by the workstations. This can be done
by setting</P
><P
><PRE
CLASS="PROGRAMLISTING"
>[global]
workgroup = SAMBA
domain master = yes
domain logons = yes
encrypt passwords = yes
security = user
....</PRE
></P
><P
>in the [global]-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 'domain master =
no' forces the BDC not to register SAMBA#1b which as a unique NetBIOS
name is reserved for the Primary Domain Controller.</P
><DIV
CLASS="SECT2"
><HR><H2
CLASS="SECT2"
><A
NAME="AEN57"
>How do I replicate the smbpasswd file?</A
></H2
><P
>Replication of the smbpasswd file is sensitive. It has to be done
whenever changes to the SAM are made. Every user's password change
(including machine trust account password changes) is done in the
smbpasswd file and has to be replicated to the BDC. So
replicating the smbpasswd file very often is necessary.</P
><P
>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
<B
CLASS="COMMAND"
>rsync(1)</B
>. <B
CLASS="COMMAND"
>rsync</B
> can use
<B
CLASS="COMMAND"
>ssh(1)</B
> as a transport. <B
CLASS="COMMAND"
>ssh</B
> itself
can be set up to accept <I
CLASS="EMPHASIS"
>only</I
> <B
CLASS="COMMAND"
>rsync</B
> transfer without requiring the user to
type a password. Refer to the man pages for these two tools for more details.</P
><P
>Another solution with high potential is to use Samba's <TT
CLASS="PARAMETER"
><I
>--with-ldapsam</I
></TT
>
for sharing and/or replicating the list of <TT
CLASS="CONSTANT"
>sambaAccount</TT
> entries.
This can all be done over SSL to ensure security. See the <A
HREF="Samba-LDAP-HOWTO.html"
TARGET="_top"
>Samba-LDAP-HOWTO</A
>
for more details.</P
></DIV
></DIV
></DIV
></BODY
></HTML
>
|
