Наши партнеры

Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

Chapter 9. Users and Security

In this chapter, we cover the basic concepts of managing security in Samba so that you can set up your Samba server with a security policy suited to your network.

One of Samba's most complicated tasks lies in reconciling the security models of Unix and Windows systems. Samba must identify users by associating them with valid usernames and groups, authenticate them by checking their passwords, then control their access to resources by comparing their access rights to the permissions on files and directories. These are complex topics on their own, and it doesn't help that there are three different operating system types to deal with (Unix, Windows 95/98/Me, and Windows NT/2000/XP) and that Samba supports multiple methods of handling user authentication.

Users and Groups

Let's start out as simply as possible and add support for a single user. The easiest way to set up a client user is to create a Unix account (and home directory) for that individual on the server and notify Samba of the user's existence. You can do the latter by creating a disk share that maps to the user's home directory in the Samba configuration file and restricting access to that user with the valid users option. For example:

[dave]
        path = /home/dave
        comment = Dave's home directory
        writable = yes
        valid users = dave

The valid users option lists the users allowed to access the share. In this case, only the user dave is allowed to access the share. In some situations it is possible to specify that any user can access a disk share by using the guest ok parameter. Because we don't wish to allow guest access, that option is absent here. If you allow both authenticated users and guest users access to the same share, you can make some files accessible to guest users by assigning world-readable permissions to those files while restricting access to other files to particular users or groups.

When client users access a Samba share, they have to pass two levels of restriction. Unix permissions on files and directories apply as usual, and configuration parameters specified in the Samba configuration file apply as well. In other words, a client must first pass Samba's security mechanisms (e.g., authenticating with a valid username and password, passing the check for the valid users parameter and the read only parameter, etc.), as well as the normal Unix file and directory permissions of its Unix-side user, before it can gain read/write access to a share.

Remember that you can abbreviate the user's home directory by using the %H variable. In addition, you can use the Unix username variable %u and/or the client username variable %U in your options as well. For example :

[dave]
    comment = %U home directory
    writable = yes
    valid users = dave
    path = %H

With a single user accessing a home directory, access permissions are taken care of when the user account is created. The home directory is owned by the user, and permissions on it are set appropriately. However, if you're creating a shared directory for group access, you need to perform a few more steps. Let's take a stab at a group share for the accounting department in the smb.conf file:

[accounting]
    comment = Accounting Department Directory
    writable = yes
    valid users = @account
    path = /home/samba/accounting
    create mode = 0660
    directory mode = 0770

The first thing we did differently is to specify @account as the valid user instead of one or more individual usernames. This is shorthand for saying that the valid users are represented by the Unix group account. These users will need to be added to the group entry account in the system group file ( /etc/group or equivalent) to be recognized as part of the group. Once they are, Samba will recognize those users as valid users for the share.

In addition, you need to create a shared directory that the members of the group can access and point to it with the path configuration option. Here are the Unix commands that create the shared directory for the accounting department (assuming /home/samba already exists):

# mkdir /home/samba/accounting
# chgrp account /home/samba/accounting
# chmod 770 /home/samba/accounting

There are two other options in this smb.conf example, both of which we saw in the previous chapter. These options are create mode and directory mode. These options set the maximum file and directory permissions that a new file or directory can have. In this case, we have denied all world access to the contents of this share. (This is reinforced by the chmod command, shown earlier.)

Handling Multiple Individual Users

Let's return to user shares for a moment. If we have several users for whom to set up home directory shares, we probably want to use the special [homes] share that we introduced in Chapter 8. With the [homes] share, all we need to say is:

[homes]
    browsable = no
    writable = yes

The [homes] share is a special section of the Samba configuration file. If a user attempts to connect to an ordinary share that doesn't appear in the smb.conf file (such as specifying it with a UNC in Windows Explorer), Samba will search for a [homes] share. If one exists, the incoming share name is assumed to be a username and is queried as such in the password database ( /etc/passwd or equivalent) file of the Samba server. If it appears, Samba assumes the client is a Unix user trying to connect to his home directory.

As an illustration, let's assume that sofia is attempting to connect to a share called [sofia] on the Samba server. There is no share by that name in the configuration file, but a [homes] share exists and user sofia is present in the password database, so Samba takes the following steps:

  1. Samba creates a new disk share called [sofia] with the path specified in the [homes] section. If no path option is specified in [homes], Samba initializes it to her home directory.

  2. Samba initializes the new share's options from the defaults in [globals], as well as any overriding options in [homes] with the exception of browsable.

  3. Samba connects sofia's client to that share.

