Sams Teach Yourself Samba in 24 Hours
Hour 6: Security Levels and Passwords
Previous
Hour
|
Sections in this Chapter: |
|
|
|
||
|
||
|
||
|
|
Sams Teach Yourself Samba in 24 Hours |
|
||||||||||||||||
|
Hour 6: Security Levels and Passwords |
|
||||||||||||||||
|
|
||
|
Regarding Plain Text and Encrypted Passwords and Windows 9x and Windows NT Clients |
|
|
Now that you understand how smbd authenticates connections, turn your attention to the details of usernames and passwords.
As you have seen already in the packet dump from a session setup request, some clients send the username in all uppercase letters. By default, Samba attempts to look up this username in all lowercase and then with only the first letter capitalized, for example boss and Boss. If you have a strange UNIX username, such as BobAcct assigned to Bob in Accounting, Samba is unable to locate the username with this method.
What is provided is a parameter to specify the maximum number of capital letters in the username. Samba then attempts to discover the username using a brute force method of trying all permutations of capitalized letters from 1 to the value defined.
Set a username level of 4 and apply that to Bob's account name:
username level = 4
You can assume that BOBACCT is transmitted as the username in the session setup request. Samba attempts to locate the following names in the system password file (or whatever account back end is being used):
bobacct
Bobacct
bObacct
boBacct
bobAcct
bobaCct
bobacCt
bobaccT
BObacct
BoBacct
BobAcct
After the username is located, the search terminates. The greater the username level, the more combinations of uppercase/lowercase letters that are tried and hence the longer the delay before being able to report success or failure. If all the UNIX account names are in the standard format of all lowercase letters, this parameter becomes unnecessary.
One of the main problems when integrating UNIX and PC operating systems is synchronizing user account information. Some variants of UNIX restrict use to eight characters or fewer for the username, whereas some Windows clients allow a free-form string including white space. Many times administrators find themselves attempting to integrate two already established systems, both with existing account names. The username map parameter enables you to specify a file that contains mappings from the username sent during the session setup to a local username.
This option is not enabled by default.
Default: username map = none
In order to use mapping, you need to specify the location of the file containing the mapping entries.
Example: username map = /usr/local/samba/lib/users.map
Each entry in the map file looks like
unix username = client username ...
For example, if you want to map the Administrator or Admin username to the sysadmin account, you would define an entry as
sysadmin = Administrator Admin
When a user attempts to connect to a share as Administrator, he or she would need to supply the password for the sysadmin account.
|
Caution - The mapping affects all instances of the client username with the exception of the session setup to a password server when security = server. Using the previous example, if a user attempts to connect to the Administrator's home directory (\\server\Administrator), the user would actually connect to \\server\sysadmin. |
It is possible to map UNIX groups to a single account. This line would map any user in the staff group to the staffsmb account:
staffsmb = @staff
There is also a wildcard that enables you to match any username sent by the client. This entry maps all users to the guest account:
guest = *
There is a catch to beware of regarding substitutions: smbd parses the file line-by-line and carries out any substitutions to the end of the file. This can lead to multiple mapping from username to new_username1 to new_username2. If you want to stop parsing the file after a map is made, you should preface the line with an exclamation point (!). If no match is found in the file, Samba uses the original username.
When plain-text passwords are used for authentication, the issues that arise are similar to the ones I mentioned in the section about usernames regarding case sensitivity. This snippet of the tcpdump output shown before reminds you that the password, testpass, is being sent in uppercase letters:
[000] 54 45 53 54 50 41 53 53 00 00 00 00 00 00 42 4F TESTPASS ......BO [010] 53 53 00 00 00 00 00 00 42 4F 53 53 00 43 48 49 SS...... BOSS.CHI [020] 50 53 4E 44 49 50 53 00 57 69 6E 64 6F 77 73 20 PSNDIPS. Windows [030] 34 2E 30 00 57 69 6E 64 6F 77 73 20 34 2E 30 00 4.0.Wind ows 4.0.
The password-level parameter acts analogously to the username parameter. The difference is that the default tries to use the password two ways, as it is sent from the client and in all lowercase letters.
The parameter takes an integer value that defines the maximum number of uppercase letters allowed in the password, as did the username-level parameter. Samba then attempts to validate the username using permutations of uppercase letters in the password.
The higher the value and the more combinations Samba tries, the longer delay in authentication attempts. You need to determine what is acceptable for your server. A password level of 8 on most systems means that the passwords are no longer case sensitive. I have found that using a level of 4 is generally acceptable, without causing too much trouble with existing passwords. However, it is also helpful to have a password change policy dictating that no more than four uppercase letters be used.
Samba supports both the LanManager and Windows NT SMB password-encryption algorithms. This means that Samba can authenticate users in the same manner that Microsoft servers can.
If you are familiar with UNIX's encryption of password, some points might seem to be similar. For example, the LanMan and NT password hashes are irreversible, as are UNIX passwords stored in /etc/passwd (or /etc/shadow). Irreversible means that the only way to determine whether a user has entered the correct password is to encrypt the entered password and compare it against the encrypted version stored on disk. There is no means of decrypting a LanMan/NT password hash other than brute force methods, such as a dictionary attack.
You should
be aware of one major difference between UNIX and LanMan/NT
password-encryption algorithms. The algorithm for generating a LanManager- or
Windows NT-hashed password always produces the same result if given the same
input. This means that if you encrypt the password testpass
200 times, the encrypted password is the same every time. This creates what
is known as a plain-text equivalent password.
I hope that the following example will clarify this. You can follow along in Figure 6.8.
Figure
6.8
Sample challenge/response authentication between a client and server.
1. The client sends a negotiate protocol request to the server.
2. If the server supports password encryption, the appropriate bit to indicate this is set in the response packet and the server includes an 8-byte challenge in the packet. The challenge is randomly generated and is different for each client.
3. Figure 6.9 illustrates the generation of the client's response. The client then uses the encrypted password appropriate for the protocol level negotiated (either LanMan or NT) appended with five null bytes (this creates a 168-bit stream) to generate three different 56-bit DES keys which are each then used to encrypt the 8-byte challenge. The three 8-byte results are concatenated to form the 24-byte response. This response is then sent to the server.
Figure
6.9
Generating the 24-byte response.
4. The server then performs the same steps using the encrypted version of the user's password stored on disk. The resulting 24-byte stream is compared to the one sent by the client to determine whether the client knew the correct password.
5. If the server's 24-byte stream and the response sent by the client match, the user session setup request is accepted (or tree connection request in the case of share-level security). If they don't match, that means that the client did not know the correct password.
Don't worry about being able to repeat the process verbatim. I've included it only to prove a point. The user's password is never transmitted across the network. The result is increased security! Only data generated from the password is sent.
Now back to my previous comment about plain-text equivalent passwords. The server must store the encrypted password somewhere to be able to produce the 24-byte value so that it can verify the client's response. Remember that the password is always encrypted to the same value. Therefore, if someone knows the encrypted version of the password, that person could participate in the previous scenario without ever knowing the password!
Does this seem like too much information to digest? Perhaps some of these points can help you to decide whether to use encrypted passwords or plain-text passwords:
If you decide to use password encryption, which is turned off by default, you must enable it in the smb.conf file by setting encrypt passwords to yes:
encrypt passwords = yes
After you enable password encryption, you must now keep track of a second user account file. This file, usually named smbpasswd and stored in a subdirectory named private located underneath the Samba install directory, is where Samba stores the LanMan and NT hashes of the user passwords. The format is very similar to /etc/passwd:
username:uid:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:account flags:lastset:
The username and uid fields are self explanatory. The next two fields contain the two 16-byte LanMan and NT hashes of the user's password respectively. The account flags field determines the type of the account such as user account or a machine account (machine accounts are discussed more in Hour 22, "Experimental PDC Support"). The lastset field records the time of the last password change.
Here's a sample entry:
jerryc:1009:AAD3B435B51404EEAAD3B435B51404EE:31D6CFE0D16AE931B73C59D7E0C089C0:[U ]:LCT-36918AD9:
If you decide to locate or name the file containing the encrypted passwords in a location other than the default, you can define the encrypted password file using the smb passwd file parameter. The value should be an absolute path to the SMB password file:
smb password file = /etc/smbpasswd
Creating the initial SMB passwd file and setting passwords can be an extremely daunting task if you have a large number of existing UNIX accounts.
There are two common solutions to this. Both solutions require you first to create an initial smbpasswd entry for each user. Using one of the scripts included with the Samba distribution, this can easily be done:
cat /etc/passwd | mksmbpasswd.sh > /usr/local/samba/private/smbpasswd
If the UNIX box obtains account information from NIS or NIS+, you can substitute the preceding cat command with either ypcat or niscat depending on your system. The mksmbpasswd.sh shell script is located in the source/script/ subdirectory of the Samba distribution. The resulting smbpasswd file contains all the users from /etc/passwd with their LanMan and NT hashed passwords set to 32 X. Samba does not validate a user whose password entry is set to this value.
If you want to set the value to an empty password, you must change
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
to
NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Issue the following command as root:
/usr/local/samba/bin/smbpasswd -n username
Replace username with the appropriate string. Samba stores the encrypted passwords in a file named smbpasswd and includes a utility also named smbpasswd to manipulate entries in the file. Don't let the common name confuse you.
Alternatively you could edit the smbpasswd file by hand using a text editor and change the string yourself. However, if you do edit the smbpasswd file by hand, make sure that the LanMan and NT password fields contain 32 characters, no more and no fewer. If the field does not have exactly 32 characters, Samba can never validate that user.
After changing the smbpasswd entry, you need to set the following null passwords parameter to yes in the [global] section of smb.conf:
null passwords = yes null passwords = yes
After the smbpasswd file is created, the next question is "How do I populate the password field for each entry?"
If you are currently using Samba with plain-text passwords, you can gradually set the encrypted password fields for each user by using the Boolean update encrypted parameter The default value to this parameter is no. In order to enable support, you need to add the following entry to smb.conf in the [global] section:
update encrypted = yes
If you set the parameter's value to yes, you must make sure that the encrypt passwords parameter is set to no.
encrypt passwords = no
When update encrypted is set to yes, each time that a user successfully requests a session setup, Samba writes the encrypted version of the plain-text password that was transmitted for that user. The only requirement is that the user has a valid entry in the existing smbpasswd file. Whatever the previous value of the passwd field was, it is now set to the user's current password. Obviously, this method makes sense only when in user-level security.
This solution allows the Samba server to run for a few days or weeks, whatever length is necessary, capturing passwords and populating the smbpassword file. When the smbpasswd file contains enough entries to your satisfaction, you can simply change the following parameters in smb.conf and switch to using encrypted passwords:
encrypt passwords = yes update encrypted = no
Most of your users will never know that anything has changed.
Figure 6.10 displays the process of how the update encrypted parameter works. First the client and server select the SMB protocol dialect to use and then the client sends the username and password in plain text contained in the sessions setup request. If the user can be successfully authenticated against /etc/passwd, smbd encrypts the password and writes the information to the smbpasswd file. You should be aware that the user's entry in smbpasswd at this point is never used in the validation process. It is used only as a storage facility for the encrypted password.
Figure
6.10
Gradually populating the smbpasswd file using the update encrypted parameter.
I mentioned before that Samba includes a utility named smbpasswd for manipulating entries in the smbpasswd file. This tool is located in the bin/ subdirectory and is the Samba equivalent of the UNIX /bin/passwd program.
When a user receives a new UNIX account, most sites assign a random password and then instruct the user on how to change it to something that is more memorable or personal. If you are beginning a Samba infrastructure--that's a word right out of Dilbert cartoon strip, isn't it?--you might simply assign users an SMB password at the same time that they are issued a UNIX account. Along with the standard instructions for using /bin/passwd to change their UNIX passwords, you would also include instruction for using the /usr/local/samba/bin/smbpasswd command to change their SMB passwords as well. This is certainly the easiest solution because the responsibility of keeping the password synchronized, if desired, has been handed over to the user. However, this could result in more help desk calls depending on the caliber of your users. It can be very easy to confuse which password goes with which logon if the accounts become out of sync; a user can be very adamant about her belief that she is entering the correct password for her account. You be the judge which solution is best for you.
Here's a sample session of changing my SMB password using the smbpasswd command. I've included comments regarding what was typed in angle brackets (< >). (You didn't really think I would show you my password, did you?)
[jerryc@bilbo jerryc]408: /usr/local/samba/bin/smbpasswd Old SMB password: <enter old SMB password here> New SMB password: <enter new SMB password here> Retype new SMB password: <reenter new SMB password here> ..Password changed for user jerryc
I want to make a quick note about using plain-text passwords and newer Microsoft clients. This and other issues specific to the Microsoft 32-bit client are more fully covered in Hour 14, "Windows 9x and Windows NT."
Beginning with Service Pack 3 for Windows NT 4.0, Microsoft changed the default to use only encrypted passwords. Therefore if you attempt to connect to a unencrypted Samba server, you will see this error:
System error 1240 has occurred. The account is not authorized to login from this station.
You'll see the same behavior in Windows 95 clients that have the SMB network redirector update (vrdrupd.exe). However, Windows 95 will simply keep asking for a password. This patch updates:
\windows\system\Vredir.vxd \windows\system\Vnetsup.xvd
It is possible to use a unencrypted Samba server with these clients. It simply requires setting a value in the Windows system registry. If you want to see the details of this solution, you can get the full story in Hour 14.
|
Sams Teach Yourself Samba in 24 Hours |
|
||||||||||||||||
|
Hour 6: Security Levels and Passwords |
|
||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.
){kind=link}
){kind=link}
){kind=link}