Section 5.1. Security Modes
5.1. Security ModesThe 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.
5.1.1. Guest Access with security = userWe 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.
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 nonguest access. The map to guest option can have different values in each virtual server configuration. 5.1.2. Passwords and AuthenticationThe proof of identity in the session setup request can take several forms. We group the mechanisms supported by Samba into three categories:
The first two areas are covered here. Kerberos authentication will be covered in the context of Active Directory domain membership in Chapter 10.
5.1.2.1. Clear-text passwordsUsing 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.
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 = no password 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.
5.1.2.2. Pluggable Authentication Modules (PAM)Pluggable Authentication Modules (PAM) are shared libraries that can be used in combination to allow an administrator to enforce a specific authentication security policy. For a complete discussion of PAM, first try searching your server's operating system documentation. Another good source of information is the Linux PAM web site at http://www.kernel.org/pub/linux/libs/pam. Each PAM module implements one or more of the following functions:
Samba is able to use PAM to authenticate users and enforce certain authorization controls based on the the configuration of the samba PAM service. On some platforms, such as Solaris, all services are configured in a single configuration file named /etc/pam.conf. On Linux hosts, these settings will be stored in /etc/pam.d/samba. The following configuration instructs the PAM library to verify that the server is not rejecting logins (i.e., the /etc/nologin file does not exist) and then validate the user against /etc/passwd: ## /etc/pam.d/samba auth requisite pam_nologin.so auth require pam_unix.so Our focus is not on PAM configuration specifics, but rather on how Samba, and smbd in particular, interacts with PAM. First it is necessary to verify that Samba was compiled to include the --with-pam configure option. The build output from smbd -b should include the WITH_PAM string if this is the case. $ smbd -b | grep WITH_PAM WITH_PAM If this check fails, return to Chapter 2 and rebuild Samba to include PAM support. You may also need to install additional software to get the PAM development files (e.g., the pam-devel package). Once you have a PAM-aware version of smbd, it will require a properly configured /etc/pam.d/samba file. Samba makes use of the auth settings in its PAM configuration file only if clients use clear-text passwords. If the encrypt passwords parameter has been enabled, the auth PAM module lines are ignored completely. However, it is possible to still make use of the remaining three PAM functions. The account and session settings are respected if the obey pam restrictions options is enabled in smb.conf. Any user password change requests that must be synchronized between Samba's and the operating system's list of users will pass through the PAM stack if pam password change = yes. Password synchronization is covered later in this chapter, so we will delay the complete discussion until then. Table 5-5 summarizes these two options and their default settings.
5.1.2.3. NTLMv1NTLM is the challenge/response authentication algorithm developed by Microsoft and utilized by Windows and other CIFS clients and servers. In the original implementations of NTLM, the client uses a hashed version of the user's password to generate a 24-byte response to a challenge returned by the server in the negotiate protocol reply. The actual details of the algorithm are not important from the point of view of a systems administrator.[*] The key facts to remember are:
The last point is important to remember, because it implies that the password hash is a plain-text equivalent. If an attacker were to uncover a user's password hash, he could impersonate that user without deriving the original clear-text string. Even so, many users reuse a single password for multiple services (email, banking accounts, and so on). Given that the LanMan password is limited to 14 uppercase characters and possesses a very weak hashing algorithm, protecting Samba's account database becomes extremely important. Enabling NTLMv1 authentication in Samba is as simple as setting encrypt passwords = yes in the [global] section of smb.conf and then creating user accounts using either smbpasswd or the pdbedit utility, introduced in Chapter 2. When adding a new user, if the password is less than or equal to 14 characters in length, Samba stores two password hashes. Following is an entry from an smbpasswd file for a user named lizard with a password of test. The first string of hexadecimal digits is the LanMan hash followed by the NT password hash. Each field is separated by a colon. The line has been wrapped due to space limitations and appears as one line in your smbpasswd file. lizard:1004:01FC5A6BE7BC6929AAD3B435B51404EE: 0CB6948805F797BF2A82807973B89537:[U ]:LCT-44528BD2: If the user's password is longer than 14 characters, the LanMan hash is disabled so that the security value of the password is not degraded by storing a truncated version. A disabled password is represented by a string of Xs. This is what lizard's smbpasswd entry would look like with a password of somepasswordstringlongerthanfourteen: lizard:1009:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: 0FF1DFDA18B63EC50E1FD9ECFCDFDE05:[U ]:LCT-44528C6B: It is possible to disable a Samba server's use of LanManager passwords altogether by setting the lanman auth option to no in the [global] service. Table 5-6 summarizes the smb.conf parameters related to NTLMv1 authentication.
5.1.2.4. NTLMv2NTLMv2 is a variant of the original NTLM authentication scheme, and was introduced in Windows NT 4.0 SP4. However, it has seemed to gain any semblance of widespread adoption only in conjunction with Active Directory deployments. Its main advantage over NTLMv1 is protection against man-in-the-middle and replay attacks. As with NTLMv1, the actual protocol details are unimportant for day-to-day system administration duties. Supporting NTLMv2 on Samba servers is a process of disabling support for the older authentication protocols. The following [global] section snippet illustrates the use of the lanman auth and ntlm auth parameters: [global] ## Enable support for only NTLMv2 on the server encrypt passwords = yes lanman auth = no ntlm auth = no Unlike many other client and server capabilities, support for NLTMv2 cannot be negotiated. If a client sends an NTLMv2 response, Samba always uses that. However, unless the older, less secure authentication schemes are disabled on the clients as well, NTLMv2 does very little to help improve the overall security of a system, primarily because both the NTLMv1 and NTLMv2 client responses are created using the NT password hash. The situation is comparable to restricting 9 out of your 10 hosts to SSH access but allowing Telnet access to the remaining tenth host. Security is only as strong as its weakest link. Table 5-7 summarizes the parameters needed to restrict access to using NTLMv2 authentication only.
|
EAN: 2147483647
Pages: 135