Section 5.1. Security Modes


5.1. 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.

[*] The term security level refers to the capabilities of the SMB/CIFS protocol and the term security mode describes Samba's various implementations of the SMB/CIFS security levels.

Table 5-1. Samba's security modes

Parameter

Value

Description

Default

Scope

security

user (Chapter 5)

ads (Chapter 10)

domain (Chapter 10)

share (deprecated)

server (deprecated)

Authentication model used to validate incoming requests.

user

Global


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.


5.1.1. Guest Access with security = 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 (\\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 guest account is allowed access to this share.

no

Share

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 nonguest access. The map to guest option can have different values in each virtual server configuration.

5.1.2. 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.

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.


5.1.2.1. 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.

If your server's operating system uses DES password hashes, setting a password level of 8 characters effectively makes the passwords case-insensitive, because DES limits the password to 8 characters.


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.

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.

0

Global


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:


auth

User authentication requests


account

User account handling, such as password expiration and denying locked accounts


session

User management related to this specific session, such as logging user activity to the system's utmp file


password

User password change requests

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.

Table 5-5. PAM-related parameters

Parameter

Value

Description

Default

Scope

obey pam restrictions

boolean

Controls whether smbd respects the account and session PAM configuration settings.

no

Global

pam password change

boolean

If enabled, smbd will, upon receiving a password change request, use PAM for synchronizing a user's Unix credentials.

no

Global


5.1.2.3. NTLMv1

NTLM 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:

[*] Details of NTLM and other authentication protocols used by CIFS can be found at Chris Hertel's site http://ubiqx.org/cifs.

  • The hashed password is never sent over the wire.

  • The user's password hash is a shared secret used to calculate the response. If the client's and the server's calculated response match, it proves that both knew the same initial password hash.

  • Both the LanManager and NT password hashing algorithms do not use any salt. Therefore a string always produces the same LanMan and NT hashes.

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.

Table 5-6. NTLMv1-related parameters

Parameter

Value

Description

Default

Scope

encrypt passwords

boolean

Controls whether Samba advertises support for NTLM authentication.

yes

Global

lanman auth

boolean

Determines whether smbd should attempt to validate NTLM responses using the LanManager password hash.

yes

Global


5.1.2.4. NTLMv2

NTLMv2 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.

Table 5-7. NTLMv2-related parameters

Parameter

Value

Description

Default

Scope

ntlm auth

boolean

Controls whether Samba should validating using the NTLMv1 24-byte response. This parameter should be disabled, along with the lanman auth option, to enforce use of NTLMv2.

yes

Global





Using Samba
Using Samba: A File and Print Server for Linux, Unix & Mac OS X, 3rd Edition
ISBN: 0596007698
EAN: 2147483647
Year: 2004
Pages: 135

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net