9.3 Authentication of Clients

At this point, we should discuss how Samba authenticates users. Each user who attempts to connect to a share not allowing guest access must provide a password to make a successful connection. What Samba does with that password ”and consequently the strategy Samba will use to handle user authentication ”is the arena of the security configuration option. Samba currently supports four security levels on its network: share , user , server , and domain .

Share-level security: Each share in the workgroup has one or more passwords associated with it. Anyone who knows a valid password for the share can access it.
User-level security: Each share in the workgroup is configured to allow access from certain users. With each initial tree connection, the Samba server verifies users and their passwords to allow them access to the share.
Server-level security: This is the same as user-level security, except that the Samba server uses another server to validate users and their passwords before granting access to the share.
Domain-level security: Samba becomes a member of a Windows NT domain and uses one of the domain's domain controllers ”either the PDC or a BDC ”to perform authentication. Once authenticated, the user is given a special token that allows her access to any share with appropriate access rights. With this token, the domain controller will not have to revalidate the user's password each time she attempts to access another share within the domain. The domain controller can be a Windows NT/2000 PDC or BDC, or Samba acting as a Windows NT PDC.

Each security policy can be implemented with the global security option, as shown in Table 9-3.

Table 9-3. Security option

Option	Parameters	Function	Default	Scope
`security`	`domain` , `server` , `share` , or `user`	Indicates the type of security that the Samba server will use	`user`	Global

9.3.1 Share-Level Security

With share-level security, each share has one or more passwords associated with it, with the client being authenticated when first connecting to the share. This differs from the other modes of security in that there are no restrictions as to whom can access a share, as long as that individual knows the correct password. Shares often have multiple passwords. For example, one password might grant read-only access, while another might grant read/write access. Security is maintained as long as unauthorized users do not discover the password for a share to which they shouldn't have access.

OS/2 and Windows 95/98/Me both support share-level security on their resources. You can set up share-level security with Windows 95/98/Me by first enabling share-level security using the Access Control tab of the Network Control Panel dialog. Then select the "Share-level access control" radio button (which deselects the "User-level access control" radio button), as shown in Figure 9-1, and click the OK button. Reboot as requested .

Figure 9-1. Selecting share-level security on a Windows 95/98/Me system

Next, right-click a resource ”such as a hard drive or a CD-ROM ”and select the Properties menu item. This will bring up the Resource Properties dialog box. Select the Sharing tab at the top of the dialog box, and enable the resource as Shared As. From here, you can configure how the shared resource will appear to individual users, as well as assign whether the resource will appear as read-only, read/write, or a mix, depending on the password that is supplied.

You might be thinking that this security model is not a good fit for Samba ”and you would be right. In fact, if you set the security = share option in the Samba configuration file, Samba will still reuse the username/password combinations in the system password files to authenticate access. More precisely, Samba will take the following steps when a client requests a connection using share-level security:

When a connection is requested, Samba will accept the password and (if sent) the username of the client.
If the share is guest only , the user is immediately granted access to the share with the rights of the user specified by the guest account parameter; no password checking is performed.
For other shares, Samba appends the username to a list of users who are allowed access to the share. It then attempts to validate the password given in association with that username. If successful, Samba grants the user access to the share with the rights assigned to that user. The user will not need to authenticate again unless a revalidate = yes option has been set inside the share.
If the authentication is unsuccessful , Samba attempts to validate the password against the list of users previously compiled during attempted connections, as well as those specified under the share in the configuration file. If the password matches that of any username (as specified in the system password file, typically /etc/passwd ), the user is granted access to the share under that username.
However, if the share has a guest ok or public option set, the user will default to access with the rights of the user specified by the guest account option.

You can indicate in the configuration file which users should be initially placed on the share-level security user list by using the username configuration option, as shown here:

 [global]     security = share [accounting1]     path = /home/samba/accounting1     guest ok = no     writable = yes     username = davecb, pkelly, andyo

Here, when a user attempts to connect to a share, Samba verifies the sent password against each user in its own list, in addition to the passwords of users davecb , pkelly , and andyo . If any of the passwords match, the connection is verified , and the user is allowed. Otherwise, connection to the specific share will fail.

9.3.2 Share-Level Security Options

Table 9-4 shows the options typically associated with share-level security .

Table 9-4. Share-level access options

Option	Parameters	Function	Default	Scope
`only user`	Boolean	If `yes` , usernames specified by `username` are the only ones allowed	`no`	Share
`username` ( `user` or `users` )	string (list of usernames)	Users against which a client's password is tested	None	Share

9.3.2.1 only user

