Samba password issues can be complicated. SMB/CIFS provides several different ways to encode passwords, to authenticate clients using passwords, and to store them. In fact, some of these issues are negotiated between client and server, with no need for explicit configuration, but others require your attention.

The simplest case of Samba password handling, at least from the point of view of Samba administration, is to have Samba accept unencrypted (or cleartext) passwords from clients and authenticate users against the local Linux account database. Conceptually, this works much like Linux authentication for FTP, Telnet, SSH, or other servers that use the Linux account database. Unfortunately, this approach has some problems. Most importantly, exchanging passwords in cleartext makes them vulnerable to sniffing—interception by unauthorized third parties who have physical access to your network wires. (In an Internet exchange, sniffing can also occur on intervening routers or their networks.) Thus, unencrypted passwords are undesirable from a security point of view. (On the other hand, the password encryption systems used by some versions of SMB/CIFS are not much better than cleartext, so you shouldn’t consider encrypted passwords to be proof against sniffing.) In terms of practicality, cleartext passwords are also a problem because recent versions of Windows use encrypted passwords by default and don’t drop back to cleartext passwords. Although you can reconfigure Windows clients to use cleartext passwords, doing so on a large network can be tedious.

So, what about encrypted passwords? Unfortunately, the password encryption systems used by SMB/CIFS aren’t compatible with the encrypted form of Linux passwords used in a standard Linux password database (/etc/passwd or, more commonly, /etc/shadow). Therefore, in order to support SMB/CIFS encrypted passwords, Samba must maintain its own password database. Typically, this database is stored in a file called smbpasswd and is located in the same directory as smb.conf or a subdirectory of that directory. Other methods of storing this database exist but are beyond the scope of this book. If you want to use encrypted passwords, you must not only configure Samba to use them but create the encrypted password file, populate it with account information, and assign passwords to users. Because the Linux passwords are stored in a hash (basically, a one-way encryption system), they can’t be decrypted, and you’ll need to either assign random Samba passwords to users or have them enter passwords in some way. This task can be tedious on a large network.

A third approach to handling passwords is to defer to another computer. For instance, if your network is configured as a Windows NT domain or an AD domain, you can have Samba defer to the domain controller. This approach greatly simplifies Samba setup because you don’t need to configure a local password database. Samba provides several options for how to defer to a remote system.

No matter what method you use, each user of your system must have a local account. (Using guest accounts can relax this restriction, but this topic is beyond the scope of this book.) Thus, you must still create local Linux accounts even if you use a Windows domain controller for authentication. If this task is tedious because you have many users, you may want to consult Chapter 7, which describes joining a Linux system to an NT domain in a way that enables the underlying Linux accounts to mirror the NT domain’s accounts. Although this configuration can be a bit tricky to set up, it can greatly simplify account maintenance on a large network that has an NT domain controller (either a Windows system or a Samba server).

From a Samba configuration perspective, the simplest authentication method is to use cleartext passwords. You can do so by setting encrypt passwords = No in the [global] section of smb.conf. This configuration is the default in Samba versions prior to 3.0; however, with Version 3.0, the default setting changed to Yes. To avoid confusion, I recommend setting the value explicitly, whatever version of Samba you’re using. When configured to use cleartext passwords, Samba doesn’t attempt to negotiate an encrypted password exchange with clients; it does attempt to authenticate users against the passwords stored in the local Linux password database. Thus, users must have valid local Linux passwords, not just valid accounts. (With encrypted passwords, Samba users’ accounts could conceivably exist but have disabled local passwords.)

Windows versions since Windows 95 OEM Service Release 2 (OSR2) and Windows NT 4.0 Service Pack 3 (SP3) require the use of encrypted passwords by default. Thus, these OSs will not work with a Samba server configured to use cleartext passwords unless you change a Windows Registry entry. One relatively painless way to do so is to use a .reg file that ships with Samba. In fact, several such files exist, one for each version of Windows. The filename takes the form Win Ver_PlanPassword.reg, where Ver is the Windows version. For instance, Win2000_PlainPassword.reg is the file for Windows 2000, and WinXP_PlainPassword.reg does the job for Windows XP. Some distributions deliver these files in compressed form, so .gz may be tacked onto the end; if so, you’ll need to uncompress the file with gunzip before you use it. Precisely where you can find these files also varies. Most place them in the Registry subdirectory of the Samba documentation directory, as in /usr/share/doc/samba-3.0.2a/full_docs/Registry, but the precise path varies.

