Section 7.2. Samba Winbind Configuration

7.2. Samba Winbind Configuration

Much of the configuration of Winbind is done using Samba. The main Winbind options appear in smb.conf (although, as described earlier, some options are set in the PAM and NSS configuration files, as well). Thus, you must know how to set these Samba options. Running the Winbind daemon is also critically important to getting the system running.

This configuration occurs on the domain member serverthe Linux system you want to configure to use a domain controller's account database. If you use a Samba server as the domain controller, it requires its own configuration, which need not include most of the options described here.

7.2.1. Winbind Options in smb.conf

You should configure the smb.conf file on the domain member server much as you would for any Samba server on a domain, as described in Chapter 3. Most notably, you should set the workgroup, security, encrypt passwords, and password server global options:

workgroup = GREENHOUSE security = Domain encrypt passwords = Yes password server = 192.168.1.1

You should adjust the values of the workgroup and password server parameters for your network, of course. The security parameter must be set to Domain, and encrypt passwords must be set to Yes.

If your domain controller supports AD, you can set security = ADS instead of security = Domain, but this configuration requires setting additional options and can be finicky. It provides somewhat better security on your LAN because it uses the extremely robust Kerberos authentication system.

In addition to these options, which are the same as those you must set for any Samba domain member server, you may want to set several other global parameters. These parameters set values for information required by Linux accounts but not provided by the domain controller:

winbind use default domain

Ordinarily, Winbind returns Linux usernames that are based on a combination of the NT domain name and the NT username. This feature enables you to maintain multiple domains and support users with duplicate usernames in these domains without causing conflicts. If you set this Boolean parameter's value to Yes, though, Winbind omits the domain name from usernames, which results in shorter and more sensible usernames. Doing this is safest when you have just one domain or when you're sure that no usernames are duplicated on multiple domains. This parameter's default value is No.

winbind separator

This parameter specifies a character that separates domain names from usernames when winbind use default domain = No. The default character is a backslash (\).

winbind enum users

Linux provides certain system calls that enable programs to enumerate users on a system. Winbind supports these features if this parameter is set to Yes (the default), but this support can be slow. Thus, if the programs you run on a system don't require this support, setting this parameter to No can improve performance.

winbind enum groups

This parameter works much like winbind enum users, but it affects system calls for enumerating groups rather than users.

idmap uid

Linux uses UIDs internally for tracking users. NT domains use a number called a Security Identifier (SID) for a similar purpose; however, the two numbers aren't identical. Thus, you can give Winbind a range of local UID numbers to use for the accounts it handles. This range is given as two numbers separated by a dash, as in 2000-5000. You should never create local Linux accounts in the range you reserve for Winbind in this way. This parameter's default range is undefined. Prior to Samba 3.0.6, this value had to be set, but in Samba 3.0.6 and later, an undefined idmap uid causes Winbind to try to map NT domain usernames to locally defined accounts, which can be useful if you have existing Linux accounts but want to rely on a domain controller for password authentication. A synonym for this parameter is winbind uid.

idmap gid

This parameter works much like idmap uid, but it reserves a range of GID numbers rather than UID numbers. This parameter's default value is undefined. A synonym for this parameter is winbind gid.

Winbind makes no guarantees about the UIDs and GIDs assigned to particular users and groups. In particular, two Linux systems might assign completely different UIDs and GIDs to a user, even if you specify the same range of UIDs with idmap uid. This can complicate certain Linux-to-Linux protocols, such as NFS, which identifies accounts by UID rather than username. You can overcome this problem using the idmap backend parameter to point to an LDAP directory that holds the UID mapping information.

Samba maintains information about UID and GID mapping in Trivial Database (TDB) files, typically in /var/cache/samba or a similar location. If these files are damaged or deleted, Winbind has to rebuild these mappings, and they may not match the originals. If this happens, you have to reassign ownership of all your users' files and home directories.

template shell

