Learn Linux, 302 (Mixed environments)


Using a Windows domain controller for Linux account management

Content series:

This content is part # of # in the series: Learn Linux, 302 (Mixed environments)

Stay tuned for additional content in this series.

This content is part of the series:Learn Linux, 302 (Mixed environments)

Stay tuned for additional content in this series.


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

Understanding Winbind

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 winbindd server 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/ and /lib/ 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.

Exploring Winbind options

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 %U for the user name and perhaps %D for 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 is Yes, but setting it to No can improve performance at the cost of strange behavior from a few programs, such as finger.
  • winbind enum groups. This option works much like winbind enum users, but it applies to groups rather than users.
  • winbind use default domain. If you set this option to Yes, 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 of No makes 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 in 10000-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 like idmap 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.

Configuring PAM

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.

Understanding PAM

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 Related topics 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.)

Modifying a PAM stack

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] nullok_secure
auth  requisite         
auth  required          

Unfortunately, this particular syntax is a bit obscure. The 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, (which always returns an authentication failure code) is skipped if succeeds, and the login succeeds.

To modify this configuration to incorporate Winbind, you must add a reference to the module and change the number of lines to skip in the line. The result resembles Listing 3, which highlights the changes.

Listing 3. A PAM stack with Winbind support
auth  [success=2 default=ignore] nullok_secure
auth  [success=1 default=ignore] cached_login try_first_pass
auth  requisite         
auth  required	        

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.

Configuring NSS

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

Running 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

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.

Moving forward

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.

Downloadable resources

Related topics

ArticleTitle=Learn Linux, 302 (Mixed environments): Winbind