Once you’ve located these files, copy the ones you need to a floppy disk, put them on an FTP site, send them via email, or otherwise make them accessible to clients. On a Windows system, double-click the file from the file manager to install the changes in the Registry. You then need to reboot the computer for the changes to take effect. In a small office, you should be able to apply the patch to all the Windows clients in a few minutes by walking from one system to another with a floppy disk in your hand. Alternatively, you can make the changes manually using a Windows Registry editor; however, applying the changes automatically is almost certain to be both faster and more reliable.

Once you’ve configured the Samba server and your clients to use cleartext passwords, the clients should be able to access the server, assuming appropriate accounts with valid passwords exist on the server. However, a few additional parameters can affect access:

On the whole, using cleartext passwords is normally undesirable on modern networks. Between the increased risks of password sniffing with cleartext passwords, and the fact that most modern SMB/CIFS clients don’t use them by default, you’re usually better off switching to an encrypted password system or to a password server. Encrypted passwords can be more of a hassle to configure on the Samba server, but they’re easier to configure on the clients.

Because all modern versions of Windows use encrypted passwords by default, this approach is the easiest one from a client configuration point of view. You will, though, need to take some steps to get encrypted passwords working on the server.

Only one smb.conf entry needs changing to use encrypted passwords: encrypt passwords = Yes. This is the default value for Samba 3.0 and later, but earlier versions used No as the default, so I recommend setting it explicitly to avoid confusion. A few other parameters can influence how Samba treats encrypted passwords, but they probably don’t need adjustment:

In addition to setting encrypt passwords = Yes and, if desired, any ancillary password-related parameters, you must prepare a local Samba password database. This database is maintained using the smbpasswd command. In particular, you add users to the database using the -a parameter (which can only be used as root):

# smbpasswd -a linnaeus
New SMB password:
Retype new SMB password:
Added user linnaeus

This command adds a Samba password entry for the user linnaeus. If your system lacks a current smbpasswd file or its equivalent, you’ll see an error message to the effect that it doesn’t exist; but don’t fear, the smbpasswd utility creates the file and adds the user to it. In any event, you should repeat this command for every user on your system. Note that Samba requires the username to match an existing Linux account, so if you’re configuring a new system, you should create a Linux account first, and then create a Samba password database entry for it.

Running smbpasswd in this way isn’t very difficult for a network with just a few users, but on a larger network, it can be quite tedious. If you want to script the operation, you can deliver a password to the utility within a script by appending the password to the username, separated by a percent symbol (%):

smbpasswd -a linnaeus%apassword

Of course, your script will need to generate passwords in some (preferably random) way. You’ll then need to either communicate this information to your users or help them enter their passwords later. Another option is to use a script called mksmbpasswd, mksmbpasswd.sh, or something similar. These scripts create a new smbpasswd file from your regular Linux passwd database. Such scripts used to ship with Samba packages, but they’re less common today, perhaps because they save very little time. The scripts can’t convert Linux passwords to a form that SMB/CIFS can use, so they deliberately generate accounts with invalid passwords. Thus, you must still help users enter their encrypted passwords manually.

In theory, the global update encrypted parameter can help you enter encrypted passwords. When set to Yes, this parameter causes Samba to set a user’s encrypted password to the value of an unencrypted password that a client computer sends when the user logs on. Unfortunately, this requires you to configure your clients to send unencrypted passwords. Thus, although update encrypted might help you convert a network from cleartext to encrypted passwords, it won’t be of much help when adding a new Linux system to an existing network that already uses encrypted passwords.

The case options described earlier, in Section 3.5.2, are inapplicable to encrypted passwords. Depending on the hash chosen by the client, passwords may be case-sensitive or -insensitive, and Samba provides the same case sensitivity as clients. Thus, in this respect encrypted passwords are simpler than unencrypted passwords.

The smbpasswd command can be used to change passwords for existing accounts, as well as create new ones. Type smbpasswd username, where username is the username whose password you want to change, to do the job. Individual users can also use this utility to change their passwords, but they must have shell access to the server to do so.

Instead of using a local password database, you can defer authentication to another computer—typically a domain controller, but perhaps some other system. In fact, Samba provides three different ways to do this. You choose the method using the security parameter, but depending upon the method you choose, you may need to perform some additional configuration steps.

All these methods of authentication require you to set encrypt passwords = Yes. Instead of maintaining the account database locally, though, you point Samba at an external server.

security = Server
password server = 172.24.21.98

security = Domain
password server = 172.24.21.98

# net join member -U 
                     adminuser