As a practical matter, the desirability of running Linux as an NT domain controller’s client (that is, as a domain member server ) varies from one network to another. The most common use for this approach is limited to file shares on a Samba server, and that procedure is described in Chapter 3. This configuration, though, works only for Samba shares, not for other services the computer might offer, such as a POP server, an SSH login server, or console logins. If a computer should be used in any of these ways in addition to or instead of being used as a Samba server, you must normally maintain local Linux-only accounts. On a network that already uses NT domain authentication for Windows systems, this separation can be a serious problem. You need to recreate your NT domain accounts on your Samba server—a tedious undertaking for you and for your users, who will have to reenter their passwords. If you want to run multiple Linux server computers or add Linux desktop systems, you need to either maintain separate Linux account databases on each Linux system or use some other network authentication database. In other words, you’ll be throwing away the benefits of the NT domain controller for the new Linux systems.

Using an NT domain controller can be a good way to minimize the account maintenance difficulties when you start adding Linux systems. Instead of using a Unix-centric centralized account system or using local Linux account databases, you can tap into the NT domain controller. Once you’ve done this, a Linux POP server, SSH server, or most other servers automatically accepts logins using the usernames and passwords supported by the NT domain controller. You can even use this method to enable console logins using the NT domain’s accounts.

NT domain authentication was designed with the needs of Windows computers in mind. These authentication tools provide some information that Linux requires, such as a username and password. This information isn’t always available in a form the Linux system will find immediately useful, though; for instance, the password is encrypted using a method that’s foreign to Linux. Worse, NT domain accounts lack some information that’s critical to Linux, such as the Linux account’s home directory and default shell. Thus, Winbind must make up some of this information using values set in Samba’s smb.conf file. Other differences, such as NT domain password encryption, are handled by Winbind’s PAM integration modules.

Linux relies on two systems to help manage accounts: PAM and NSS. PAM is described in detail in Appendix A. In brief, PAM tells login services whether a user may log in or not, helps programs change passwords, and handles a few related tasks. PAM is a modular system, so you can reconfigure PAM to use authentication modules based on authentication tools other than the common /etc/passwd and /etc/shadow files. In particular, this chapter describes how to configure PAM modules that link to an NT domain controller with the Winbind tool.

In addition to PAM, Linux relies on another software component, NSS, for account information. Rather than authentication information, though, NSS provides more mundane information, such as a mapping of UIDs to usernames and the account’s default shell. Like PAM, NSS is designed in a modular way and sits between applications that ask for this information and the actual account databases. Although you may think in terms of domain authentication, which is what PAM provides, this ancillary information is just as important, so you must configure NSS to query Winbind. Most of the information NSS delivers is made up rather than pulled out of the NT domain controller, though, because this is the information the domain controller doesn’t support.

Winbind is implemented as a daemon, winbindd . This daemon ships with the official Samba source code tarball, although some Linux distributions split it off into its own package, such as winbind. As described in the later Section 7.2.2, this daemon runs at all times on any server that authenticates users against a domain controller. Although winbindd is a daemon, it’s not an externally accessible server; it doesn’t bind to a port and listen for external connections. It does, though, use Unix domain sockets to communicate with local processes—namely, the PAM and NSS libraries that are also part of the Winbind package.

Winbind connects to the domain controller to authenticate users and thus functions as a domain member server to a domain controller. Winbind works in this way only when the computer on which it’s running is fully joined to a domain using the Samba net command, which is described in Section 7.2.1.