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
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
|
<HTML
><HEAD
><TITLE
>LanMan and NT Password Encryption in Samba 2.x</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="PWENCRYPT"
>LanMan and NT Password Encryption in Samba 2.x</A
></H1
><HR></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN3"
>Introduction</A
></H1
><P
>With the development of LanManager and Windows NT
compatible password encryption for Samba, it is now able
to validate user connections in exactly the same way as
a LanManager or Windows NT server.</P
><P
>This document describes how the SMB password encryption
algorithm works and what issues there are in choosing whether
you want to use it. You should read it carefully, especially
the part about security and the "PROS and CONS" section.</P
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN7"
>How does it work?</A
></H1
><P
>LanManager encryption is somewhat similar to UNIX
password encryption. The server uses a file containing a
hashed value of a user's password. This is created by taking
the user's plaintext password, capitalising it, and either
truncating to 14 bytes or padding to 14 bytes with null bytes.
This 14 byte value is used as two 56 bit DES keys to encrypt
a 'magic' eight byte value, forming a 16 byte value which is
stored by the server and client. Let this value be known as
the "hashed password".</P
><P
>Windows NT encryption is a higher quality mechanism,
consisting of doing an MD4 hash on a Unicode version of the user's
password. This also produces a 16 byte hash value that is
non-reversible.</P
><P
>When a client (LanManager, Windows for WorkGroups, Windows
95 or Windows NT) wishes to mount a Samba drive (or use a Samba
resource), it first requests a connection and negotiates the
protocol that the client and server will use. In the reply to this
request the Samba server generates and appends an 8 byte, random
value - this is stored in the Samba server after the reply is sent
and is known as the "challenge". The challenge is different for
every client connection.</P
><P
>The client then uses the hashed password (16 byte values
described above), appended with 5 null bytes, as three 56 bit
DES keys, each of which is used to encrypt the challenge 8 byte
value, forming a 24 byte value known as the "response".</P
><P
>In the SMB call SMBsessionsetupX (when user level security
is selected) or the call SMBtconX (when share level security is
selected), the 24 byte response is returned by the client to the
Samba server. For Windows NT protocol levels the above calculation
is done on both hashes of the user's password and both responses are
returned in the SMB call, giving two 24 byte values.</P
><P
>The Samba server then reproduces the above calculation, using
its own stored value of the 16 byte hashed password (read from the
<TT
CLASS="FILENAME"
>smbpasswd</TT
> file - described later) and the challenge
value that it kept from the negotiate protocol reply. It then checks
to see if the 24 byte value it calculates matches the 24 byte value
returned to it from the client.</P
><P
>If these values match exactly, then the client knew the
correct password (or the 16 byte hashed value - see security note
below) and is thus allowed access. If not, then the client did not
know the correct password and is denied access.</P
><P
>Note that the Samba server never knows or stores the cleartext
of the user's password - just the 16 byte hashed values derived from
it. Also note that the cleartext password or 16 byte hashed values
are never transmitted over the network - thus increasing security.</P
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN18"
>Important Notes About Security</A
></H1
><P
>The unix and SMB password encryption techniques seem similar
on the surface. This similarity is, however, only skin deep. The unix
scheme typically sends clear text passwords over the network when
logging in. This is bad. The SMB encryption scheme never sends the
cleartext password over the network but it does store the 16 byte
hashed values on disk. This is also bad. Why? Because the 16 byte hashed
values are a "password equivalent". You cannot derive the user's
password from them, but they could potentially be used in a modified
client to gain access to a server. This would require considerable
technical knowledge on behalf of the attacker but is perfectly possible.
You should thus treat the smbpasswd file as though it contained the
cleartext passwords of all your users. Its contents must be kept
secret, and the file should be protected accordingly.</P
><P
>Ideally we would like a password scheme which neither requires
plain text passwords on the net or on disk. Unfortunately this
is not available as Samba is stuck with being compatible with
other SMB systems (WinNT, WfWg, Win95 etc). </P
><DIV
CLASS="WARNING"
><P
></P
><TABLE
CLASS="WARNING"
BORDER="1"
WIDTH="100%"
><TR
><TD
ALIGN="CENTER"
><B
>Warning</B
></TD
></TR
><TR
><TD
ALIGN="LEFT"
><P
>Note that Windows NT 4.0 Service pack 3 changed the
default for permissible authentication so that plaintext
passwords are <I
CLASS="EMPHASIS"
>never</I
> sent over the wire.
The solution to this is either to switch to encrypted passwords
with Samba or edit the Windows NT registry to re-enable plaintext
passwords. See the document WinNT.txt for details on how to do
this.</P
><P
>Other Microsoft operating systems which also exhibit
this behavior includes</P
><P
></P
><UL
><LI
><P
>MS DOS Network client 3.0 with
the basic network redirector installed</P
></LI
><LI
><P
>Windows 95 with the network redirector
update installed</P
></LI
><LI
><P
>Windows 98 [se]</P
></LI
><LI
><P
>Windows 2000</P
></LI
></UL
><P
><I
CLASS="EMPHASIS"
>Note :</I
>All current release of
Microsoft SMB/CIFS clients support authentication via the
SMB Challenge/Response mechanism described here. Enabling
clear text authentication does not disable the ability
of the client to participate in encrypted authentication.</P
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="SECT2"
><HR><H2
CLASS="SECT2"
><A
NAME="AEN37"
>Advantages of SMB Encryption</A
></H2
><P
></P
><UL
><LI
><P
>plain text passwords are not passed across
the network. Someone using a network sniffer cannot just
record passwords going to the SMB server.</P
></LI
><LI
><P
>WinNT doesn't like talking to a server
that isn't using SMB encrypted passwords. It will refuse
to browse the server if the server is also in user level
security mode. It will insist on prompting the user for the
password on each connection, which is very annoying. The
only things you can do to stop this is to use SMB encryption.
</P
></LI
></UL
></DIV
><DIV
CLASS="SECT2"
><HR><H2
CLASS="SECT2"
><A
NAME="AEN44"
>Advantages of non-encrypted passwords</A
></H2
><P
></P
><UL
><LI
><P
>plain text passwords are not kept
on disk. </P
></LI
><LI
><P
>uses same password file as other unix
services such as login and ftp</P
></LI
><LI
><P
>you are probably already using other
services (such as telnet and ftp) which send plain text
passwords over the net, so sending them for SMB isn't
such a big deal.</P
></LI
></UL
></DIV
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN53"
><A
NAME="SMBPASSWDFILEFORMAT"
></A
>The smbpasswd file</A
></H1
><P
>In order for Samba to participate in the above protocol
it must be able to look up the 16 byte hashed values given a user name.
Unfortunately, as the UNIX password value is also a one way hash
function (ie. it is impossible to retrieve the cleartext of the user's
password given the UNIX hash of it), a separate password file
containing this 16 byte value must be kept. To minimise problems with
these two password files, getting out of sync, the UNIX <TT
CLASS="FILENAME"
> /etc/passwd</TT
> and the <TT
CLASS="FILENAME"
>smbpasswd</TT
> file,
a utility, <B
CLASS="COMMAND"
>mksmbpasswd.sh</B
>, is provided to generate
a smbpasswd file from a UNIX <TT
CLASS="FILENAME"
>/etc/passwd</TT
> file.
</P
><P
>To generate the smbpasswd file from your <TT
CLASS="FILENAME"
>/etc/passwd
</TT
> file use the following command :</P
><P
><TT
CLASS="PROMPT"
>$ </TT
><TT
CLASS="USERINPUT"
><B
>cat /etc/passwd | mksmbpasswd.sh
> /usr/local/samba/private/smbpasswd</B
></TT
></P
><P
>If you are running on a system that uses NIS, use</P
><P
><TT
CLASS="PROMPT"
>$ </TT
><TT
CLASS="USERINPUT"
><B
>ypcat passwd | mksmbpasswd.sh
> /usr/local/samba/private/smbpasswd</B
></TT
></P
><P
>The <B
CLASS="COMMAND"
>mksmbpasswd.sh</B
> program is found in
the Samba source directory. By default, the smbpasswd file is
stored in :</P
><P
><TT
CLASS="FILENAME"
>/usr/local/samba/private/smbpasswd</TT
></P
><P
>The owner of the <TT
CLASS="FILENAME"
>/usr/local/samba/private/</TT
>
directory should be set to root, and the permissions on it should
be set to 0500 (<B
CLASS="COMMAND"
>chmod 500 /usr/local/samba/private</B
>).
</P
><P
>Likewise, the smbpasswd file inside the private directory should
be owned by root and the permissions on is should be set to 0600
(<B
CLASS="COMMAND"
>chmod 600 smbpasswd</B
>).</P
><P
>The format of the smbpasswd file is (The line has been
wrapped here. It should appear as one entry per line in
your smbpasswd file.)</P
><P
><PRE
CLASS="PROGRAMLISTING"
>username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
[Account type]:LCT-<last-change-time>:Long name
</PRE
></P
><P
>Although only the <TT
CLASS="REPLACEABLE"
><I
>username</I
></TT
>,
<TT
CLASS="REPLACEABLE"
><I
>uid</I
></TT
>, <TT
CLASS="REPLACEABLE"
><I
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</I
></TT
>,
[<TT
CLASS="REPLACEABLE"
><I
>Account type</I
></TT
>] and <TT
CLASS="REPLACEABLE"
><I
> last-change-time</I
></TT
> sections are significant
and are looked at in the Samba code.</P
><P
>It is <I
CLASS="EMPHASIS"
>VITALLY</I
> important that there by 32
'X' characters between the two ':' characters in the XXX sections -
the smbpasswd and Samba code will fail to validate any entries that
do not have 32 characters between ':' characters. The first XXX
section is for the Lanman password hash, the second is for the
Windows NT version.</P
><P
>When the password file is created all users have password entries
consisting of 32 'X' characters. By default this disallows any access
as this user. When a user has a password set, the 'X' characters change
to 32 ascii hexadecimal digits (0-9, A-F). These are an ascii
representation of the 16 byte hashed value of a user's password.</P
><P
>To set a user to have no password (not recommended), edit the file
using vi, and replace the first 11 characters with the ascii text
<TT
CLASS="CONSTANT"
>"NO PASSWORD"</TT
> (minus the quotes).</P
><P
>For example, to clear the password for user bob, his smbpasswd file
entry would look like :</P
><P
><PRE
CLASS="PROGRAMLISTING"
> bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:[U ]:LCT-00000000:Bob's full name:/bobhome:/bobshell
</PRE
></P
><P
>If you are allowing users to use the smbpasswd command to set
their own passwords, you may want to give users NO PASSWORD initially
so they do not have to enter a previous password when changing to their
new password (not recommended). In order for you to allow this the
<B
CLASS="COMMAND"
>smbpasswd</B
> program must be able to connect to the
<B
CLASS="COMMAND"
>smbd</B
> daemon as that user with no password. Enable this
by adding the line :</P
><P
><B
CLASS="COMMAND"
>null passwords = yes</B
></P
><P
>to the [global] section of the smb.conf file (this is why
the above scenario is not recommended). Preferably, allocate your
users a default password to begin with, so you do not have
to enable this on your server.</P
><P
><I
CLASS="EMPHASIS"
>Note : </I
>This file should be protected very
carefully. Anyone with access to this file can (with enough knowledge of
the protocols) gain access to your SMB server. The file is thus more
sensitive than a normal unix <TT
CLASS="FILENAME"
>/etc/passwd</TT
> file.</P
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN105"
>The smbpasswd Command</A
></H1
><P
>The smbpasswd command maintains the two 32 byte password fields
in the smbpasswd file. If you wish to make it similar to the unix
<B
CLASS="COMMAND"
>passwd</B
> or <B
CLASS="COMMAND"
>yppasswd</B
> programs,
install it in <TT
CLASS="FILENAME"
>/usr/local/samba/bin/</TT
> (or your
main Samba binary directory).</P
><P
>Note that as of Samba 1.9.18p4 this program <I
CLASS="EMPHASIS"
>MUST NOT
BE INSTALLED</I
> setuid root (the new <B
CLASS="COMMAND"
>smbpasswd</B
>
code enforces this restriction so it cannot be run this way by
accident).</P
><P
><B
CLASS="COMMAND"
>smbpasswd</B
> now works in a client-server mode
where it contacts the local smbd to change the user's password on its
behalf. This has enormous benefits - as follows.</P
><P
></P
><UL
><LI
><P
>smbpasswd no longer has to be setuid root -
an enormous range of potential security problems is
eliminated.</P
></LI
><LI
><P
><B
CLASS="COMMAND"
>smbpasswd</B
> now has the capability
to change passwords on Windows NT servers (this only works when
the request is sent to the NT Primary Domain Controller if you
are changing an NT Domain user's password).</P
></LI
></UL
><P
>To run smbpasswd as a normal user just type :</P
><P
><TT
CLASS="PROMPT"
>$ </TT
><TT
CLASS="USERINPUT"
><B
>smbpasswd</B
></TT
></P
><P
><TT
CLASS="PROMPT"
>Old SMB password: </TT
><TT
CLASS="USERINPUT"
><B
><type old value here -
or hit return if there was no old password></B
></TT
></P
><P
><TT
CLASS="PROMPT"
>New SMB Password: </TT
><TT
CLASS="USERINPUT"
><B
><type new value>
</B
></TT
></P
><P
><TT
CLASS="PROMPT"
>Repeat New SMB Password: </TT
><TT
CLASS="USERINPUT"
><B
><re-type new value
</B
></TT
></P
><P
>If the old value does not match the current value stored for
that user, or the two new values do not match each other, then the
password will not be changed.</P
><P
>If invoked by an ordinary user it will only allow the user
to change his or her own Samba password.</P
><P
>If run by the root user smbpasswd may take an optional
argument, specifying the user name whose SMB password you wish to
change. Note that when run as root smbpasswd does not prompt for
or check the old password value, thus allowing root to set passwords
for users who have forgotten their passwords.</P
><P
><B
CLASS="COMMAND"
>smbpasswd</B
> is designed to work in the same way
and be familiar to UNIX users who use the <B
CLASS="COMMAND"
>passwd</B
> or
<B
CLASS="COMMAND"
>yppasswd</B
> commands.</P
><P
>For more details on using <B
CLASS="COMMAND"
>smbpasswd</B
> refer
to the man page which will always be the definitive reference.</P
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN144"
>Setting up Samba to support LanManager Encryption</A
></H1
><P
>This is a very brief description on how to setup samba to
support password encryption. </P
><P
></P
><OL
TYPE="1"
><LI
><P
>compile and install samba as usual</P
></LI
><LI
><P
>enable encrypted passwords in <TT
CLASS="FILENAME"
> smb.conf</TT
> by adding the line <B
CLASS="COMMAND"
>encrypt
passwords = yes</B
> in the [global] section</P
></LI
><LI
><P
>create the initial <TT
CLASS="FILENAME"
>smbpasswd</TT
>
password file in the place you specified in the Makefile
(--prefix=<dir>). See the notes under the <A
HREF="#SMBPASSWDFILEFORMAT"
>The smbpasswd File</A
>
section earlier in the document for details.</P
></LI
></OL
><P
>Note that you can test things using smbclient.</P
></DIV
></DIV
></BODY
></HTML
>
|
