Authentication is proving that you are who you say you are. You do this every day, during such activities as printing a document or saving a file to a network drive. When things are working correctly, the steps taken by a server to authenticate a request are often taken for granted. You enter a password, and it is used whenever the client machine needs to access a network resource on your behalf. Authentication is a prerequiste to authorization. Authorization is what the server does to verify that the authenticated user should (or should not) gain access to the requested resource (such as the printer or file share).

Chapter 1 described the basic steps necessary to connect to a share. The second step, after negotiating the protocol dialect, is the session setup, a packet exchange in which the client sends some proof of identify. This proof must be validated somehow. In this chapter, you will see how Samba can be configured to verify this request using a set of local user accounts. More advanced authentication environments involving domain controllers are covered in Chapters 9 and 10.

Security Modes

The SMB/CIFS protocol has two security levels: user and share. Samba implements these levels across five security modes defined by the global security parameter in smb.conf.* Only three of these values are relevant to modern Samba servers, all of which are variations of SMB/CIFS user-level authentication. In this chapter, we cover the details of security = user and local accounts. Chapter 10 presents the domain member server modes security=domain and security=ads . Table 5-1 lists the valid security modes as well as their current level of support from Samba developers.

Table 5-1. Samba’s security modes

Parameter

Value

Description

Default

Scope

security

user(Chapter 5)

Authentication model used to

user

Global

ads(Chapter 10)

validate incoming requests.

domain(Chapter 10)

share(deprecated)

server(deprecated)

What About the Other Two Security Modes?

The remaining two security modes, security= share and security=server , are historical artifacts from past releases. Both of these implementations are remnants of authentication models primarily used by Windows 9x and earlier hosts. Neither security mode offers functionality beyond that provided by the three recommended security values covered in this chapter. Furthermore, in many instances, the deprecated modes suffer from severe protocol limitations. For this and other reasons, there is a high chance that both will be removed from Samba at some future time. It is strongly suggested that you avoid these two values when building new servers.

{mospagebreak title=Guest Access with security equals user}

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 (\OAKpublic), 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:

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.

{mospagebreak title=Passwords and Authentication}

The proof of identity in the session setup request can take several forms. We group the mechanisms supported by Samba into three categories:

Clear-text passwords

NTLM and related challenge/response exchanges

Kerberos tickets

The first two areas are covered here. Kerberos authentication will be covered in the context of Active Directory domain membership in Chapter 10.

Security Modes

Dispelling the Myth of Windows and Encrypted Password Support

Much of Samba is surrounded by urban legends and common misunderstandings. One such myth is that older versions of Windows did not support password encryption or the NTLM
challenge/response authentication mechanism. The confusion arises from the behavior of pre-Windows NT 4.0 SP3 clients and the original versions of Windows 95. These clients would happily transmit the password’s clear text to a server if the negprot response indicated that password encryption was not supported. Such behavior is open to abuse, as you can imagine.

The result was that Microsoft decided that Windows clients must refuse to downgrade to sending clear-text passwords to servers that report lack of support for NTLM. This move was valid, as all Microsoft servers have long supported NTLM. Samba has also supported NTLM for many years, but it was not the default password setting until the 3.0.0 release.

All recent Microsoft clients, including the MS-DOS LanMan client, Windows for Workgroups, and the original Windows 95 releases, prefer to use encrypted passwords if supported by the server. Therefore, if you change a Samba host from encrypt passwords = no to yes , Windows clients automatically begin to use the NTLM authentication algorithm. You might want to configure the clients to never downgrade to clear-text authentication at this point, just to prevent clever attackers masquerading as SMB/CIFS servers. But no client-side changes are required to have the new server functionality utilized.

{mospagebreak title=Clear-text passwords}

Using clear-text passwords has many disadvantages in modern networks. The lack of security is the most serious of these; plus, no current CIFS clients support this in their default configurations. But clear-text authentication has one alluring feature that still entices some systems administrators even today: having smbd authenticate users against an NIS map or local /etc/passwd file.

Samba’s domain controller functionality cannot be used with encrypt passwords = no .

If you choose this route, the first requirement is to configure the Windows clients to send the clear-text password, which can be done by importing the appropriate file from the docs/registry/ directory of the Samba source distribution into the client’s local registry. The operating system name is part of the filename. So for a Windows XP client, use the file called WinXP_PlainPassword.reg. After you import the correct file, a reboot of the client is required to make the change effective.

The second step is to set encrypt passwords = no in the [global] section of smb.conf. This setting instructs Samba to ignore any smb.conf passdb backend directives when authenticating users, and instead to validate each user by hashing the transmitted password and comparing it against the entry returned from the system account list.

There are a few subtleties of which you should be aware. Although Windows NT-based clients send the clear text password as it was typed by the user, Windows 9x/Me hosts do not. These clients transmit the clear-text password in all uppercase. You must inform Samba as to how many permutations of that password it should attempt to validate before giving up and reporting failure. The password level option accepts a positive numeric value that represents the maximum number of uppercase letters in password test cases. For example, if the client transmitted a password of “cow,” a password level of 1 would result in the follow variations being tested: COW, cow, Cow, cOw, and coW. The first two combinations shown are tried irrespective of the password level. Samba always tries the password as transmitted first, followed by an all-lowercase version and an all-uppercase version of the string (assuming the originally transmitted password had mixed case). The password level option defaults to 0, because as the number of combinations to be tested increases, a proportional amount of CPU and time is needed for the authentication process.

Here is a basic smb.conf that allows users to authenticate against /etc/passwd, as long as passwords contain at most four uppercase characters. If there are no users with Windows 9x/Me clients that will require access to the server, the password level option can be removed altogether.

[global]encrypt passwords = nopassword level = 4

In some extreme cases, it may be necessary to have Samba perform the same type of case permutations to a user’s login name, because Windows 9x/Me clients also convert the login name to uppercase before sending to the server. Unix platforms have historically presented usernames as case-sensitive. This is yet another point of contention between Windows and Unix hosts. Internally, Samba first looks for the name in all lowercase, as this is the most common case on Unix hosts, followed by string as transmitted from the client, and finally in all uppercase. If no user by any of the names can be found, Samba then attempts a round of upper- and lowercase combinations controlled by the value of username level . Only when a user’s name is stored in mixed case in the server’s list of accounts should you even consider changing the username level from its default of 0.

The username and password level options are summarized in Table 5-4.

Table 5-4. Username- and password-level parameters

Parameter

Value

Description

Default

Scope

password level

integer

Number of case permutations to test when validating a clear text password.

0

Global

username level

integer

Number of case permutations to test when searching for the login name sent in a connection request.