This Boolean option indicates whether Samba will allow connections to a share using share-level security based solely on the individuals specified in the username option, instead of those users compiled on Samba's internal list. The default value for this option is no . You can override it per share as follows :

 [global]     security = share [data]     username = andy, peter, valerie     only user = yes

9.3.2.2 username

This option presents a list of usernames and/or group names against which Samba tests a connection password to allow access. It is typically used with clients that have share-level security to allow connections to a particular service based solely on a qualifying password ”in this case, one that matches a password set up for a specific user:

 [global]     security = share [data]     username = andy, peter, terry

You can enter a list of usernames and/or group names. If a name is prefixed by an at sign ( @ ), it is interpreted as a group name, with NIS groups searched before Unix groups. If the name is prefixed by a plus sign ( + ), it is interpreted as the name of a Unix group, and NIS is not searched. If the name is prefixed by an ampersand ( & ), it is interpreted as an NIS group name rather than a Unix group name. The plus sign and ampersand can be used together to specify whether NIS or Unix groups are searched first. When Samba encounters a group name in this option, it attempts to authenticate each user in the group until if finds one that succeeds. Beware that this can be very inefficient.

We recommend against using this option unless you are implementing a Samba server with share-level security.

9.3.3 User-Level Security

The default mode of security with Samba is user-level security . With this method, each share is assigned specific users that can access it. When a user requests a connection to a share, Samba authenticates by validating the given username and password with the authorized users in the configuration file and the passwords in the password database of the Samba server. As mentioned earlier in the chapter, one way to isolate which users are allowed access to a specific share is by using the valid users option for each share:

 [global]     security = user [accounting1]     writable = yes     valid users = bob, joe, sandy

Each user listed can connect to the share if the password provided matches the password stored in the system password database on the server. Once the initial authentication succeeds, the client will not need to supply a password again to access that share unless the revalidate = yes option has been set.

Passwords can be sent to the Samba server in either an encrypted or a nonencrypted format. If you have both types of systems on your network, you should ensure that the passwords represented by each user are stored both in a traditional account database and Samba's encrypted password database. This way, authorized users can gain access to their shares from any type of client. ^[1] However, we recommend that you move your system to encrypted passwords and abandon nonencrypted passwords if security is an issue. Section 9.4 of this chapter explains how to use encrypted as well as nonencrypted passwords.

^[1] Having both encrypted and nonencrypted password clients on your network is one of the reasons why Samba allows you to include (or not include) various options in the Samba configuration file based on the client operating system or machine name variables .

9.3.4 Server-Level Security

Server-level security is similar to user-level security. However, with server-level security, Samba delegates password authentication to another SMB password server ”typically another Samba server or a Windows NT/2000 server acting as a PDC on the network. Note that Samba still maintains its list of shares and their configuration in its smb.conf file. When a client attempts to make a connection to a particular share, Samba validates that the user is indeed authorized to connect to the share. Samba then attempts to validate the password by passing the username and password to the SMB password server. If the password is accepted, a session is established with the client. See Figure 9-2 for an illustration of this setup.

Figure 9-2. A typical system setup using server-level security

You can configure Samba to use a separate password server under server-level security with the use of the password server global configuration option, as follows:

 [global]     security = server     password server = mixtec toltec

Note that you can specify more than one machine as the target of the password server ; Samba moves down the list of servers in the event that its first choice is unreachable. The servers identified by the password server option are given as NetBIOS names, not their DNS names or equivalent IP addresses. Also, if any of the servers reject the given password, the connection automatically fails ”Samba will not attempt another server.

One caveat: when using this option, you still need an account representing that user on the regular Samba server. This is because the Unix operating system needs a username to perform various I/O operations. The preferable method of handling this is to give the user an account on the Samba server but disable the account's password by replacing it in the system password file (e.g., /etc/passwd ) with an asterisk (*).

9.3.5 Domain-Level Security

With domain-level security , the Samba server acts as a member of a Windows domain. Recall from Chapter 1 that each domain has a primary domain controller, which can be a Windows NT/2000 or Samba server offering password authentication. The domain controller keeps track of users and passwords in its own database and authenticates each user when she first logs on and wishes to access another machine's shares.

As mentioned earlier in this chapter, Samba has a similar ability to offer user-level security, but that option is Unix-centric and assumes that the authentication occurs via Unix password files. If the Unix machine is part of an NIS or NIS+ domain, Samba authenticates users transparently against a shared password file in typical Unix fashion. Samba then provides access to the NIS or NIS+ domain from Windows. There is, of course, no relationship between the NIS concept of a domain and a Windows NT domain.

Configuring Samba for domain-level security is covered in Chapter 4 in Section 4.7.