1<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter�15.�LanMan and NT Password Encryption</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.66.1"><link rel="start" href="index.html" title="SAMBA Developers Guide"><link rel="up" href="pt03.html" title="Part�III.�Samba Subsystems"><link rel="prev" href="wins.html" title="Chapter�14.�Samba WINS Internals"><link rel="next" href="pt04.html" title="Part�IV.�Debugging and tracing"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter�15.�LanMan and NT Password Encryption</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="wins.html">Prev</a>�</td><th width="60%" align="center">Part�III.�Samba Subsystems</th><td width="20%" align="right">�<a accesskey="n" href="pt04.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="pwencrypt"></a>Chapter�15.�LanMan and NT Password Encryption</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Jeremy</span> <span class="surname">Allison</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><br> 2 <tt class="email"><<a href="mailto:samba@samba.org">samba@samba.org</a>></tt><br> 3 </p></div></div></div></div><div><p class="pubdate">19 Apr 1999</p></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="pwencrypt.html#id2537695">Introduction</a></span></dt><dt><span class="sect1"><a href="pwencrypt.html#id2537716">How does it work?</a></span></dt><dt><span class="sect1"><a href="pwencrypt.html#id2537800">The smbpasswd file</a></span></dt></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2537695"></a>Introduction</h2></div></div></div><p>With the development of LanManager and Windows NT 4 compatible password encryption for Samba, it is now able 5 to validate user connections in exactly the same way as 6 a LanManager or Windows NT server.</p><p>This document describes how the SMB password encryption 7 algorithm works and what issues there are in choosing whether 8 you want to use it. You should read it carefully, especially 9 the part about security and the "PROS and CONS" section.</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2537716"></a>How does it work?</h2></div></div></div><p>LanManager encryption is somewhat similar to UNIX 10 password encryption. The server uses a file containing a 11 hashed value of a user's password. This is created by taking 12 the user's plaintext password, capitalising it, and either 13 truncating to 14 bytes or padding to 14 bytes with null bytes. 14 This 14 byte value is used as two 56 bit DES keys to encrypt 15 a 'magic' eight byte value, forming a 16 byte value which is 16 stored by the server and client. Let this value be known as 17 the "hashed password".</p><p>Windows NT encryption is a higher quality mechanism, 18 consisting of doing an MD4 hash on a Unicode version of the user's 19 password. This also produces a 16 byte hash value that is 20 non-reversible.</p><p>When a client (LanManager, Windows for WorkGroups, Windows 21 95 or Windows NT) wishes to mount a Samba drive (or use a Samba 22 resource), it first requests a connection and negotiates the 23 protocol that the client and server will use. In the reply to this 24 request the Samba server generates and appends an 8 byte, random 25 value - this is stored in the Samba server after the reply is sent 26 and is known as the "challenge". The challenge is different for 27 every client connection.</p><p>The client then uses the hashed password (16 byte values 28 described above), appended with 5 null bytes, as three 56 bit 29 DES keys, each of which is used to encrypt the challenge 8 byte 30 value, forming a 24 byte value known as the "response".</p><p>In the SMB call SMBsessionsetupX (when user level security 31 is selected) or the call SMBtconX (when share level security is 32 selected), the 24 byte response is returned by the client to the 33 Samba server. For Windows NT protocol levels the above calculation 34 is done on both hashes of the user's password and both responses are 35 returned in the SMB call, giving two 24 byte values.</p><p>The Samba server then reproduces the above calculation, using 36 its own stored value of the 16 byte hashed password (read from the 37 <tt class="filename">smbpasswd</tt> file - described later) and the challenge 38 value that it kept from the negotiate protocol reply. It then checks 39 to see if the 24 byte value it calculates matches the 24 byte value 40 returned to it from the client.</p><p>If these values match exactly, then the client knew the 41 correct password (or the 16 byte hashed value - see security note 42 below) and is thus allowed access. If not, then the client did not 43 know the correct password and is denied access.</p><p>Note that the Samba server never knows or stores the cleartext 44 of the user's password - just the 16 byte hashed values derived from 45 it. Also note that the cleartext password or 16 byte hashed values 46 are never transmitted over the network - thus increasing security.</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2537800"></a>The smbpasswd file</h2></div></div></div><a name="SMBPASSWDFILEFORMAT"></a><p>In order for Samba to participate in the above protocol 47 it must be able to look up the 16 byte hashed values given a user name. 48 Unfortunately, as the UNIX password value is also a one way hash 49 function (ie. it is impossible to retrieve the cleartext of the user's 50 password given the UNIX hash of it), a separate password file 51 containing this 16 byte value must be kept. To minimise problems with 52 these two password files, getting out of sync, the UNIX <tt class="filename"> 53 /etc/passwd</tt> and the <tt class="filename">smbpasswd</tt> file, 54 a utility, <span><b class="command">mksmbpasswd.sh</b></span>, is provided to generate 55 a smbpasswd file from a UNIX <tt class="filename">/etc/passwd</tt> file. 56 </p><p>To generate the smbpasswd file from your <tt class="filename">/etc/passwd 57 </tt> file use the following command:</p><p><tt class="prompt">$ </tt><b class="userinput"><tt>cat /etc/passwd | mksmbpasswd.sh 58 > /usr/local/samba/private/smbpasswd</tt></b></p><p>If you are running on a system that uses NIS, use</p><p><tt class="prompt">$ </tt><b class="userinput"><tt>ypcat passwd | mksmbpasswd.sh 59 > /usr/local/samba/private/smbpasswd</tt></b></p><p>The <span><b class="command">mksmbpasswd.sh</b></span> program is found in 60 the Samba source directory. By default, the smbpasswd file is 61 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> 62 directory should be set to root, and the permissions on it should 63 be set to 0500 (<span><b class="command">chmod 500 /usr/local/samba/private</b></span>). 64 </p><p>Likewise, the smbpasswd file inside the private directory should 65 be owned by root and the permissions on is should be set to 0600 66 (<span><b class="command">chmod 600 smbpasswd</b></span>).</p><p>The format of the smbpasswd file is (The line has been 67 wrapped here. It should appear as one entry per line in 68 your smbpasswd file.)</p><pre class="programlisting"> 69username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: 70 [Account type]:LCT-<last-change-time>:Long name 71 </pre><p>Although only the <i class="replaceable"><tt>username</tt></i>, 72 <i class="replaceable"><tt>uid</tt></i>, <i class="replaceable"><tt> 73 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</tt></i>, 74 [<i class="replaceable"><tt>Account type</tt></i>] and <i class="replaceable"><tt> 75 last-change-time</tt></i> sections are significant 76 and are looked at in the Samba code.</p><p>It is <span class="emphasis"><em>VITALLY</em></span> important that there by 32 77 'X' characters between the two ':' characters in the XXX sections - 78 the smbpasswd and Samba code will fail to validate any entries that 79 do not have 32 characters between ':' characters. The first XXX 80 section is for the Lanman password hash, the second is for the 81 Windows NT version.</p><p>When the password file is created all users have password entries 82 consisting of 32 'X' characters. By default this disallows any access 83 as this user. When a user has a password set, the 'X' characters change 84 to 32 ascii hexadecimal digits (0-9, A-F). These are an ascii 85 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 86 using vi, and replace the first 11 characters with the ascii text 87 <tt class="constant">"NO PASSWORD"</tt> (minus the quotes).</p><p>For example, to clear the password for user bob, his smbpasswd file 88 entry would look like :</p><pre class="programlisting"> 89bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: 90 [U ]:LCT-00000000:Bob's full name:/bobhome:/bobshell 91 </pre><p>If you are allowing users to use the smbpasswd command to set 92 their own passwords, you may want to give users NO PASSWORD initially 93 so they do not have to enter a previous password when changing to their 94 new password (not recommended). In order for you to allow this the 95 <span><b class="command">smbpasswd</b></span> program must be able to connect to the 96 <span><b class="command">smbd</b></span> daemon as that user with no password. Enable this 97 by adding the line :</p><p><span><b class="command">null passwords = yes</b></span></p><p>to the [global] section of the smb.conf file (this is why 98 the above scenario is not recommended). Preferably, allocate your 99 users a default password to begin with, so you do not have 100 to enable this on your server.</p><p><span class="emphasis"><em>Note : </em></span>This file should be protected very 101 carefully. Anyone with access to this file can (with enough knowledge of 102 the protocols) gain access to your SMB server. The file is thus more 103 sensitive than a normal unix <tt class="filename">/etc/passwd</tt> file.</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="wins.html">Prev</a>�</td><td width="20%" align="center"><a accesskey="u" href="pt03.html">Up</a></td><td width="40%" align="right">�<a accesskey="n" href="pt04.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter�14.�Samba WINS Internals�</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">�Part�IV.�Debugging and tracing</td></tr></table></div></body></html> 104