Hour 6: Security Levels and Passwords: Security Levels and the security Parameter

Sams Teach Yourself Samba in 24 Hours

Hour 6: Security Levels and Passwords

Sections in this Chapter:
Security Levels and the security Parameter		Final Comments
Usernames and Passwords		Summary
Accessibility		Q&A
Miscellaneous		New Terms

Hour 6
Security Levels and Passwords

After my weeklong vacation in Hour 4, "Installing and Testing the Configuration," I arrived back at work, and the boss pulled me aside. "These network drive things you set up are great! Productivity has gone through the roof! I'd like to scale this setup company-wide, but before I can make the recommendation to management, I need some hard facts on the security of things. Can you explain to me how Samba checks my password when I log in?"

I stood there for a moment thinking. After a few silent moments, I said, "I'd be glad to sit down and explain how it all happens, but first I need an hour to get my morning cup of coffee and finish a few things."

"Sounds good," the boss replied. "I'll see you in an hour in my office."

I started down the hall toward the testing lab trying to remember where I left my favorite coffee cup and my copy of this book.

Would I be able to find the information in time? Would Samba be deployed company wide?

Stay tuned and find out more!

In the previous hour, I talked about the general layout of the Samba configuration file as well as some of the general and miscellaneous [global] parameters. In this hour, I'll examine the parameters that relate to the authentication methods that Samba uses to validate connections. In addition to that, I'll also talk about password security using encryption and a client's IP address to decide whether to attempt to validate the connection at all.

Security Levels and the security Parameter

security = share		security = server
security = user		security = domain

The SMB protocol has two fundamental modes of validating connections. The mode that Samba uses is defined by setting the security parameter in the [global] section of the smb.conf file.

The smb.conf man page entry for the security parameter lists four possible strings which can be used, but I said that the SMB protocol has two basic levels of authentication. In reality, of the four modes that Samba supports--share, user, server, and domain--the only ones that are fundamentally different are share and user, which are the two SMB security levels. The other values supported by Samba are variations on user-mode security:

security = [share|user|server|domain]

Caution - Prior to version 2.0, the default settings for the security parameter was share. In version 2.0, the default was changed to user-mode security.

Samba 2.0 introduced a password database API to enable developers to plug in difference authentication by defining a set of functions. This means that there are several choices for you when deciding on how to store your user account information.

Figure 6.1 shows the possible back ends that are currently in use or in the process of being developed. The client requests a connection to the server and the server contacts the account database through a defined interface. It is not necessary to really know what back end is being used; as far as Samba is concerned, the database provides the user information needed.

Figure 6.1
Samba allows multiple, mutually exclusive, user account databases.

Experimental support is underway for accessing NIS+ tables as well as an Lightweight Directory Access Protocol (LDAP) server. Of the possibilities displayed in Figure 6.1, the two which are currently supported are Samba's private/smbpasswd file and the standard UNIX /etc/passwd file. Both of these are discussed in depth later in this hour. For now, you should be aware that each one requires a username and password for validation.

security = share

In share-level security, the client sends a password during the tree connection request. No associated username is required. This is slightly different from the description I gave in Hour 2, "Windows Networking," which more accurately represents user-level security. Figure 6.2 illustrates the two steps used in a connection to an SMB server in share-level security.

Figure 6.2
Password sent in share-level security with the tree connection request.

You might already be aware of a common example of a share-level SMB server. Share-level security is the default setting for a Windows 95 file or print server (see Figure 6.3). Figure 6.4 displays the page in the network control panel that enables you to change the security level.

Figure 6.3
Share-level security screen in Windows 95.

Figure 6.4
Choosing the security level in Windows 95.

By now you might be thinking, "Share-level security seems to violate the UNIX username/password authentication model." You are correct. The concept of share-level security does not work well in a multiuser environment, such as UNIX, but Samba goes to great lengths to not compromise the UNIX security model.

Although the client expects the share-level SMB server to associate a password with each share, Samba uses the standard UNIX username/password scheme. In spite of the fact that clients connecting to a server in share-level security send the password in the tree connection request, many clients also send a session setup request containing a username. Samba adds this username to a list of names which it attempts to validate using the transmitted password. You can specify other usernames to be added to the list by using the user parameter in the service:

user = jerryc, smbguest, jdoe

Samba attempts to validate the connection by trying to validate each username with the password until a pair is successfully authenticated or all the possible pairs fail, in which case the tree connection is refused. Because Samba always attempts to validate a username/password pair anyway, share-level security is not recommended. It is generally better to use one of the forms of user-level security, which I will discuss next.

security = user

The SMB connection setup process in Hour 2 (see "Protocol Overview") describes a connection attempt to a server in user-level security. If plain text passwords are being used, the client sends a username and password during the session setup.