The [homes] share is a fast, painless way to create shares for your user community without having to duplicate the information from the password database file in the smb.conf file. It does have some peculiarities, however, that we need to point out:

As we mentioned, there is no need for a path statement in [homes] if the users have Unix home directories in the server's /etc/passwd file. You should ensure that a valid home directory does exist, however, as Samba will not automatically create a home directory for a user and will refuse a tree connect if the user's directory does not exist or is not accessible.

Controlling Access to Shares

Often you will need to restrict the users who can access a specific share for security reasons. This is very easy to do with Samba because it contains a wealth of options for creating practically any security configuration. Let's introduce a few configurations that you might want to use in your own Samba setup.

We've seen what happens when you specify valid users. However, you are also allowed to specify a list of invalid users—users who should never be allowed access to Samba or its shares. This is done with the invalid users option. We hinted at one frequent use of this option earlier: a global default with the [homes] section to ensure that various system users and superusers cannot be forged for access. For example:

[global]
    invalid users = root bin daemon adm sync shutdown \
                        halt mail news uucp operator
    auto services = dave peter bob

[homes]
    browsable = no
    writable = yes

The invalid users option, like valid users, can take group names, preceded by an at sign (@), as well as usernames. In the event that a user or group appears in both lists, the invalid users option takes precedence, and the user or group is denied access to the share.

At the other end of the spectrum, you can explicitly specify users who will be allowed superuser (root) access to a share with the admin users option. An example follows:

[sales]
        path = /home/sales
        comment = Sedona Real Estate Sales Data
        writable = yes
        valid users = sofie shelby adilia
        admin users = mike

This option takes both group names and usernames. In addition, you can specify NIS netgroups by preceding them with an @ as well; if the netgroup is not found, Samba will assume that you are referring to a standard Unix group.

Be careful if you assign administrative privileges to a share for an entire group. The Samba Team highly recommends you avoid using this option, as it essentially gives root access to the specified users or groups for that share.

If you wish to force read-only or read/write access on users who access a share, you can do so with the read list and write list options, respectively. These options can be used on a per-share basis to restrict a writable share or to grant write access to specific users in a read-only share, respectively. For example:

[sales]
        path = /home/sales
        comment = Sedona Real Estate Sales Data
        read only = yes
        write list = sofie shelby

The write list option cannot override Unix permissions. If you've created the share without giving the write-list user write permission on the Unix system, she will be denied write access regardless of the setting of write list.

Guest Access

As mentioned earlier, you can configure a share using guest ok = yes to allow access to guest users. This works only when using share-level security, which we will cover later in this chapter. When a user connects as a guest, authenticating with a username and password is unnecessary, but Samba still needs a way to map the connected client to a user on the local system. The guest account parameter can be used in the share to specify the Unix account that guest users should be assigned when connecting to the Samba server. The default value for this is set during compilation and is typically nobody, which works well with most Unix versions. However, on some systems the nobody account is not allowed to access some services (e.g., printing), and you might need to set the guest user to ftp or some other account instead.

If you wish to restrict access in a share only to guests—in other words, all clients connect as the guest account when accessing the share—you can use the guest only option in conjunction with the guest ok option, as shown in the following example:

[sales]
        path = /home/sales
        comment = Sedona Real Estate Sales Data
        writable = yes
        guest ok = yes
        guest account = ftp
        guest only = yes

Make sure you specify yes for both guest only and guest ok; otherwise, Samba will not use the guest account that you specify.

Access Control Options

Table 9-1 summarizes the options that you can use to control access to shares.

Table 9-1. Share-level access options

Option

Parameters

Function

Default

Scope

admin users

string (list of usernames)

Users who can perform operations as root

None

Share

valid users

string (list of usernames)

Users who can connect to a share

None

Share

invalid users

string (list of usernames)

Users who will be denied access to a share

None

Share

read list

string (list of usernames)

Users who have read-only access to a writable share

None

Share

write list

string (list of usernames)

Users who have read/write access to a read-only share

None

Share

max connections

numeric

Maximum number of connections for a share at a given time

0

Share

guest only (only guest)

Boolean

If yes, allows only guest access

no

Share

guest account

string (name of account)

Unix account that will be used for guest access

nobody

Share

admin users

This option specifies a list of users that perform file operations as if they were root. This means that they can modify or destroy any other user's files, regardless of the permissions. Any files that they create will have root ownership and will use the default group of the admin user. The admin users option allows PC users to act as administrators for particular shares. Be very careful when using this option, and make sure good password and other security policies are in place.

valid users, invalid users

