We already talked about user-level security in Chapter 1, so we won’t repeat the protocol background here. Rather, we are currently interested in how the server determines whether to respond to a session setup request with success or failure. Let’s consider a very simple case in which a server must provide open access to users without requiring creation of individual accounts. This example might seem a little counterintuitive, given the previous discussion of authentication, but it has its purpose and its uses.

Assume for a minute that Samba receives an authentication request in the form of a session setup packet and that the user cannot be authenticated. This might happen in a small office network where all clients and servers are operating in standalone configurations. This type of setup was described in Chapter 1 as peer-to-peer networking. If there is a user named susan logged into her local Windows workstation trying to access the share public on the Samba server named OAK (\\OAK\public), smbd will be responsible for looking in its own list of accounts (e.g., a smbpasswd file) to validate susan’s credentials. But what should Samba do when susan has no account on the server? The default behavior is to reject the connection attempt and indicate a logon failure.

The response to a failed logon is controlled by the map to guest parameter. To implement open sharing in this example, the parameter should be set to the value bad user . When susan cannot be authenticated (because she has no account), smbd evaluates the reason for the failure. A bad user is one whose name cannot be found in the the password storage system denoted by the passdb backend option. The concept of a backend is explored more in the upcoming section “Account Storage”; the default backend is an smbpasswd file. When the reason for the authentication is determined to be a bad username, smbd then honors susan’s request, but requires all authorization requests to be done using the guest account defined in smb.conf. The guest account value is a normal Unix account that smbd can use for this one purpose. The smb.conf for our guest server appears as follows:

  [global]
      netbios name = OAK
      workgroup = GARDEN
      server string = Public access file server
      security = user
      map to guest = bad user
      guest account = smbguest

  [public]
      path = /export/public
      guest ok = yes
      read only = no

Here is one file share named [public] , which makes the /data/public directory available for users. The permissions on this directory should allow anyone to create files (i.e., permission set to 1777). The guest ok option is needed to tell smbd that users mapped to the guest account should be allowed access to the share, assuming that the guest user, smbguest in this example, is allowed access by the filesystem permissions. The read only parameter operates as it has in past examples.

One disadvantage of a public server such as this one is that when a connection is mapped to the guest user, you lose all ability to audit any changes made by that connection. Any files created by this user are owned by the guest user. Other tasks, such as printer page accounting, also become impossible, as all knowledge of the original user is essentially lost.

Table 5-2 lists the various guest-related smb.conf parameters, and Table 5-3 lists the complete set of map to guest values.

Table 5-2. Guest-related parameters

Parameter	Value	Description	Default	Scope
guest account	username	The Unix account smbd uses this parameter when a connection is allowed guest access.	nobody	Global
guest ok	boolean	Specifies whether a user mapped to the no Share guest account is allowed access to this share.	no	Share

Table 5-2. Guest-related parameters (continued)

Parameter	Value			Description		Default	Scope
guest only	boolean			Automatically maps the user to the guest account for access to this share.		no	Share
map to guest		never, bad password, bad user, bad uid			Determine whether a failed authentication request should be treated as the guest user and allowed access. The complete list of values and their description is in Table 5-3.	never	Global

Table 5-3. Values for the map to guest parameter

The only real word of caution when you configure guest servers is to remember that the map to guest parameter is a global setting. A client may wish to access multiple file or printer shares on the same server. However, when providing user-level security, there is only one authenticated session per user for all share connections. It is not possible for a client to access the server as a guest for one share and then to provide a valid set of credentials to access another share. One way around this limitation is to use the virtual server technique described in Chapter 4. One server identity would be dedicated to providing guest access and another would be used for non-guest access. The map to guest option can have different values in each virtual server configuration.