Because this is a book on using Samba and not on developing an SMB server, I won't bore you with packet dumps very often. But I think there is some value in displaying the account information transmitted during this portion of the connection. Here is a session setup request from a Windows 95 OSR2 client connecting to a Samba server. The packets were captured using an SMB-enabled version of tcpdump:

C:\WINDOWS> net use h: \\bilbo\boss
The command was completed successfully.

Tip - tcpdump is a network packet sniffer that is distributed with source code. The SMB-enabled version is available for download from http://samba.org. More about packet sniffers can be found in Hour 11, "Troubleshooting."

After executing the previous command, tcpdump produces the following output:

SMB PACKET: SMBsesssetupX (REQUEST)
SMB Command   =  0x73
Error class   =  0x0
Error code    =  0
Flags1        =  0x10
Flags2        =  0x0
Tree ID       =  0
Proc ID       =  28754
UID           =  1
MID           =  3586
Word Count    =  13
Com2=0x75
Res1=0x0
Off2=125
MaxBuffer=2920
MaxMpx=50
VcNumber=0
SessionKey=0xBE
CaseInsensitivePasswordLength=
[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.

You can clearly see that the password testpass and the username boss are transmitted during the session setup request. If you look closely, you can also notice that the username and password are translated into uppercase letters. This can be annoying and is covered in the section, "Password Encryption," later in this hour.

When in user-level security, Samba accepts the username/password pair transmitted and attempts to validate them against its account database. This process is the same regardless of the user account backend (for example, encrypted passwords, LDAP, and /etc/passwd), although the proof of identity might be some derived value rather than the actual password itself. Please refer to the notes on the SMB challenge/response encryption under the "Password Encryption" section later in this hour. If the session setup validation succeeds, the client does not need to transmit user account information during subsequent tree connection requests.

The three steps for a connection to a user-level SMB server are shown in Figure 6.5. First the protocol level is selected, next a session is established between the client and server, and finally the connection to resource is configured.

Figure 6.5
Tree connection requests in user-mode security.

security = server

Samba's server-level security is really a type of user-level security. Samba reports to the client that it is in user-level security and the client performs a normal session setup. Samba then takes the information and sends a session setup request to the machine designated as the password server. If the password server is in user-level security and accepts the session setup, Samba accepts the initial session setup request from the client.

Figure 6.6 illustrates this process. The chronological flow of the diagram is from top to bottom. If you follow the arrows, you'll see that at the point where the client requests a session with the server, the latter machine sends a session request to the password server. Only after the server has received a response from the password server is the client's session request accepted or rejected.

Figure 6.6
A client connecting to a Samba server in server-level security.

The password server parameter has the following syntax:

password server = NetBIOS name of SMB server

You can list multiple NetBIOS names in the list such as

password server = DOMAINPDC DOMAINBDC1 DOMAINBDC2

This allows Samba to attempt a session setup request to each machine in the list in order until a server is contacted. This means that the next machine on the list is contacted only if the previous machine was unreachable. This does not mean that Samba attempts to contact the other machines listed, if the session request to the first machine fails.

Note - You must use the NetBIOS name of the password server (not the IP address), and Samba must have a way of resolving the name to an IP address in order to attempt the connection.

Caution - You can use any SMB server in user mode security as the password, but the security of your Samba server then becomes only as secure as the password server you select. You have been warned! Common choices for a password server are your Windows NT Primary Domain Controller (PDC) or another Samba box.

There is one fine point of using server-level security. After Samba has granted the session setup request to the client, it must then have some means of obtaining a UNIX uid for the user in order to control access to files. This means that although local accounts are not used to validate the connection, the user must have a uid on the local server. There are two possible solutions to this problem:

You can create a local account for all users that access the Samba server and simply disable the password field in /etc/passwd (or whatever file in which the passwords are stored). Setting the password field to the asterisk character (*) normally does this.

You can use one of the means of mapping usernames within a share, such as force user, which is described in Hour 7, "File Sharing." Or use the username map parameter, which I'll talk about shortly.

Figure 6.7 appears very similar to Figure 6.6; they do in fact represent the same process. Figure 6.7 has been expanded to describe the point at which Samba attempts to obtain a valid UNIX uid for the username specified in the session setup request. What is transparent, in a sense, is that the username lookup can be filtered through a username map before actually searching for a name in /etc/passwd.

Figure 6.7
Mapping a validated username to a UNIX uid.

security = domain

Samba's domain security is basically the same concept as its server-level security, with the exception that the Samba server becomes a member of a Windows NT domain. This means that the Samba server can participate in things such as trust relationships. There are several other advantages to using security = domain rather than security = server. I would like to defer this discussion to Hour 12, "Case Study: Replacing an NT File and Print Server," where I'll look at how to replace a Windows NT File and Print Server with a Samba box running in domain-level security. For now, consider them equivalent.