| 1 | <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 13. LanMan and NT Password Encryption</title><link rel="stylesheet" href="../samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"><link rel="home" 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 12. 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 13. 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 13. LanMan and NT Password Encryption</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Jeremy</span> <span class="orgname">Samba Team</span> <span class="surname">Allison</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><br>
|
|---|
| 2 | <code class="email"><<a class="email" href="mailto:[email protected]">[email protected]</a>></code><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#id2560809">Introduction</a></span></dt><dt><span class="sect1"><a href="pwencrypt.html#id2560829">How does it work?</a></span></dt><dt><span class="sect1"><a href="pwencrypt.html#id2560912">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="id2560809"></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="id2560829"></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 | <code class="filename">smbpasswd</code> 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="id2560912"></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 <code class="filename">
|
|---|
| 53 | /etc/passwd</code> and the <code class="filename">smbpasswd</code> file,
|
|---|
| 54 | a utility, <code class="literal">mksmbpasswd.sh</code>, is provided to generate
|
|---|
| 55 | a smbpasswd file from a UNIX <code class="filename">/etc/passwd</code> file.
|
|---|
| 56 | </p><p>To generate the smbpasswd file from your <code class="filename">/etc/passwd
|
|---|
| 57 | </code> file use the following command:</p><p><code class="prompt">$ </code><strong class="userinput"><code>cat /etc/passwd | mksmbpasswd.sh
|
|---|
| 58 | > /usr/local/samba/private/smbpasswd</code></strong></p><p>If you are running on a system that uses NIS, use</p><p><code class="prompt">$ </code><strong class="userinput"><code>ypcat passwd | mksmbpasswd.sh
|
|---|
| 59 | > /usr/local/samba/private/smbpasswd</code></strong></p><p>The <code class="literal">mksmbpasswd.sh</code> program is found in
|
|---|
| 60 | the Samba source directory. By default, the smbpasswd file is
|
|---|
| 61 | stored in :</p><p><code class="filename">/usr/local/samba/private/smbpasswd</code></p><p>The owner of the <code class="filename">/usr/local/samba/private/</code>
|
|---|
| 62 | directory should be set to root, and the permissions on it should
|
|---|
| 63 | be set to 0500 (<code class="literal">chmod 500 /usr/local/samba/private</code>).
|
|---|
| 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 | (<code class="literal">chmod 600 smbpasswd</code>).</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
|
|---|
|
|---|
