Section 3.5. Setting Password Options

3.5. Setting Password Options

New Samba installations are frequently plagued by two problems: incorrectly set workgroup names and password encryption difficulties. The first problem is easily corrected by changing the workgroup parameter, as described earlier. Password problems are harder to overcome because they may require changing more than just one or two Samba parameters. To address these issues, you must first understand them. You must then decide whether to use unencrypted or encrypted passwords. On some networks, you may need to decide whether to use a password server for authentication, as well.

3.5.1. Password Issues

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 sniffinginterception 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).

3.5.2. Using Cleartext Passwords

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

Try using your distribution's package management tools to locate these files. For instance, on a computer that uses the RPM Package Manager (RPM), you could type rpm -ql samba | grep PlainPassword to locate the files in the samba package that contain the string PlainPassword in their names.

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:

password level

Linux's local passwords are case-sensitive, but many SMB/CIFS clients assume passwords will be treated in a case-insensitive way. For instance, Windows 9x/Me converts all passwords to uppercase when using certain SMB/CIFS protocol levels. In order to work around this problem, the global password level parameter tells Samba to try case variants. The default value for this parameter is 0, which causes Samba to try the password as delivered and the password converted to all-lowercase if it was sent in all-uppercase. Higher values cause Samba to convert the password to lowercase and then to convert the specified number of letters to uppercase. For instance, if password level = 1 and if a client gives RHUMBA as the password, Samba tries to authenticate the user with passwords of RHUMBA, rhumba, Rhumba, rHumba, and so on. Using high numbers as the password level parameter can therefore improve the odds of a successful login using a valid password that's been corrupted by the client. These attempts increase the time for Samba to confirm that a password is invalid, though, and, in some cases, to verify a valid password. They also increase the odds of a successful break-in by effectively eliminating case as a security feature in your local passwords.

username level

This global parameter is similar to password level, but it applies to usernames rather than passwords. One other minor difference is that when this parameter is set to its default value of 0, Samba tests the username converted to lowercase followed by the username converted to lowercase but with an initial capital letter. If you give higher values, Samba tries up to the number of letters converted to uppercase that you specify, just as with password level.

username

This share-level parameter specifies a list of usernames against which to test a password. This is necessary when using some very old clients (such as some antiquated DOS clients) that don't send usernames, just passwords. Samba tries the password with each of the usernames specified. Ordinarily, this parameter isn't needed because all modern clients deliver usernames by default. This parameter can be used with encrypted passwords as well as with cleartext ones, but because the clients most likely to force its use employ unencrypted passwords, I've described it here.

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.

3.5.3. Using Encrypted Passwords

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.

From a client perspective, the difference between using encrypted passwords on the file or print server and using a password server is nil. In both cases, the client engages in a challenge-response authentication exchange with the file or print server; only the configuration of that file or print server differs.

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:

smb passwd file

You can tell Samba what file to use for holding encrypted passwords with this global parameter. Ordinarily, Samba uses a file called smbpasswd, which is usually located in the same directory as smb.conf or a subdirectory thereof.

passdb backend

This parameter tells Samba how to store its password database. The usual value, smbpasswd, specifies that the smbpasswd file (or another file specified by smb passwd file) be used. Other options tell Samba to use more specialized types of databases, such as an LDAP directory. Fully describing these alternatives is beyond the scope of this book.

lanman auth

The LANMAN hashing scheme is one of several SMB/CIFS encrypted authentication systems. This global Boolean parameter enables or disables support for this protocol. The default value is Yes, and the parameter must be set to this value to support Windows 9x/Me systems.

ntlm auth

The NT LANMAN (NTLM) hash is an improvement on LANMAN authentication, and this parameter controls whether Samba accepts this authentication method. The default value is Yes. If this option and lanman auth are both set to No, only the newest NTLMv2 protocol will work; however, this protocol was added only to Windows NT 4.0 SP4; older clients (and many non-Microsoft clients) don't support NTLMv2.

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.

If users don't need shell access to the server, you can set their login shells to /usr/bin/smbpasswd. When users log in using Telnet or SSH, they'll enter their Linux passwords and then be prompted to change their Samba passwords. Once this is done, they're immediately logged out.

3.5.4. Using a Password Server