An /etc/passwd file normally specifies a default shell for a user; this program is run when a user logs in at a text-mode console, via SSH, and so on. NT domain controllers don't maintain this information, though, so you must tell Winbind what value to provide. The default is /bin/false, which is a conservative choice from a security point of view and may be good for some functions. However, for systems that should support shell access, another value, such as /bin/bash, will function better. You can't customize this value on a per-user basis; all accounts mediated by Winbind must use the same shell.

template homedir

Just as with the default shell, NT domain controllers don't maintain information on the users' home directories. You specify this information with this parameter, which defaults to /home/%D/%U. Because %D is a Samba variable for the domain name and %U stands for the username, this value sets a unique home directory for each user. As of Samba 3.0.6, only the %D, %N, %U, and %u variables are supported in this option.

winbind cache time

This parameter sets the amount of time, in seconds, that Winbind will cache authentication information before querying the server again, should a new authentication request occur. The default value is 300 (five minutes). You may want to reduce this value during testing.

The most important of these parameters to set or change are usually idmap uid, idmap gid, and template shell. Setting other parameters can sometimes be desirable, though. For instance, you might use parameters like these for testing in a one-domain configuration:

winbind use default domain = Yes idmap uid = 2000-5000 idmap gid = 2000-5000 template shell = /bin/bash template homedir = /home/%U winbind cache time = 5

Once you're convinced everything is working, you should increase the cache time so as to reduce the number of queries the system makes of the domain controller. Changes to some other parameters might require additional system changes; for instance, if you alter template homedir, you have to move users' home directories yourself.

Before proceeding, remember to add a machine trust account to the domain controller for the Linux computer. This can be done from the Linux system using the net utility. For instance, to join a computer to the domain specified by the workgroup parameter in smb.conf, type this command:

# net join member -U  adminuser

This command needs to be run just once. In this example, adminuser is the username of an account on the domain controller that may add machine trust accounts. (This topic is covered in more detail in Chapter 3.) If the domain controller is a Samba server, consult Chapter 5 for information on configuring the necessary machine trust accounts.

7.2.2. Running the Winbind Daemon

Because Winbind relies on a running daemon, you must configure it to run at all times. For testing purposes, though, you may want to run it manually:

# /usr/sbin/winbindd -i

The winbindd program file may be in another directory on your system. /usr/local/samba/sbin is common if you compiled Samba from source code yourself. If you can't find the binary on your system, check your distribution's Samba packages; you might not have installed the package in which the daemon ships.

To run the daemon permanently, you should do one of two things:

• Add a line to launch the program to a local startup script, such as the /etc/rc.d/rc.local script in Fedora Core, Mandrake, or Red Hat; /etc/init.d/boot.local in SuSE; or /etc/conf.d/local.start in Gentoo.

• Configure a SysV startup script to launch the daemon. Many distributions' Samba packages include such scripts, usually called winbind or something similar. Create appropriate symbolic links or use whatever SysV startup script management tools your distribution provides to do the job.

In either case, you should remove the -i option from the line that launches winbindd. This option causes the daemon to log information on its operation to standard output and to not detach from the current terminal, which is handy when testing the daemon but not when using it in normal operation.

Once Winbind is running, you can test its basic operation using the wbinfo command. This command supports numerous options that return information on accounts maintained by the domain controller. Some options enable you to modify those accounts, as well. To test the most basic operation, use the -t option to test the trust account you've created and the basic Winbind functionality:

$ wbinfo -t checking the trust secret via RPC calls succeeded

If this call returns an error message, review your smb.conf options and check the logs on the Linux system and the domain controller for clues to the cause. A subsequent testing step involves -u; this option returns a list of accounts maintained by the domain controller:

$ wbinfo -u linnaeus mendel britton

This example shows output consistent with a setting of winbind use default domain = Yes. If this option is set to No, the usernames include domain names, as in GREENHOUSE\linnaeus rather than linnaeus.

If wbinfo -u returns a list of users, you can be confident that Winbind is operating, at least minimally. If you receive an error message, though, you should look into the matter. Review your smb.conf entries, and check the logs on both the Linux system and the domain controller for clues.