Using Samba: A File and Print Server for Linux, Unix & Mac OS X, 3rd Edition

2.5. A Basic Samba Configuration File

The key to configuring Samba is its configuration file, smb.conf. This configuration file can be very simple or extremely complex, and the rest of this book is devoted to helping you get deeply personal with this file. For now, however, we'll show you how to set up a single file service, which will allow you to fire up the Samba daemons and see that everything is running as it should be. In later chapters, you will see how to configure Samba for more complicated and interesting tasks.

The installation process does not automatically create an smb.conf configuration file, although several example files are included in the Samba distribution in the samba-3.0.x/examples/ directory. To test the server software, we'll use the following file, which you can create in a text editor of your choosing. It should be named smb.conf and placed in the /usr/local/samba/lib directory:^[*]

^[*] If you did not compile Samba, but instead downloaded a binary, check with the documentation for the package to find out where it expects the smb.conf file to be. Or, check the output from smbd -b and locate the value of the CONFIGFILE variable. If Samba came preinstalled with your Unix system, an smb.conf file is probably already somewhere on your system.

[global] workgroup = GARDEN [test] comment = For testing only, please path = /export/tmp read only = no

This brief configuration file tells the Samba server to offer the /export/tmp directory on the server as an SMB share called test. Parameters in smb.conf are case-insensitivepath is the same option as PATH. They are also whitespace-insensitive so that read only and ReadOnly are interpreted as the same parameter. Values, however, may or may not be case-insensitive, depending on their use. For example, a username or a directory path should be considered to be case-sensitive, yet Samba interprets Boolean value such as yes or no as case-insensitive strings.

Our server will operate as part of the GARDEN workgroup, of which each client should also be a part. If you have already chosen a name for your own workgroup, use the existing name instead of GARDEN in the previous example. In case you are connecting your server to an existing network and need to know the workgroup name, ask another system administrator or go to a Windows system in the workgroup and follow these instructions for Windows 2000/XP/2003:

• Right click on My Computer icon and select Properties.

• The workgroup or domain name should be listed in the windows after selecting the Network Identification (or Computer Name) tab.

We'll use the [test] share in the next chapter to set up the Windows clients. For now, you can complete the setup by performing the following commands as root on your Unix server:

# mkdir -p /export/tmp # chmod 1777 /export/tmp

If the version of mkdir included on your system doesn't support creating a full directory path (-p), just create each directory one by one. You might also want to put a file or two in the /export/tmp directory, so that after the Windows clients are initially configured, it will be easier to verify that that everything works.

2.5.1. Encrypted Passwords

Password encryption is one of those areas where interoperability between Windows and Unix/Linux systems gets extremely messy. Both sides of the fence use a different nonreversible encryption algorithm, which means that you cannot generically convert Unix passwords to the LanMan or NT password hashes or vice versa.

There is even widespread misunderstanding about Windows support for password encryption and the associated NTLM challenge/response authentication protocol. The myth is that Microsoft added support for encrypted passwords only with the release of the Windows 95 network redirector update and Windows NT 4 Service Pack 3. The truth is that all Microsoft operating systems (including the DOS LanMan client) support NTLM authentication and therefore support at least one of these password encryption algorithms, either the LanManager or the NT password hashes. The misunderstanding stems from the fact that prior to these operating system updates, Windows clients would downgrade to sending the clear text of a password if the remote SMB/CIFS server did not support password encryption. Of course, there are ways to exploit this behavior and gain access to users' passwords. Therefore, Microsoft decided that it was a good idea to disable the capability to automatically fall back to clear text authentication. It can still be done, even on Windows 2003, but requires a registry setting change and a client reboot.

Samba 3.0 follows this same path to interoperability. Because Windows clients no longer send clear text passwords without explicit configuration changes, Samba defaults to requiring that you, as the administrator, create LanMan and NT password hashes for all the users who will be accessing your server. But as there is no way to convert the existing /etc/passwd entries to Samba's password format, you have to start from scratch.

Samba does support authenticating users against the system's /etc/passwd file, NIS passwd map, and PAM stack, but you must ensure that all clients have clear text authentication for CIFS connections enabled. As previously noted, this is not the default behavior in modern Microsoft clients. Additional mechanisms for authenticating users are presented in Chapter 5.

