From e7c2603609c99e4c39948a7f7afcd633223714e7 Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Mon, 4 Nov 2002 16:20:15 +0000 Subject: Move explanation of encryption algorithm to dev-doc (This used to be commit b279cc065385d45b8a16e220fb13b278d5921b1f) --- docs/docbook/projdoc/ENCRYPTION.sgml | 243 ++++------------------------------- 1 file changed, 27 insertions(+), 216 deletions(-) (limited to 'docs/docbook/projdoc') diff --git a/docs/docbook/projdoc/ENCRYPTION.sgml b/docs/docbook/projdoc/ENCRYPTION.sgml index 6a26dbeffa..f903d7d334 100644 --- a/docs/docbook/projdoc/ENCRYPTION.sgml +++ b/docs/docbook/projdoc/ENCRYPTION.sgml @@ -7,88 +7,42 @@ Samba Team
- samba@samba.org + jra@samba.org
- - 19 Apr 1999 + + JelmerVernooij + + Samba Team +
+ jelmer@samba.org +
+ + + + 4 November 2002 -LanMan and NT Password Encryption in Samba 2.x +LanMan and NT Password Encryption in Samba Introduction - 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. - - 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. - - - - - How does it work? - - 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". - - 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. - - 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. - - 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". - - 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. + Newer windows clients send encrypted passwords over + the wire, instead of plain text passwords. The newest clients + will only send encrypted passwords and refuse to send plain text + passwords, unless their registry is tweaked. - The Samba server then reproduces the above calculation, using - its own stored value of the 16 byte hashed password (read from the - smbpasswd 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. - - 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. + These passwords can't be converted to unix style encrypted + passwords. Because of that you can't use the standard unix + user database, and you have to store the Lanman and NT hashes + somewhere else. For more information, see the documentation + about the passdb backend = parameter. + - 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. @@ -183,111 +137,6 @@ - - <anchor id="SMBPASSWDFILEFORMAT">The smbpasswd file - - 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 - /etc/passwd and the smbpasswd file, - a utility, mksmbpasswd.sh, is provided to generate - a smbpasswd file from a UNIX /etc/passwd file. - To generate the smbpasswd file from your /etc/passwd - file use the following command : - - $ cat /etc/passwd | mksmbpasswd.sh - > /usr/local/samba/private/smbpasswd - - If you are running on a system that uses NIS, use - - $ ypcat passwd | mksmbpasswd.sh - > /usr/local/samba/private/smbpasswd - - The mksmbpasswd.sh program is found in - the Samba source directory. By default, the smbpasswd file is - stored in : - - /usr/local/samba/private/smbpasswd - - The owner of the /usr/local/samba/private/ - directory should be set to root, and the permissions on it should - be set to 0500 (chmod 500 /usr/local/samba/private). - - - Likewise, the smbpasswd file inside the private directory should - be owned by root and the permissions on is should be set to 0600 - (chmod 600 smbpasswd). - - - 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.) - - -username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: - [Account type]:LCT-<last-change-time>:Long name - - - Although only the username, - uid, - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, - [Account type] and - last-change-time sections are significant - and are looked at in the Samba code. - - It is VITALLY 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. - - 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. - - 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 - "NO PASSWORD" (minus the quotes). - - For example, to clear the password for user bob, his smbpasswd file - entry would look like : - - - bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:[U ]:LCT-00000000:Bob's full name:/bobhome:/bobshell - - - 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 - smbpasswd program must be able to connect to the - smbd daemon as that user with no password. Enable this - by adding the line : - - null passwords = yes - - 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. - - Note : 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 /etc/passwd file. - - - The smbpasswd Command @@ -297,25 +146,14 @@ username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: install it in /usr/local/samba/bin/ (or your main Samba binary directory). - Note that as of Samba 1.9.18p4 this program MUST NOT - BE INSTALLED setuid root (the new smbpasswd - code enforces this restriction so it cannot be run this way by - accident). - smbpasswd 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. - - smbpasswd no longer has to be setuid root - - an enormous range of potential security problems is - eliminated. - - smbpasswd 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). - + smbpasswd 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). To run smbpasswd as a normal user just type : @@ -348,31 +186,4 @@ username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: to the man page which will always be the definitive reference. - - - Setting up Samba to support LanManager Encryption - - This is a very brief description on how to setup samba to - support password encryption. - - - compile and install samba as usual - - - enable encrypted passwords in - smb.conf by adding the line encrypt - passwords = yes in the [global] section - - - create the initial smbpasswd - password file in the place you specified in the Makefile - (--prefix=<dir>). See the notes under the The smbpasswd File - section earlier in the document for details. - - - - Note that you can test things using smbclient. - - -- cgit