docs/htmldocs/ENCRYPTION.html

   1 <HTML
   2 ><HEAD
   3 ><TITLE
   4 >LanMan and NT Password Encryption in Samba 2.x</TITLE
   5 ><META
   6 NAME="GENERATOR"
   7 CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD
   8 ><BODY
   9 CLASS="ARTICLE"
  10 BGCOLOR="#FFFFFF"
  11 TEXT="#000000"
  12 LINK="#0000FF"
  13 VLINK="#840084"
  14 ALINK="#0000FF"
  15 ><DIV
  16 CLASS="ARTICLE"
  17 ><DIV
  18 CLASS="TITLEPAGE"
  19 ><H1
  20 CLASS="TITLE"
  21 ><A
  22 NAME="PWENCRYPT"
  23 >LanMan and NT Password Encryption in Samba 2.x</A
  24 ></H1
  25 ><HR></DIV
  26 ><DIV
  27 CLASS="SECT1"
  28 ><H1
  29 CLASS="SECT1"
  30 ><A
  31 NAME="AEN3"
  32 >Introduction</A
  33 ></H1
  34 ><P
  35 >With the development of LanManager and Windows NT
  36         compatible password encryption for Samba, it is now able
  37         to validate user connections in exactly the same way as
  38         a LanManager or Windows NT server.</P
  39 ><P
  40 >This document describes how the SMB password encryption
  41         algorithm works and what issues there are in choosing whether
  42         you want to use it. You should read it carefully, especially
  43         the part about security and the "PROS and CONS" section.</P
  44 ></DIV
  45 ><DIV
  46 CLASS="SECT1"
  47 ><HR><H1
  48 CLASS="SECT1"
  49 ><A
  50 NAME="AEN7"
  51 >How does it work?</A
  52 ></H1
  53 ><P
  54 >LanManager encryption is somewhat similar to UNIX
  55         password encryption. The server uses a file containing a
  56         hashed value of a user's password.  This is created by taking
  57         the user's plaintext password, capitalising it, and either
  58         truncating to 14 bytes or padding to 14 bytes with null bytes.
  59         This 14 byte value is used as two 56 bit DES keys to encrypt
  60         a 'magic' eight byte value, forming a 16 byte value which is
  61         stored by the server and client. Let this value be known as
  62         the "hashed password".</P
  63 ><P
  64 >Windows NT encryption is a higher quality mechanism,
  65         consisting of doing an MD4 hash on a Unicode version of the user's
  66         password. This also produces a 16 byte hash value that is
  67         non-reversible.</P
  68 ><P
  69 >When a client (LanManager, Windows for WorkGroups, Windows
  70         95 or Windows NT) wishes to mount a Samba drive (or use a Samba
  71         resource), it first requests a connection and negotiates the
  72         protocol that the client and server will use. In the reply to this
  73         request the Samba server generates and appends an 8 byte, random
  74         value - this is stored in the Samba server after the reply is sent
  75         and is known as the "challenge".  The challenge is different for
  76         every client connection.</P
  77 ><P
  78 >The client then uses the hashed password (16 byte values
  79         described above), appended with 5 null bytes, as three 56 bit
  80         DES keys, each of which is used to encrypt the challenge 8 byte
  81         value, forming a 24 byte value known as the "response".</P
  82 ><P
  83 >In the SMB call SMBsessionsetupX (when user level security
  84         is selected) or the call SMBtconX (when share level security is
  85         selected), the 24 byte response is returned by the client to the
  86         Samba server.  For Windows NT protocol levels the above calculation
  87         is done on both hashes of the user's password and both responses are
  88         returned in the SMB call, giving two 24 byte values.</P
  89 ><P
  90 >The Samba server then reproduces the above calculation, using
  91         its own stored value of the 16 byte hashed password (read from the
  92         <TT
  93 CLASS="FILENAME"
  94 >smbpasswd</TT
  95 > file - described later) and the challenge
  96         value that it kept from the negotiate protocol reply. It then checks
  97         to see if the 24 byte value it calculates matches the 24 byte value
  98         returned to it from the client.</P
  99 ><P
 100 >If these values match exactly, then the client knew the
 101         correct password (or the 16 byte hashed value - see security note
 102         below) and is thus allowed access. If not, then the client did not
 103         know the correct password and is denied access.</P
 104 ><P
 105 >Note that the Samba server never knows or stores the cleartext
 106         of the user's password - just the 16 byte hashed values derived from
 107         it. Also note that the cleartext password or 16 byte hashed values
 108         are never transmitted over the network - thus increasing security.</P
 109 ></DIV
 110 ><DIV
 111 CLASS="SECT1"
 112 ><HR><H1
 113 CLASS="SECT1"
 114 ><A
 115 NAME="AEN18"
 116 >Important Notes About Security</A
 117 ></H1
 118 ><P
 119 >The unix and SMB password encryption techniques seem similar
 120         on the surface. This similarity is, however, only skin deep. The unix
 121         scheme typically sends clear text passwords over the network when
 122         logging in. This is bad. The SMB encryption scheme never sends the
 123         cleartext password over the network but it does store the 16 byte
 124         hashed values on disk. This is also bad. Why? Because the 16 byte hashed
 125         values are a "password equivalent". You cannot derive the user's
 126         password from them, but they could potentially be used in a modified
 127         client to gain access to a server. This would require considerable
 128         technical knowledge on behalf of the attacker but is perfectly possible.
 129         You should thus treat the smbpasswd file as though it contained the
 130         cleartext passwords of all your users. Its contents must be kept
 131         secret, and the file should be protected accordingly.</P
 132 ><P
 133 >Ideally we would like a password scheme which neither requires
 134         plain text passwords on the net or on disk. Unfortunately this
 135         is not available as Samba is stuck with being compatible with
 136         other SMB systems (WinNT, WfWg, Win95 etc). </P
 137 ><DIV
 138 CLASS="WARNING"
 139 ><P
 140 ></P
 141 ><TABLE
 142 CLASS="WARNING"
 143 BORDER="1"
 144 WIDTH="100%"
 145 ><TR
 146 ><TD
 147 ALIGN="CENTER"
 148 ><B
 149 >Warning</B
 150 ></TD
 151 ></TR
 152 ><TR
 153 ><TD
 154 ALIGN="LEFT"
 155 ><P
 156 >Note that Windows NT 4.0 Service pack 3 changed the
 157                 default for permissible authentication so that plaintext
 158                 passwords are <I
 159 CLASS="EMPHASIS"
 160 >never</I
 161 > sent over the wire.
 162                 The solution to this is either to switch to encrypted passwords
 163                 with Samba or edit the Windows NT registry to re-enable plaintext
 164                 passwords. See the document WinNT.txt for details on how to do
 165                 this.</P
 166 ><P
 167 >Other Microsoft operating systems which also exhibit
 168                 this behavior includes</P
 169 ><P
 170 ></P
 171 ><UL
 172 ><LI
 173 ><P
 174 >MS DOS Network client 3.0 with
 175                         the basic network redirector installed</P
 176 ></LI
 177 ><LI
 178 ><P
 179 >Windows 95 with the network redirector
 180                         update installed</P
 181 ></LI
 182 ><LI
 183 ><P
 184 >Windows 98 [se]</P
 185 ></LI
 186 ><LI
 187 ><P
 188 >Windows 2000</P
 189 ></LI
 190 ></UL
 191 ><P
 192 ><I
 193 CLASS="EMPHASIS"
 194 >Note :</I
 195 >All current release of
 196                 Microsoft SMB/CIFS clients support authentication via the
 197                 SMB Challenge/Response mechanism described here.  Enabling
 198                 clear text authentication does not disable the ability
 199                 of the client to participate in encrypted authentication.</P
 200 ></TD
 201 ></TR
 202 ></TABLE
 203 ></DIV
 204 ><DIV
 205 CLASS="SECT2"
 206 ><HR><H2
 207 CLASS="SECT2"
 208 ><A
 209 NAME="AEN37"
 210 >Advantages of SMB Encryption</A
 211 ></H2
 212 ><P
 213 ></P
 214 ><UL
 215 ><LI
 216 ><P
 217 >plain text passwords are not passed across
 218                         the network. Someone using a network sniffer cannot just
 219                         record passwords going to the SMB server.</P
 220 ></LI
 221 ><LI
 222 ><P
 223 >WinNT doesn't like talking to a server
 224                         that isn't using SMB encrypted passwords. It will refuse
 225                         to browse the server if the server is also in user level
 226                         security mode. It will insist on prompting the user for the
 227                         password on each connection, which is very annoying. The
 228                         only things you can do to stop this is to use SMB encryption.
 229                         </P
 230 ></LI
 231 ></UL
 232 ></DIV
 233 ><DIV
 234 CLASS="SECT2"
 235 ><HR><H2
 236 CLASS="SECT2"
 237 ><A
 238 NAME="AEN44"
 239 >Advantages of non-encrypted passwords</A
 240 ></H2
 241 ><P
 242 ></P
 243 ><UL
 244 ><LI
 245 ><P
 246 >plain text passwords are not kept
 247                         on disk. </P
 248 ></LI
 249 ><LI
 250 ><P
 251 >uses same password file as other unix
 252                         services such as login and ftp</P
 253 ></LI
 254 ><LI
 255 ><P
 256 >you are probably already using other
 257                         services (such as telnet and ftp) which send plain text
 258                         passwords over the net, so sending them for SMB isn't
 259                         such a big deal.</P
 260 ></LI
 261 ></UL
 262 ></DIV
 263 ></DIV
 264 ><DIV
 265 CLASS="SECT1"
 266 ><HR><H1
 267 CLASS="SECT1"
 268 ><A
 269 NAME="AEN53"
 270 ><A
 271 NAME="SMBPASSWDFILEFORMAT"
 272 ></A
 273 >The smbpasswd file</A
 274 ></H1
 275 ><P
 276 >In order for Samba to participate in the above protocol
 277         it must be able to look up the 16 byte hashed values given a user name.
 278         Unfortunately, as the UNIX password value is also a one way hash
 279         function (ie. it is impossible to retrieve the cleartext of the user's
 280         password given the UNIX hash of it), a separate password file
 281         containing this 16 byte value must be kept. To minimise problems with
 282         these two password files, getting out of sync, the UNIX <TT
 283 CLASS="FILENAME"
 284 >       /etc/passwd</TT
 285 > and the <TT
 286 CLASS="FILENAME"
 287 >smbpasswd</TT
 288 > file,
 289         a utility, <B
 290 CLASS="COMMAND"
 291 >mksmbpasswd.sh</B
 292 >, is provided to generate
 293         a smbpasswd file from a UNIX <TT
 294 CLASS="FILENAME"
 295 >/etc/passwd</TT
 296 > file.
 297         </P
 298 ><P
 299 >To generate the smbpasswd file from your <TT
 300 CLASS="FILENAME"
 301 >/etc/passwd
 302         </TT
 303 > file use the following command :</P
 304 ><P
 305 ><TT
 306 CLASS="PROMPT"
 307 >$ </TT
 308 ><TT
 309 CLASS="USERINPUT"
 310 ><B
 311 >cat /etc/passwd | mksmbpasswd.sh
 312         &gt; /usr/local/samba/private/smbpasswd</B
 313 ></TT
 314 ></P
 315 ><P
 316 >If you are running on a system that uses NIS, use</P
 317 ><P
 318 ><TT
 319 CLASS="PROMPT"
 320 >$ </TT
 321 ><TT
 322 CLASS="USERINPUT"
 323 ><B
 324 >ypcat passwd | mksmbpasswd.sh
 325         &gt; /usr/local/samba/private/smbpasswd</B
 326 ></TT
 327 ></P
 328 ><P
 329 >The <B
 330 CLASS="COMMAND"
 331 >mksmbpasswd.sh</B
 332 > program is found in
 333         the Samba source directory. By default, the smbpasswd file is
 334         stored in :</P
 335 ><P
 336 ><TT
 337 CLASS="FILENAME"
 338 >/usr/local/samba/private/smbpasswd</TT
 339 ></P
 340 ><P
 341 >The owner of the <TT
 342 CLASS="FILENAME"
 343 >/usr/local/samba/private/</TT
 344 >
 345         directory should be set to root, and the permissions on it should
 346         be set to 0500 (<B
 347 CLASS="COMMAND"
 348 >chmod 500 /usr/local/samba/private</B
 349 >).
 350         </P
 351 ><P
 352 >Likewise, the smbpasswd file inside the private directory should
 353         be owned by root and the permissions on is should be set to 0600
 354         (<B
 355 CLASS="COMMAND"
 356 >chmod 600 smbpasswd</B
 357 >).</P
 358 ><P
 359 >The format of the smbpasswd file is (The line has been
 360         wrapped here. It should appear as one entry per line in
 361         your smbpasswd file.)</P
 362 ><P
 363 ><PRE
 364 CLASS="PROGRAMLISTING"
 365 >username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:
 366         [Account type]:LCT-&lt;last-change-time&gt;:Long name
 367         </PRE
 368 ></P
 369 ><P
 370 >Although only the <TT
 371 CLASS="REPLACEABLE"
 372 ><I
 373 >username</I
 374 ></TT
 375 >,
 376         <TT
 377 CLASS="REPLACEABLE"
 378 ><I
 379 >uid</I
 380 ></TT
 381 >, <TT
 382 CLASS="REPLACEABLE"
 383 ><I
 384 >       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</I
 385 ></TT
 386 >,
 387         [<TT
 388 CLASS="REPLACEABLE"
 389 ><I
 390 >Account type</I
 391 ></TT
 392 >] and <TT
 393 CLASS="REPLACEABLE"
 394 ><I
 395 >       last-change-time</I
 396 ></TT
 397 > sections are significant
 398         and are looked at in the Samba code.</P
 399 ><P
 400 >It is <I
 401 CLASS="EMPHASIS"
 402 >VITALLY</I
 403 > important that there by 32
 404         'X' characters between the two ':' characters in the XXX sections -
 405         the smbpasswd and Samba code will fail to validate any entries that
 406         do not have 32 characters  between ':' characters. The first XXX
 407         section is for the Lanman password hash, the second is for the
 408         Windows NT version.</P
 409 ><P
 410 >When the password file is created all users have password entries
 411         consisting of 32 'X' characters. By default this disallows any access
 412         as this user. When a user has a password set, the 'X' characters change
 413         to 32 ascii hexadecimal digits (0-9, A-F). These are an ascii
 414         representation of the 16 byte hashed value of a user's password.</P
 415 ><P
 416 >To set a user to have no password (not recommended), edit the file
 417         using vi, and replace the first 11 characters with the ascii text
 418         <TT
 419 CLASS="CONSTANT"
 420 >"NO PASSWORD"</TT
 421 > (minus the quotes).</P
 422 ><P
 423 >For example, to clear the password for user bob, his smbpasswd file
 424         entry would look like :</P
 425 ><P
 426 ><PRE
 427 CLASS="PROGRAMLISTING"
 428 >       bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:[U          ]:LCT-00000000:Bob's full name:/bobhome:/bobshell
 429         </PRE
 430 ></P
 431 ><P
 432 >If you are allowing users to use the smbpasswd command to set
 433         their own passwords, you may want to give users NO PASSWORD initially
 434         so they do not have to enter a previous password when changing to their
 435         new password (not recommended). In order for you to allow this the
 436         <B
 437 CLASS="COMMAND"
 438 >smbpasswd</B
 439 > program must be able to connect to the
 440         <B
 441 CLASS="COMMAND"
 442 >smbd</B
 443 > daemon as that user with no password. Enable this
 444         by adding the line :</P
 445 ><P
 446 ><B
 447 CLASS="COMMAND"
 448 >null passwords = yes</B
 449 ></P
 450 ><P
 451 >to the [global] section of the smb.conf file (this is why
 452         the above scenario is not recommended). Preferably, allocate your
 453         users a default password to begin with, so you do not have
 454         to enable this on your server.</P
 455 ><P
 456 ><I
 457 CLASS="EMPHASIS"
 458 >Note : </I
 459 >This file should be protected very
 460         carefully. Anyone with access to this file can (with enough knowledge of
 461         the protocols) gain access to your SMB server. The file is thus more
 462         sensitive than a normal unix <TT
 463 CLASS="FILENAME"
 464 >/etc/passwd</TT
 465 > file.</P
 466 ></DIV
 467 ><DIV
 468 CLASS="SECT1"
 469 ><HR><H1
 470 CLASS="SECT1"
 471 ><A
 472 NAME="AEN105"
 473 >The smbpasswd Command</A
 474 ></H1
 475 ><P
 476 >The smbpasswd command maintains the two 32 byte password fields
 477         in the smbpasswd file. If you wish to make it similar to the unix
 478         <B
 479 CLASS="COMMAND"
 480 >passwd</B
 481 > or <B
 482 CLASS="COMMAND"
 483 >yppasswd</B
 484 > programs,
 485         install it in <TT
 486 CLASS="FILENAME"
 487 >/usr/local/samba/bin/</TT
 488 > (or your
 489         main Samba binary directory).</P
 490 ><P
 491 >Note that as of Samba 1.9.18p4 this program <I
 492 CLASS="EMPHASIS"
 493 >MUST NOT
 494         BE INSTALLED</I
 495 > setuid root (the new <B
 496 CLASS="COMMAND"
 497 >smbpasswd</B
 498 >
 499         code enforces this restriction so it cannot be run this way by
 500         accident).</P
 501 ><P
 502 ><B
 503 CLASS="COMMAND"
 504 >smbpasswd</B
 505 > now works in a client-server mode
 506         where it contacts the local smbd to change the user's password on its
 507         behalf. This has enormous benefits - as follows.</P
 508 ><P
 509 ></P
 510 ><UL
 511 ><LI
 512 ><P
 513 >smbpasswd no longer has to be setuid root -
 514                 an enormous range of potential security problems is
 515                 eliminated.</P
 516 ></LI
 517 ><LI
 518 ><P
 519 ><B
 520 CLASS="COMMAND"
 521 >smbpasswd</B
 522 > now has the capability
 523                 to change passwords on Windows NT servers (this only works when
 524                 the request is sent to the NT Primary Domain Controller if you
 525                 are changing an NT Domain user's password).</P
 526 ></LI
 527 ></UL
 528 ><P
 529 >To run smbpasswd as a normal user just type :</P
 530 ><P
 531 ><TT
 532 CLASS="PROMPT"
 533 >$ </TT
 534 ><TT
 535 CLASS="USERINPUT"
 536 ><B
 537 >smbpasswd</B
 538 ></TT
 539 ></P
 540 ><P
 541 ><TT
 542 CLASS="PROMPT"
 543 >Old SMB password: </TT
 544 ><TT
 545 CLASS="USERINPUT"
 546 ><B
 547 >&lt;type old value here -
 548         or hit return if there was no old password&gt;</B
 549 ></TT
 550 ></P
 551 ><P
 552 ><TT
 553 CLASS="PROMPT"
 554 >New SMB Password: </TT
 555 ><TT
 556 CLASS="USERINPUT"
 557 ><B
 558 >&lt;type new value&gt;
 559         </B
 560 ></TT
 561 ></P
 562 ><P
 563 ><TT
 564 CLASS="PROMPT"
 565 >Repeat New SMB Password: </TT
 566 ><TT
 567 CLASS="USERINPUT"
 568 ><B
 569 >&lt;re-type new value
 570         </B
 571 ></TT
 572 ></P
 573 ><P
 574 >If the old value does not match the current value stored for
 575         that user, or the two new values do not match each other, then the
 576         password will not be changed.</P
 577 ><P
 578 >If invoked by an ordinary user it will only allow the user
 579         to change his or her own Samba password.</P
 580 ><P
 581 >If run by the root user smbpasswd may take an optional
 582         argument, specifying the user name whose SMB password you wish to
 583         change.  Note that when run as root smbpasswd does not prompt for
 584         or check the old password value, thus allowing root to set passwords
 585         for users who have forgotten their passwords.</P
 586 ><P
 587 ><B
 588 CLASS="COMMAND"
 589 >smbpasswd</B
 590 > is designed to work in the same way
 591         and be familiar to UNIX users who use the <B
 592 CLASS="COMMAND"
 593 >passwd</B
 594 > or
 595         <B
 596 CLASS="COMMAND"
 597 >yppasswd</B
 598 > commands.</P
 599 ><P
 600 >For more details on using <B
 601 CLASS="COMMAND"
 602 >smbpasswd</B
 603 > refer
 604         to the man page which will always be the definitive reference.</P
 605 ></DIV
 606 ><DIV
 607 CLASS="SECT1"
 608 ><HR><H1
 609 CLASS="SECT1"
 610 ><A
 611 NAME="AEN144"
 612 >Setting up Samba to support LanManager Encryption</A
 613 ></H1
 614 ><P
 615 >This is a very brief description on how to setup samba to
 616         support password encryption. </P
 617 ><P
 618 ></P
 619 ><OL
 620 TYPE="1"
 621 ><LI
 622 ><P
 623 >compile and install samba as usual</P
 624 ></LI
 625 ><LI
 626 ><P
 627 >enable encrypted passwords in <TT
 628 CLASS="FILENAME"
 629 >               smb.conf</TT
 630 > by adding the line <B
 631 CLASS="COMMAND"
 632 >encrypt
 633                 passwords = yes</B
 634 > in the [global] section</P
 635 ></LI
 636 ><LI
 637 ><P
 638 >create the initial <TT
 639 CLASS="FILENAME"
 640 >smbpasswd</TT
 641 >
 642                 password file in the place you specified in the Makefile
 643                 (--prefix=&lt;dir&gt;). See the notes under the <A
 644 HREF="#SMBPASSWDFILEFORMAT"
 645 >The smbpasswd File</A
 646 >
 647                 section earlier in the document for details.</P
 648 ></LI
 649 ></OL
 650 ><P
 651 >Note that you can test things using smbclient.</P
 652 ></DIV
 653 ></DIV
 654 ></BODY
 655 ></HTML
 656 >