![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
In this article, learn about these concepts:
- Installing Winbind
- Configuring Winbind
This article helps you prepare for Objective 313.3 in Topic 312 of the Linux Professional Institute's (LPI) Mixed Environment specialty exam (302). The objective has a weight of 2.
To get the most from the articles in this series, you should have an advanced knowledge of Linux and a working Linux system on which you can practice the commands covered in this article. In particular, this article assumes that you have a working knowledge of Linux command-line functions and at least a general understanding of the purpose of Samba as covered in Learn Linux, 302 (Mixed environments): Concepts, as well as the basics of Samba configuration, including configuring Samba to use a domain controller. You should be familiar with the overall structure of the smb.conf configuration file. You should also understand how servers in general are run, including use of System V (SysV) startup scripts and super servers. As a practical matter, you must have access to a Windows domain to use the information presented here. (You can use a domain that's managed by Samba or by a computer running a Windows Server operating system.)
As described in Learn Linux, 302 (Mixed environments): Samba roles and Learn Linux, 302 (Mixed environments): Domain control, Windows networks often include a domain controller, which is a computer that manages authentication for all the Windows computers in a network. Such a configuration can greatly simplify life in a network with many users and computers, because user account information need not be duplicated (and maintained) on multiple computers. Instead, all the Windows account information is centralized on a single computer, enabling administrators to manage accounts in one location and enabling users to change their passwords once for all the domain's member computers.
You can configure a Samba server to be a member server in a domain by setting various options. A typical set of global options for joining a domain might resemble the following:
security = Domain password server = CONTROL domain logons = No encrypt passwords = Yes |
You might use security = ADS rather than
security = Domain if the domain controller supports
Microsoft Active Directory Domain Services features. You must also
join the Samba server to the domain by typing
net join member -U adminuser, where
adminuser is the domain's administrative
account. Refer to Learn
Linux, 302 (Mixed environments): Samba roles for a more detailed description of how to configure
a Samba server as a domain member.
All of this is well and good for a Samba server, but of course Samba is just one server you can run on a Linux computer. Other servers, as well as local login services, could in principle benefit from a domain controller. For instance, if some computers on a network function as Linux workstations or if you run a Post Office Protocol (POP) e-mail server on a Linux computer, you might want them to use the domain controller for authentication. That's where Winbind comes in; it provides the "glue" to enable Linux to use a Windows domain's accounts for non-Samba authentication tasks.
Before you configure Winbind, though, you should be aware of its limitations. Because Microsoft designed its domain authentication procedures with the needs of Windows in mind, it lacks certain features that Linux needs in its accounts, such as UNIX®-style user ID (UID) and group ID (GID) values. Instead, Windows domains use security identifiers, which aren't directly mappable to Linux UIDs and GIDs. Similarly, domain controllers don't store UNIX/Linux home directory information. Thus, Winbind must create some of this Linux information locally. This is fine for many purposes, but it means that two Linux computers using Winbind might easily create different UIDs and GIDs for a single user. This fact could have negative consequences if those computers share files using the Network File System (NFS), which relies on UIDs and GIDs matching across servers. In such situations, you might be better off configuring a Lightweight Directory Access Protocol (LDAP) server for the network and using its account database for both Linux accounts and Windows domain accounts.
Winbind relies on several different elements:
- Winbind-specific options in smb.conf
- Configuration options for the Pluggable Authentication Modules (PAM) subsystem, which is a standard part of modern Linux installations
- Configuration options for the Net Service Switch (NSS) subsystem, which is a standard part of modern Linux installations
- The
winbinddserver program
Configuring Winbind, therefore, requires modifying each of these configurations. You
need not run the main Samba server programs, smbd
and nmbd, to use Winbind, but you may have to install
the server to get all the necessary support files. You may need to install a separate
Winbind package, typically called winbind or
samba-winbind. You may also need to install a package
called samba-winbind-clients. Be sure your final installation
includes the /lib/security/pam_winbind.so and /lib/libnss_winbind.so.2 files.
Setting Winbind options in smb.conf
To set up Winbind, you must first configure the computer to join a domain, as described briefly earlier and in more detail in Learn Linux, 302 (Mixed environments): Samba roles. You must then set various smb.conf options that relate specifically to Winbind.
The smb.conf options you might need to set include:
winbind separator. In a domain, Windows user names include both a user name and a domain name, with a separating character between them. This option sets that character. The default is a backslash (\), but a plus sign (+) is a common alternative.winbind cache time. Winbind caches authentication data for a given period of time, which defaults to 300 seconds (5 minutes). You may want to reduce this value when testing your Winbind configuration.template shell. You set the users' default shell using this option. The default value is/bin/false, which is appropriate for systems that don't support shell access; but if you want users to be able to log in locally or via servers such as the Secure Shell (SSH), you should set this option to /bin/bash or some other legal Linux shell.template homedir. You must set a default home directory for users. You'll typically use one or more Samba variables, such as%Ufor the user name and perhaps%Dfor the domain name. This parameter's default value is/home/%D/%U.winbind enum users. This Boolean option enables or disables support for certain system calls that enable programs to enumerate users. The default value isYes, but setting it toNocan improve performance at the cost of strange behavior from a few programs, such asfinger.winbind enum groups. This option works much likewinbind enum users, but it applies to groups rather than users.winbind use default domain. If you set this option toYes, Winbind drops the domain component of user names for most operations, which is often desirable, because it shortens user names—for instance, from MYDOMAIN\rexx to rexx. Using the default value ofNomakes sense if your network includes multiple domains.idmap uid. You should specify a set of UIDs with this option, using a dash (-) as a separator, as in10000-20000. Be sure that the range you use does not overlap with the locally defined UIDs in use on your system.idmap gid. This option is just likeidmap uid, but it sets a range of GIDs.
Examining a sample configuration
As an example, consider Listing 1, which shows a set of smb.conf options that demonstrate all of the preceding options.
Listing 1. An example smb.conf file demonstrating Winbind configuration
winbind separator = + winbind cache time = 60 template shell = /bin/bash template homedir = /home/%U winbind enum users = Yes winbind enum groups = Yes winbind use default domain = Yes idmap uid = 10000-20000 idmap gid = 10000-20000 |
Of course, you should customize these options for your own needs. For example,
as noted earlier, the default value for template shell
is probably appropriate for servers that don't provide login shell access, such as
e-mail servers or FTP servers.
With the smb.conf configuration in place, you must tackle the PAM configuration. Learn Linux, 302 (Mixed environments): Authentication and authorization introduced PAM, but for Winbind's purposes, you want to add Winbind as an authentication method for non-Samba tools rather than authenticate Samba users using PAM. Doing this can be a bit tricky, because different distributions configure PAM in different ways, so a modification that works perfectly on one distribution will fail miserably on another one.
PAM is a set of libraries that can be used by programs that require authentication,
such as the login program that handles text-mode
logins, an X Display Manager program that handles graphical user interface
logins, or a POP e-mail server program. To provide a flexible system, you can
configure PAM using configuration files, as described shortly.
PAM is a complex system, and because of the differences between distributions
in PAM configuration, a complete description is not possible here. (The
Resources section provides pointers to additional PAM
documentation.) You configure PAM through files in /etc/pam.d. Most of the
files in this directory describe how PAM works for specific programs, such as
the text-mode login program or the SSH server
program. Most distributions, though, provide global PAM configuration files,
such as system-auth or common-stackname, where stackname
is one of four PAM stack names. (Each stack defines one particular type of
service PAM provides.)
When reconfiguring PAM, you must decide whether you want to make a change that affects all your login services or just a few. (Examine the files in /etc/pam.d to see what sorts of login services are installed on your system, and then ask yourself if all or just a few need to use Winbind.) If you want to modify just one or two services, such as a POP server, while not enabling Winbind authentication for others, such as an FTP server, modify just the file for the service you want to change. If you want all services to be affected, though, edit the generic file, such as system-auth.
A typical PAM stack looks something like Listing 2, which is the /etc/pam.d/common-auth file from an Ubuntu version 10.10 system.
Listing 2. An example PAM stack
auth [success=1 default=ignore] pam_unix.so nullok_secure auth requisite pam_deny.so auth required pam_permit.so |
Unfortunately, this particular syntax is a bit obscure. The pam_unix.so
module manages authentication using local password database files, and the
success=1 option on that line means that PAM skips
one line when this module returns success. Thus, pam_deny.so
(which always returns an authentication failure code) is skipped if
pam_unix.so succeeds, and the login succeeds.
To modify this configuration to incorporate Winbind, you must add a reference to
the pam_winbind.so module and change the number
of lines to skip in the pam_unix.so line. The result
resembles Listing 3, which highlights the changes.
Listing 3. A PAM stack with Winbind support
auth [success=2 default=ignore] pam_unix.so nullok_secure auth [success=1 default=ignore] pam_winbind.so cached_login try_first_pass auth requisite pam_deny.so auth required pam_permit.so |
Distributions other than Ubuntu, on which this example is based, require other
changes to PAM, but you must fully understand your initial configuration before
making such changes. Note also that you must modify all of the four
stacks—auth, account,
session, and password.
These stacks might all appear in one file or be split across multiple files. If you
want to modify individual services, you must modify all four stacks in the
configuration files for all the services you want to adjust.
Some distributions make appropriate changes to their PAM configurations when you install the Winbind package. Thus, you may not need to make any changes at all.
A second service that you must adjust to enable Winbind logins is NSS. Fortunately, NSS configuration is considerably simpler than PAM configuration. You must edit the /etc/nsswitch.conf file and change the following three lines:
passwd: compat group: compat shadow: compat |
Some systems use files rather than compat
on these lines, and it's possible you'll find other entries on these lines. These
lines tell NSS to use local files for its job, which is to provide lists of users and
groups to programs that want them. To add Winbind to the system, add a
reference to it to each of these lines:
passwd: compat winbind group: compat winbind shadow: compat winbind |
With these changes in place, you can finally run and test Winbind. You can usually launch Winbind by using a SysV startup script, as in:
# /etc/init.d/winbind start |
Caution: If your system is running the Name Service Cache Daemon (NSCD), terminate the daemon before running the Winbind daemon. NSCD can interfere with Winbind operations.
If you want to run the daemon automatically whenever the system starts, ensure that its
SysV startup script is properly configured for this task. You can use
chkconfig, ntsysv,
update-rc.d, or other tools to do this.
With Winbind running, the wbinfo program enables you to
test it. The -u option returns a list of users:
$ wbinfo -u grogers fastaire mikhail |
This example shows three users. You can also type getent passwd
to retrieve a list of users; this is essentially the equivalent of the /etc/passwd file.
This command returns all the users defined by any means, including local accounts,
Winbind, and any other services you may be using, such as an LDAP server.
Note: The wbinfo -u and
getent passwd commands sometimes fail to return a
complete list of domain users, particularly if you set winbind enum users = No.
Thus, if these commands don't seem to work, test your ability to log in.
Of course, the ultimate test of whether Winbind is working is whether it can properly
authenticate users of the services you've configured it to use in PAM. Thus, you
should test this ability by using an account that's defined in the Windows domain but
not on the local computer. If you don't succeed, try examining the log files on both
the client and the Windows domain controller. Remember that if you set
inbind use default domain = No, your local user names
will take the form DOMAIN\username (or something similar,
with a different separator if you set winbind separator.
The next topic in this series, Learn Linux, 302 (Mixed environments): CIFS integration, covers integrating a Linux computer into a Server Message Block (SMB)/Common Internet File System (CIFS) network as a file-sharing client. This topic includes using stand-alone client tools and mounting SMB/CIFS shares in the standard Linux file system hierarchy.
Learn
-
"Understanding
and configuring PAM" (developerWorks, March 2009) explains PAM in more detail.
-
The Official
Samba Winbind documentation goes into additional detail about Winbind
configuration.
-
The Linux
PAM System Administrators' Guide provides extensive information on PAM,
although it's old enough that it doesn't cover the latest features.
- At the LPIC
Program site, find detailed objectives, task lists, and sample
questions for the three levels of the LPI's Linux systems administration
certification. In particular, look at the LPI-302 detailed objectives.
- Review the entire LPI exam
prep series on developerWorks to learn Linux fundamentals and
prepare for systems administrator certification based on LPI exam
objectives prior to April 2009.
-
In the developerWorks
Linux zone, find hundreds of
how-to
articles and tutorials as well as downloads, discussion forums, and a wealth
of other resources for Linux developers and administrators.
-
Follow developerWorks on
Twitter, or subscribe to a feed of
Linux
tweets on developerWorks.
-
Stay current with developerWorks
technical events and webcasts focused on a variety of IBM products and
IT industry topics.
-
Attend a free developerWorks
Live! briefing to get up to speed quickly on IBM products and tools as well
as IT industry trends.
-
Watch developerWorks
on-demand demos ranging from product installation and setup demos for beginners
to advanced functionality for experienced developers.
Discuss
-
Get involved in the My developerWorks
community. Connect with other developerWorks users while exploring the
developer-driven blogs, forums, groups, and wikis.
Roderick W. Smith is a consultant and author of over a dozen books on UNIX and Linux, including The Definitive Guide to Samba 3, Linux in a Windows World, and Linux Professional Institute Certification Study Guide. He is also the author of the GPT fdisk partitioning software. He currently resides in Woonsocket, Rhode Island.