These two options let you enumerate the users and groups who are granted or denied access to a particular share. You can enter a list of user and/or group names. If a name is prefixed by an at sign (@), it is interpreted as a group name—with NIS groups searched before Unix groups. If the name is prefixed by a plus sign (+), it is interpreted as the name of a Unix group, and NIS is not searched. If the name is prefixed by an ampersand (&), it is interpreted as an NIS group name rather than as a Unix group name. The plus sign and ampersand can be used together to specify whether NIS or Unix groups are searched first. For example:

[database]
    valid users = mary ellen sue &sales +marketing @dbadmin
    invalid users = gavin syd dana &techies +&helpdesk

In the valid users parameter, users mary, ellen, and sue are allowed access to the [database] share, as are the members of the Unix group marketing and NIS/Unix group dbadmin. The invalid users parameter denies access to the share by users gavin, syd, and dana, as well as members of the NIS group techies and Unix/NIS group helpdesk. In this last case, the list of Unix groups is searched first for the helpdesk group, and if it is not found there, the list of NIS groups is searched.

The important rule to remember with these options is that any name or group in the invalid users list will always be denied access, even if it is included (in any form) in the valid users list.

read list, write list

Like the valid users and invalid users options, this pair of options specifies which users have read-only access to a writable share and read/write access to a read-only share, respectively. The value of either options is a list of users. The read list parameter overrides any other Samba permissions granted—as well as Unix file permissions on the server system—to deny users write access. The write list parameter overrides other Samba permissions to grant write access, but cannot grant write access if the user lacks write permissions for the file on the Unix system. You can specify NIS or Unix group names by prefixing the name with an at sign (such as @users). Neither configuration option has a default value associated with it.

max connections

This option specifies the maximum number of client connections that a share can have at any given time. Any connections that are attempted after the maximum is reached will be rejected. The default value is 0, which is a special case that allows an unlimited number of connections. You can override it per share as follows:

[accounting]
    max connections = 30

This option is useful in the event that you need to limit the number of users who are accessing a licensed program or piece of data concurrently.

guest only

This share-level option (also called only guest) forces a connection to a share to be performed with the user specified by the guest account option. The share to which this is applied must explicitly specify guest ok = yes for this option to be recognized by Samba. The default value for this option is no.

guest account

This option specifies the name of the account to be used for guest access to shares in Samba. The default for this option varies from system to system, but it is often set to nobody. Some default user accounts have trouble connecting as guest users. If that occurs on your system, the Samba Team recommends using the ftp account as the guest user.

Username Options

Table 9-2 shows two additional options that Samba can use to correct for incompatibilities in usernames between Windows and Unix.

Table 9-2. Username options

Option

Parameters

Function

Default

Scope

username map

string (filename)

Sets the name of the username mapping file

None

Global

username level

numeric

Indicates the number of capital letters to use when trying to match a username

0

Global

username map

Client usernames on an SMB network can be relatively long (up to 255 characters), while usernames on a Unix network often cannot be longer than eight characters. This means that an individual user can have one username on a client and another (shorter) one on the Samba server. You can get past this issue by mapping a free-form client username to a Unix username of eight or fewer characters. It is placed in a standard text file, using a format that we'll describe shortly. You can then specify the pathname to Samba with the global username map option. Be sure to restrict access to this file; make the root user the file's owner and deny write access to others (with octal permissions of 744 or 644). Otherwise, an untrusted user with access to the file can easily map his client username to the root user of the Samba server.

You can specify this option as follows:

[global]
    username map = /usr/local/samba/private/usermap.txt

Each entry in the username map file should be listed as follows: the Unix username, followed by an equal sign (=), followed by one or more whitespace-separated SMB client usernames. Note that unless instructed otherwise (i.e., a guest connection), Samba will expect both the client and the server user to have the same password. You can also map NT groups to one or more specific Unix groups using the @ sign. Here are some examples:

jarwin = JosephArwin
manderso = MarkAnderson
users = @account

You can also use the asterisk to specify a wildcard that matches any free-form client username as an entry in the username map file:

nobody = *

