diff options
Diffstat (limited to 'docs/htmldocs/ENCRYPTION.html')
| -rw-r--r-- | docs/htmldocs/ENCRYPTION.html | 656 |
1 files changed, 656 insertions, 0 deletions
diff --git a/docs/htmldocs/ENCRYPTION.html b/docs/htmldocs/ENCRYPTION.html new file mode 100644 index 0000000000..e4d3ef5fed --- /dev/null +++ b/docs/htmldocs/ENCRYPTION.html @@ -0,0 +1,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 +>
\ No newline at end of file |