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
Value
Description
never
Reply with a logon failure error. This is the default behavior.
bad password
Use the guest account if the username exists in Samba’s list of accounts but the client transmitted the wrong password. This value is not recommended in most circumstances, due to the confusion that it may cause when a user is allowed access but does not have the expected access.
bad uid
Valid only when used on member servers ( security = ads or security = domain ). Use the guest account if the domain mode authentication succeeded but a local uid for the username cannot be found.
bad user
Use the guest account if the username is unknown to Samba’s list of accounts.
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.
Site Administration 
