-Contributor: Jeremy Allison <samba-bugs@samba.anu.edu.au>
-Updated: June 27, 1997
+!==
+!== ENCRYPTION.txt for Samba release 2.0.5a 22 Jul 1999
+!==
+Contributor: Jeremy Allison <samba-bugs@samba.org>
+Updated: April 19, 1999
Note: Please refer to WinNT.txt also
Subject: LanManager / Samba Password Encryption.
How does it work ?
------------------
- LanManager encryption is somewhat similar to UNIX password
+LanManager encryption is somewhat similar to UNIX password
encryption. The server uses a file containing a hashed value of a
-users password. This is created by taking the users paintext
+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 users password. This
+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
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 users password and both responses are returned
+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 it's own
+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
If these values match exactly, then the client knew the correct
password (or the 16 byte hashed value - see security note below) and
-is this allowed access. If not then the client did not know the
+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
-users password - just the 16 byte hashed values derived from it. Also
+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.
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 users password from them,
+"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
- 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 promting the
+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.
The smbpasswd file.
-------------------
- In order for Samba to participate in the above protocol it must
+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 users
+function (ie. it is impossible to retrieve the cleartext of the user's
password given the UNIX hash of it) then 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 format of the smbpasswd file is
-username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Long name:user home dir:user shell
+username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:[Account type]:LCT-<last-change-time>:Long name
-Although only the username, uid, and XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-sections are significant and are looked at in the Samba code.
+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
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 users password.
+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 asci text
Eg. To clear the password for user bob, his smbpasswd file entry would
look like :
-bob:100:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Bob's full name:/bobhome:/bobshell
+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).
+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 = true
+
+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
The smbpasswd Command.
----------------------
- The smbpasswd command maintains the two 32 byte password fields in
+The smbpasswd command maintains the two 32 byte password fields in
the smbpasswd file. If you wish to make it similar to the unix passwd
or yppasswd programs, install it in /usr/local/samba/bin (or your main
-Samba binary directory) and make it setuid root.
+Samba binary directory).
-Note that if you do not do this then the root user will have to set all
-users passwords.
+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).
-To set up smbpasswd as setuid root, change to the Samba binary install
-directory and then type (as root) :
+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.
-chown root smbpasswd
-chmod 4555 smbpasswd
+1). smbpasswd no longer has to be setuid root - an enormous
+range of potential security problems is eliminated.
-If smbpasswd is installed as setuid root then you would use it as
-follows.
+2). 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 :
smbpasswd
-Old SMB password: <type old alue here - just hit return if there is NO PASSWORD>
+Old SMB password: <type old value here - or hit return if there was no old password >
New SMB Password: < type new value >
Repeat New SMB Password: < re-type new value >
smbpasswd is designed to work in the same way and be familiar to UNIX
users who use the passwd or yppasswd commands.
-NOTE. As smbpasswd is designed to be installed as setuid root I would
-appreciate it if everyone examined the source code to look for
-potential security flaws. A setuid program, if not written properly can
-be an open door to a system cracker. Please help make this program
-secure by reporting all problems to me (the author, Jeremy Allison).
-
-My email address is :-
-
-jallison@whistle.com
+For more details on using smbpasswd refer to the man page which
+will always be the definitive reference.
Setting up Samba to support LanManager Encryption.
--------------------------------------------------
password encryption. More complete instructions will probably be added
later.
-1) get and compile the libdes libraries. the source is available from
-ftp://samba.anu.edu.au/pub/libdes/
-
-2) enable the encryption stuff in the Samba makefile, making sure you
-point it to the libdes library and include file (it needs des.h)
-The entries you need to uncomment are the four lines after the comment :-
-
-# This is for SMB encrypted (lanman) passwords.
-
-Note that you may have to change the variable DES_BASE to
-point at the place where you installed the DES library.
+1) compile and install samba as usual
-3) compile and install samba as usual
-
-4) f your system can't compile the module getsmbpass.c then remove the
+2) if your system can't compile the module getsmbpass.c then remove the
-DSMBGETPASS define from the Makefile.
-5) enable encrypted passwords in smb.conf by adding the line
+3) enable encrypted passwords in smb.conf by adding the line
"encrypt passwords = yes" in the [global] section
-6) create the initial smbpasswd password file in the place you
+4) create the initial smbpasswd password file in the place you
specified in the Makefile. A simple way to do this based on your
existing Makefile (assuming it is in a reasonably standard format) is
like this:
like this:
# SMB password file.
-tridge:148:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:Andrew Tridgell:/home/tridge:/bin/tcsh
+tridge:148:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:[U ]:LCT-00000000:Andrew Tridgell:/home/tridge:/bin/tcsh
note that the uid and username fields must be right. Also, you must get
the number of X's right (there should be 32).
-If you wish, install the smbpasswd program as suid root.
-
-chown root /usr/local/samba/bin/smbpasswd
-chmod 4555 /usr/local/samba/bin/smbpasswd
-
-7) set the passwords for users using the smbpasswd command. For
+5) set the passwords for users using the smbpasswd command. For
example, as root you could do "smbpasswd tridge"
-8) try it out!
+6) try it out!
Note that you can test things using smbclient, as it also now supports
encryption.
-NOTE TO USA Sites that Mirror Samba
------------------------------------
-
-The DES library is considered a munition in the USA. Under US Law it is
-illegal to export this software, or to put it in a freely available ftp
-site.
-
-Please do not mirror the libdes directory from the site on
-samba.anu.edu.au
-
-Thank you,
-
-Jeremy Allison.
-
==============================================================================
Footnote: Please refer to WinNT.txt also
git.samba.org / tprouty / samba.git / blobdiff