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
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.
# 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.)
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 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:
The [homes] section can represent any account on the machine, which isn't always desirable. For example, it can potentially create a share for root, bin, sys, uucp, and the like. You can set a global invalid users option to protect against this.
The meaning of the browsable configuration option is different from other shares; it indicates only that a [homes] section won't show up in the local browse list, not that the [alice] share won't. When the [alice] section is created (after the initial connection), it will use the browsable value from the [globals] section for that share, not the value from [homes].
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.
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
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
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.
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.
[sales] path = /home/sales comment = Sedona Real Estate Sales Data writable = yes guest ok = yes guest account = ftp guest only = yes
Table 9-1 summarizes the options that you can use to control access to shares.
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 |
[database] valid users = mary ellen sue &sales +marketing @dbadmin invalid users = gavin syd dana &techies +&helpdesk
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.
Table 9-2 shows two additional options that Samba can use to correct for incompatibilities in usernames between Windows and Unix.
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 |
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
jarwin = JosephArwin manderso = MarkAnderson users = @account
nobody = *
Comments can be placed in the file by starting the line with a hash mark (#) or a semicolon (;).
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.
Each security policy can be implemented with the global security option, as shown in Table 9-3.
Option |
Parameters |
Function |
Default |
Scope |
---|---|---|---|---|
domain, server, share, or user |
Indicates the type of security that the Samba server will use |
user |
Global |
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.
[global] security = share [accounting1] path = /home/samba/accounting1 guest ok = no writable = yes username = davecb, pkelly, andyo
Table 9-4 shows the options typically associated with share-level security.
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 |
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
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 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.
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
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