Comments can be placed in the file by starting the line with a hash mark (#) or a semicolon (;).

Note that you can also use this file to redirect one Unix user to another user. Be careful, though, as Samba and your client might not notify the user that the mapping has been made and Samba might be expecting a different password.

username level

SMB clients (such as Windows) will often send usernames in SMB connection requests entirely in capital letters; in other words, client usernames are not necessarily case-sensitive. On a Unix server, however, usernames are case-sensitive: the user ANDY is different from the user andy. By default, Samba attacks this problem by doing the following:

  1. Checking for a user account with the exact name sent by the client

  2. Testing the username in all lowercase letters

  3. Testing the username in lowercase letters with only the first letter capitalized

If you wish to have Samba attempt more combinations of upper- and lowercase letters, you can use the username level global configuration option. This option takes an integer value that specifies how many letters in the username should be capitalized when attempting to connect to a share. You can specify this option as follows:

[global]
    username level = 3

In this case, Samba attempts all possible permutations of usernames having three capital letters. The larger the number, the more computations Samba has to perform to match the username, and the longer the authentication will take.

Authentication of Clients

At this point, we should discuss how Samba authenticates users. Each user who attempts to connect to a share not allowing guest access must provide a password to make a successful connection. What Samba does with that password—and consequently the strategy Samba will use to handle user authentication—is the arena of the security configuration option. Samba currently supports four security levels on its network: share, user, server, and domain.

Share-level security

Each share in the workgroup has one or more passwords associated with it. Anyone who knows a valid password for the share can access it.

User-level security

Each share in the workgroup is configured to allow access from certain users. With each initial tree connection, the Samba server verifies users and their passwords to allow them access to the share.

Server-level security

This is the same as user-level security, except that the Samba server uses another server to validate users and their passwords before granting access to the share.

Domain-level security

Samba becomes a member of a Windows NT domain and uses one of the domain's domain controllers—either the PDC or a BDC—to perform authentication. Once authenticated, the user is given a special token that allows her access to any share with appropriate access rights. With this token, the domain controller will not have to revalidate the user's password each time she attempts to access another share within the domain. The domain controller can be a Windows NT/2000 PDC or BDC, or Samba acting as a Windows NT PDC.

Each security policy can be implemented with the global security option, as shown in Table 9-3.

Table 9-3. Security option

Option

Parameters

Function

Default

Scope

security

domain, server, share, or user

Indicates the type of security that the Samba server will use

user

Global

Share-Level Security

With share-level security, each share has one or more passwords associated with it, with the client being authenticated when first connecting to the share. This differs from the other modes of security in that there are no restrictions as to whom can access a share, as long as that individual knows the correct password. Shares often have multiple passwords. For example, one password might grant read-only access, while another might grant read/write access. Security is maintained as long as unauthorized users do not discover the password for a share to which they shouldn't have access.

OS/2 and Windows 95/98/Me both support share-level security on their resources. You can set up share-level security with Windows 95/98/Me by first enabling share-level security using the Access Control tab of the Network Control Panel dialog. Then select the "Share-level access control" radio button (which deselects the "User-level access control" radio button), as shown in Figure 9-1, and click the OK button. Reboot as requested.

Figure 9-1. Selecting share-level security on a Windows 95/98/Me system

Next, right-click a resource—such as a hard drive or a CD-ROM—and select the Properties menu item. This will bring up the Resource Properties dialog box. Select the Sharing tab at the top of the dialog box, and enable the resource as Shared As. From here, you can configure how the shared resource will appear to individual users, as well as assign whether the resource will appear as read-only, read/write, or a mix, depending on the password that is supplied.

You might be thinking that this security model is not a good fit for Samba—and you would be right. In fact, if you set the security = share option in the Samba configuration file, Samba will still reuse the username/password combinations in the system password files to authenticate access. More precisely, Samba will take the following steps when a client requests a connection using share-level security:

  1. When a connection is requested, Samba will accept the password and (if sent) the username of the client.

  2. If the share is guest only , the user is immediately granted access to the share with the rights of the user specified by the guest account parameter; no password checking is performed.

  3. For other shares, Samba appends the username to a list of users who are allowed access to the share. It then attempts to validate the password given in association with that username. If successful, Samba grants the user access to the share with the rights assigned to that user. The user will not need to authenticate again unless a revalidate = yes option has been set inside the share.

  4. If the authentication is unsuccessful, Samba attempts to validate the password against the list of users previously compiled during attempted connections, as well as those specified under the share in the configuration file. If the password matches that of any username (as specified in the system password file, typically /etc/passwd ), the user is granted access to the share under that username.

  5. However, if the share has a guest ok or public option set, the user will default to access with the rights of the user specified by the guest account option.

You can indicate in the configuration file which users should be initially placed on the share-level security user list by using the username configuration option, as shown here:

[global]
    security = share

[accounting1]
    path = /home/samba/accounting1
    guest ok = no
    writable = yes
    username = davecb, pkelly, andyo

Here, when a user attempts to connect to a share, Samba verifies the sent password against each user in its own list, in addition to the passwords of users davecb, pkelly, and andyo. If any of the passwords match, the connection is verified, and the user is allowed. Otherwise, connection to the specific share will fail.

Share-Level Security Options

Table 9-4 shows the options typically associated with share-level security.

Table 9-4. Share-level access options

Option

Parameters

Function

Default

Scope

only user

Boolean

If yes, usernames specified by username are the only ones allowed

no

Share

username (user or users)

string (list of usernames)

Users against which a client's password is tested

None

Share

only user

This Boolean option indicates whether Samba will allow connections to a share using share-level security based solely on the individuals specified in the username option, instead of those users compiled on Samba's internal list. The default value for this option is no. You can override it per share as follows:

[global]
    security = share
[data]
    username = andy, peter, valerie
    only user = yes

username

This option presents a list of usernames and/or group names against which Samba tests a connection password to allow access. It is typically used with clients that have share-level security to allow connections to a particular service based solely on a qualifying password—in this case, one that matches a password set up for a specific user:

[global]
    security = share
[data]
    username = andy, peter, terry

You can enter a list of usernames and/or group names. If a name is prefixed by an at sign (@), it is interpreted as a group name, with NIS groups searched before Unix groups. If the name is prefixed by a plus sign (+), it is interpreted as the name of a Unix group, and NIS is not searched. If the name is prefixed by an ampersand (&), it is interpreted as an NIS group name rather than a Unix group name. The plus sign and ampersand can be used together to specify whether NIS or Unix groups are searched first. When Samba encounters a group name in this option, it attempts to authenticate each user in the group until if finds one that succeeds. Beware that this can be very inefficient.

We recommend against using this option unless you are implementing a Samba server with share-level security.

User-Level Security

The default mode of security with Samba is user-level security. With this method, each share is assigned specific users that can access it. When a user requests a connection to a share, Samba authenticates by validating the given username and password with the authorized users in the configuration file and the passwords in the password database of the Samba server. As mentioned earlier in the chapter, one way to isolate which users are allowed access to a specific share is by using the valid users option for each share:

[global]
    security = user

[accounting1]
    writable = yes
    valid users = bob, joe, sandy

Each user listed can connect to the share if the password provided matches the password stored in the system password database on the server. Once the initial authentication succeeds, the client will not need to supply a password again to access that share unless the revalidate = yes option has been set.

Passwords can be sent to the Samba server in either an encrypted or a nonencrypted format. If you have both types of systems on your network, you should ensure that the passwords represented by each user are stored both in a traditional account database and Samba's encrypted password database. This way, authorized users can gain access to their shares from any type of client.[1] However, we recommend that you move your system to encrypted passwords and abandon nonencrypted passwords if security is an issue. Section 9.4 of this chapter explains how to use encrypted as well as nonencrypted passwords.

Server-Level Security

Server-level security is similar to user-level security. However, with server-level security, Samba delegates password authentication to another SMB password server—typically another Samba server or a Windows NT/2000 server acting as a PDC on the network. Note that Samba still maintains its list of shares and their configuration in its smb.conf file. When a client attempts to make a connection to a particular share, Samba validates that the user is indeed authorized to connect to the share. Samba then attempts to validate the password by passing the username and password to the SMB password server. If the password is accepted, a session is established with the client. See Figure 9-2 for an illustration of this setup.

Figure 9-2. A typical system setup using server-level security

You can configure Samba to use a separate password server under server-level security with the use of the password server global configuration option, as follows:

[global]
    security = server
    password server = mixtec toltec

Note that you can specify more than one machine as the target of the password server; Samba moves down the list of servers in the event that its first choice is unreachable. The servers identified by the password server option are given as NetBIOS names, not their DNS names or equivalent IP addresses. Also, if any of the servers reject the given password, the connection automatically fails—Samba will not attempt another server.

One caveat: when using this option, you still need an account representing that user on the regular Samba server. This is because the Unix operating system needs a username to perform various I/O operations. The preferable method of handling this is to give the user an account on the Samba server but disable the account's password by replacing it in the system password file (e.g., /etc/passwd ) with an asterisk (*).

Domain-Level Security

With domain-level security, the Samba server acts as a member of a Windows domain. Recall from Chapter 1 that each domain has a primary domain controller, which can be a Windows NT/2000 or Samba server offering password authentication. The domain controller keeps track of users and passwords in its own database and authenticates each user when she first logs on and wishes to access another machine's shares.

As mentioned earlier in this chapter, Samba has a similar ability to offer user-level security, but that option is Unix-centric and assumes that the authentication occurs via Unix password files. If the Unix machine is part of an NIS or NIS+ domain, Samba authenticates users transparently against a shared password file in typical Unix fashion. Samba then provides access to the NIS or NIS+ domain from Windows. There is, of course, no relationship between the NIS concept of a domain and