Instead of using a local password database, you can defer authentication to another computertypically 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.

3.5.4.1 Setting the security mode

The security parameter tells Samba what security mode to usethat is, what rules to apply for authenticating users. This parameter takes one of five possible values:

Share

When using this security level, Samba attempts to emulate the default access control method of Windows 9x/Me, which is to assign passwords to individual shares and not use usernames. To do this, Samba tries to authenticate using the password that the client sends and a series of different accounts, such as an account used by a previous logon from the client or the name of the share itself. Share-level security is a poor match to Linux's underlying security model, though, and so it's seldom used.

User

This security model is the default, and it corresponds to the use of a local account databaseeither a cleartext Linux account database or an encrypted Samba account database, depending on the value of encrypt passwords.

Server

When using server-level security, Samba authenticates users against a remote server in much the way that Windows 9x/Me servers do. On a technical level, this authentication method is similar to a man-in-the-middle attack; the Samba server essentially passes the data on from the client as if it were making the logon request, then honors the reply from the server. This approach is easy to configure but occasionally doesn't work correctly. It can be used to authenticate against a server that's not a domain controller, but the remote server must be configured to enable remote authentication. This option is being deprecated in Samba 3.0 and later; it still works, but is likely to eventually vanish.

Domain

In a domain-level configuration, the Samba server fully joins an NT domain, much as Windows NT/200x/XP systems do. Samba can then exchange credentials with the domain controller and use the full NT domain authentication system for its users.

ADS

This is the latest authentication method. It links Samba to a Windows 200x Active Directory (AD) controller and uses native AD protocols for authentication. This system is also the most difficult to configure and isn't fully described in this book.

If you use server-, domain-, or ADS-level security, you must tell Samba where to find the password server. This task can be accomplished with the global password server parameter, which accepts a list of one or more names or IP addresses. If you specify a name, it's looked up in the order specified by the name resolve order parameter. If you use domain- or ADS-level security, the remote servers must be domain controllers. Alternatively, you can specify an asterisk (*) to have Samba attempt to locate its domain controller automatically.

Don't use the password server parameter or domain- or ADS-level security on a system that you configure as a domain controller. Such systems should use user-level security and should omit the password server parameter.

3.5.4.2 Using server-level security

Server-level security can be a quick way to use a remote password server. This configuration requires you to enter options like this:

security = Server password server = 172.24.21.98

Of course, you'd adjust the IP address for your own network. Little else is required for this configuration, at least on the Samba server that users access directly. You must ensure that appropriate user accounts exist on the password server system, though. Those accounts must also match the local Linux user accounts on the Samba server you're configuring; using a remote password server doesn't obviate the need to provide local Linux accounts for Samba's use.

Windows networks frequently employ longer usernames than do Linux systems; for instance, CarlLinnaeus rather than linnaeus. If your password server uses such usernames, you can map them to conventional Linux usernames with the username map parameter. This parameter accepts a filename that contains mappings of Linux to Windows usernames, as in linnaeus = "Carl Linnaeus". When Samba receives a logon request from CarlLinnaeus, it authenticates against the password server using that name but uses the local linnaeus account. Although you can use this parameter with user-level security, it's most frequently employed with server-, domain-, or ADS-level security.

3.5.4.3 Using domain-level security

A more complex configuration than server-level security looks nearly identical to it in smb.conf:

security = Domain password server = 172.24.21.98

However, this configuration requires joining the Samba server to the domain using the net command. You can accomplish this task by passing the join subcommand to net:

# net join member -U  adminuser

In this example, the system is joined as a member of the domain specified by the workgroup parameter in smb.conf and controlled by the domain controller pointed to by password server. You must specify an account to use on the domain controller for this operation with the -U parameter. This account must have administrative access to the domain controller's account database, because it must add a machine trust account for your Samba server. This machine trust account is used in the authentication process for individual user logons.

As a practical matter, domain-level security is a bit tougher to configure than is server-level security, but it's more reliable in some situations. If necessary, you can use the username map parameter, as described in Section 3.5.4.2, to associate Linux usernames with Windows usernames.

Chapter 5 describes configuring a Samba server as a domain controller, including the domain controller configuration options required to enable joining other Samba servers as full domain members.