By default, Samba 3.0 enables the encrypt passwords option. For the sake of clarity, and because you may not be familiar with all of Samba's default settings, we add the following line to our smb.conf in the [global] section.

encrypt passwords = yes

The smbpasswd program (typically located in the directory /usr/local/samba/bin/ ) can be used to enter the username/password combinations of the Samba users into Samba's encrypted password database. For example, to allow Unix user lizard to access shares from a client system, use this command:

# smbpasswd -a lizard New SMB password: <enter password for lizard> Retype new SMB password: <re-enter password for lizard> Added user lizard.

When the first user is added, the program may output a message saying that the encrypted password database does not exist. Don't worry: it will then create the database for you. Make sure that the username/password combinations you add to the encrypted database match the usernames and passwords that you intend to use on the Windows client side. You must run smbpasswd for each client user that will authenticated access to the server. There are simpler ways to configure a server to allow guest access, which we explore in Chapter 5.

2.5.2. Using SWAT to Create an smb.conf File

Creating a configuration file with SWAT is even easier than writing a configuration file by hand. To invoke SWAT, use your web browser to connect to http://localhost:901/, and log on as root with the root password, as shown in Figure 2-1.

After logging in, click the GLOBALS icon at the top of the screen. You should see the Global Parameters page shown in Figure 2-2.

In this example, notice that SWAT retrieved the workgroup name from the smb.conf file that you created. (If it didn't, go back and perform that step correctly.) Make sure that the security field is set to USER (the default).

The only other option you need to change from the menu is one determining which system on the LAN resolves NetBIOS addresses; this system is called the WINS server. At the very bottom of the page, set the wins support field to Yes, unless you already have a WINS server on your network. If you do, put the WINS server's IP address in the wins server field instead. Then return to the top of the screen, and press the Commit Changes button to write the changes out to the smb.conf file. If your Samba server and clients are all on a single broadcast subnet (i.e., if they all have the same broadcast address), you can ignore the WINS settings for now.

Next, click the SHARES icon. Select test (to the right of the Choose Share button), and click the Choose Share button. You will see the Share Parameters screen, as shown in Figure 2-3, with the comment and path fields filled in from your smb.conf file.

If you specified that you want to use encrypted passwords on the GLOBALS page, click the PASSWORD icon. Near the top of the screen is the Server Password Management section. Enter your Unix username and password in the spaces, and click the Add New User button. This step functions the same as the smbpasswd utility and creates an entry in the /usr/local/samba/private/smbpasswd file to allow you to authenticate from a Windows client.

Now click the VIEW icon at the top; SWAT then shows you the following smb.conf file:

# Samba config file created using SWAT # from localhost (127.0.0.1) # Date: 2005/06/27 09:56:43 # Global parameters [global] workgroup = GARDEN [test] comment = For testing only! path = /export/tmp read only = No

Notice that the encrypt passwords option is not listed, because SWAT does not write parameters with default settings to the configuration file. Once this configuration file is completed, you can skip the "Testing the Configuration File" step, because the output of SWAT is guaranteed to be syntactically correct.

2.5.3. Testing the Configuration File

If you didn't use SWAT to create your configuration file, you should probably test it to ensure that it does not contain any syntax errors. It might seem silly to run a test program against a six-line configuration file, but it's good practice for the longer, more complex ones that we'll be writing later on.

The parser, testparm, examines an smb.conf file for syntax errors and reports any it finds along with a list of the services enabled on your machine. An example follows; you'll notice that in our haste to get the server running, we mistyped workgroup as workgrp (the output can be lengthy, so again it is best to use some type of filter or pager):

$ testparm -s /usr/local/samba/lib/smb.conf | more Load smb config files from /usr/local/samba/lib/smb.conf Unknown parameter encountered: "workgrp" Ignoring unknown parameter "workgrp" Processing section "[test]" Loaded services file OK. # Global parameters [global] [test] comment = For testing only! path = /usr/local/samba/tmp read only = No

Samba 3.0 displays a brief listing of the configuration file. In fact, this is identical to how SWAT will strip the file and display it.