From 4f5791ebd03eaec1c7da0865a383175b05102712 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 5 May 2024 19:47:29 +0200 Subject: Adding upstream version 2:4.17.12+dfsg. Signed-off-by: Daniel Baumann --- docs-xml/Samba-Developers-Guide/encryption.xml | 199 +++++++++++++++++++++++++ 1 file changed, 199 insertions(+) create mode 100644 docs-xml/Samba-Developers-Guide/encryption.xml (limited to 'docs-xml/Samba-Developers-Guide/encryption.xml') diff --git a/docs-xml/Samba-Developers-Guide/encryption.xml b/docs-xml/Samba-Developers-Guide/encryption.xml new file mode 100644 index 0000000..cba9490 --- /dev/null +++ b/docs-xml/Samba-Developers-Guide/encryption.xml @@ -0,0 +1,199 @@ + + + + + + + + JeremyAllison + + Samba Team +
+ samba@lists.samba.org +
+ + + + 19 Apr 1999 + + +LanMan and NT Password Encryption + + + 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. + + 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. + + 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. + + + + 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. + + + -- cgit v1.2.3