diff options
Diffstat (limited to 'docs/htmldocs/Samba3-Developers-Guide/pwencrypt.html')
| -rw-r--r-- | docs/htmldocs/Samba3-Developers-Guide/pwencrypt.html | 103 |
1 files changed, 0 insertions, 103 deletions
diff --git a/docs/htmldocs/Samba3-Developers-Guide/pwencrypt.html b/docs/htmldocs/Samba3-Developers-Guide/pwencrypt.html deleted file mode 100644 index 01ee798025..0000000000 --- a/docs/htmldocs/Samba3-Developers-Guide/pwencrypt.html +++ /dev/null @@ -1,103 +0,0 @@ -<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.75.2"><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" title="Chapter 13. LanMan and NT Password Encryption"><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="surname">Allison</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><br> - <code class="email"><<a class="email" href="mailto:samba@samba.org">samba@samba.org</a>></code><br> - </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#id332270">Introduction</a></span></dt><dt><span class="sect1"><a href="pwencrypt.html#id332287">How does it work?</a></span></dt><dt><span class="sect1"><a href="pwencrypt.html#id332348">The smbpasswd file</a></span></dt></dl></div><div class="sect1" title="Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id332270"></a>Introduction</h2></div></div></div><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" title="How does it work?"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id332287"></a>How does it work?</h2></div></div></div><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 - <code class="filename">smbpasswd</code> 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" title="The smbpasswd file"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id332348"></a>The smbpasswd file</h2></div></div></div><a name="SMBPASSWDFILEFORMAT"></a><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 <code class="filename"> - /etc/passwd</code> and the <code class="filename">smbpasswd</code> file, - a utility, <code class="literal">mksmbpasswd.sh</code>, is provided to generate - a smbpasswd file from a UNIX <code class="filename">/etc/passwd</code> file. - </p><p>To generate the smbpasswd file from your <code class="filename">/etc/passwd - </code> file use the following command:</p><p><code class="prompt">$ </code><strong class="userinput"><code>cat /etc/passwd | mksmbpasswd.sh - > /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 - > /usr/local/samba/private/smbpasswd</code></strong></p><p>The <code class="literal">mksmbpasswd.sh</code> program is found in - the Samba source directory. By default, the smbpasswd file is - 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> - directory should be set to root, and the permissions on it should - be set to 0500 (<code class="literal">chmod 500 /usr/local/samba/private</code>). - </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 - (<code class="literal">chmod 600 smbpasswd</code>).</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><pre class="programlisting"> -username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: - [Account type]:LCT-<last-change-time>:Long name - </pre><p>Although only the <em class="replaceable"><code>username</code></em>, - <em class="replaceable"><code>uid</code></em>, <em class="replaceable"><code> - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</code></em>, - [<em class="replaceable"><code>Account type</code></em>] and <em class="replaceable"><code> - last-change-time</code></em> sections are significant - and are looked at in the Samba code.</p><p>It is <span class="emphasis"><em>VITALLY</em></span> 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 - <code class="constant">"NO PASSWORD"</code> (minus the quotes).</p><p>For example, to clear the password for user bob, his smbpasswd file - entry would look like :</p><pre class="programlisting"> -bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: - [U ]:LCT-00000000:Bob's full name:/bobhome:/bobshell - </pre><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 - <code class="literal">smbpasswd</code> program must be able to connect to the - <code class="literal">smbd</code> daemon as that user with no password. Enable this - by adding the line :</p><p><code class="literal">null passwords = yes</code></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><span class="emphasis"><em>Note : </em></span>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 <code class="filename">/etc/passwd</code> 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 12. 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> |