Section 7.4. Winbind in Action

7.4. Winbind in Action

In theory, Winbind should now be working. In practice, though, various problems can occur. You can perform tests to check on Winbind's operation that will point you to likely solutions for any problems that might exist. Once the system is up and running, you can begin using it, but you should understand its capabilities and limitations in day-to-day operation.

7.4.1. Testing Winbind Operation

We looked at the wbinfo tool that tests Winbind operation in Section 7.2.2. This tool queries the domain controller via Winbind without using the NSS or PAM libraries, and as such, it's a good test of "pure" Winbind operation. It provides several options you can use to test basic Winbind operations:

-a username%password

This option performs a test authentication using the provided username and password. If it succeeds, Winbind can authenticate users. This option only works when run as root.

-g

This option displays all groups available on the current domain.

-n name

Winbind returns the SID of the specified name, which is normally a username but could be a group name.

-p

This option checks for the presence of Winbind; if it's running and working at least minimally, the program responds Ping to winbindd succeeded.

-t

Use this option to check the validity of your domain trust account. If it's valid, wbinfo responds:

checking the trust secret via RPC calls succeeded

-u

As described earlier, this option displays a list of usernames managed by Winbind.

Some additional options provide more features for converting between SIDs, Unix usernames, and Unix UIDs. Still more options can be used for account management. Consult the wbinfo manpage for more information.

When debugging problems, I recommend using the -p, -t, -u, and -g options to check for basic functionality. (The last of these may return an empty list under some circumstances, though.) Using options that work on specific accounts or groups, such as -a and -n, can help you verify that more advanced features are working. If any tests fail, the pattern of failures can be informative. For instance, if -t fails, but -p works, you should check your machine trust account, and if necessary recreate it.

A second layer of tests uses the getent command. This tool returns the contents of administrative databases, such as /etc/passwd or /etc/group. The tool works through NSS, though, so when you configure NSS to use a domain controller, getent should return information from the local /etc/passwd or /etc/group files, followed by constructed entries for the NT domain accounts and groups. You obtain these lists by typing the command followed by the databasethat is, getent passwd or getent group. Check the outputs of these commands for the accounts and groups that are defined on your domain controller. If either output lacks entries that should be present, you might have mistyped an entry in /etc/nsswitch.conf, or your system might be missing the appropriate library. Remember to type ldconfig after adding libraries.

You should also check the output of getent for appropriate UID and GID numbers. The NT domain accounts and groups should use numbers specified in the idmap uid and idmap gid parameters, respectively, in smb.conf. If these numbers overlap those of locally defined accounts, reconfigure smb.conf so they don't overlap.

Sorting the getent output by UID can sometimes be helpful. Typing getent passwd | sort -t: -k3 -n will do this.

7.4.2. Winbind Logins

Once you've performed these tests, you can try logging in using Winbind. Doing so may require you to restart the login process you're using, though. If you can't seem to log in, try terminating the server you're using and restarting it. (The local login process, which handles text-mode logins, normally starts anew whenever you log out. The same is true of processes run from a super server.)

If all goes well, you should be able to log into your system using the NT domain controller just as you would using the local login database; you should see absolutely no difference. To be sure you're using the NT domain controller, use an account that exists on the domain controller but not in the Linux system's local account database.

Some PAM configuration errors enable you to log into an account with no password or with an incorrect password, so be sure to test not only your ability to log in, but Linux's response to incorrect passwords.

If you set winbind use default domain = No, you'll have to provide the domain name as part of each username, as in GREENHOUSE\linnaeus rather than linnaeus. This can be awkward, so you should set this parameter to Yes, if possible.

If your server should support multiple login services, such as text-mode console, GDM, and FTP accesses, be sure to test all of them. Of course, you'll also have to adjust each service's /etc/pam.d file.

Some servers require unusual configurations, either in their PAM configuration files or in their own configuration files. For instance, OpenSSH requires you to set UsePrivilegeSeparation no in its /etc/ssh/sshd_config file. Some servers also provide optional PAM support, which must be enabled either in a configuration file or when building the server. If you find that most servers work with NT domain authentication but some don't, try a web search on Winbind or PAM and the server name for clues about any server-specific quirks.

If your domain controller is a Samba server, you might find that your NT domain accounts don't belong to an explicitly defined group. The usual symptom is a GID number rather than a group name in ls listings:

$ ls -l total 0 -rw-r--r--  1 linnaeus 2009 0 May 23 15:55 myfile.txt

Note the GID number (2009) in this output where a group name normally appears. This problem is a result of the fact that Samba doesn't automatically map its local Linux groups to NT domain groups. You may be able to safely ignore this problem, but if groups are important to you, you can overcome it using the net utility to set up a mapping of Linux to NT domain groups. First, create NT groups using the GROUP ADD subcommand:

$ net GROUP ADD  Botanists

Now, set up a mapping of existing Linux groups to the NT domain groups:

$ net GROUPMAP ADD ntgroup= Botanists unixgroup=botany

Of course, the Linux group must exist before you type this command; if it doesn't, you should create it first, using groupadd or some other tool. You may be asked for a password after typing these commands. You may also need to add the -U adminuser option to perform this action as the specified administrative user. If you want to configure multiple groups, you must set up each individually. In any event, after performing these steps, group mapping should operate in a fairly straightforward way.

Another approach to the problem of missing group mappings is to use NIS, LDAP, or some other tool to share group information between the Samba server and the Winbind client. This approach requires either setting winbind trusted domains only = Yes or not setting the idmap gid parameter. In either case, the Winbind client then uses the GID information distributed via the alternative protocol, such as NIS or LDAP.

In normal operation, Winbind attempts to authenticate users against the NT domain controller. This attempt can fail, though. This can happen because of a failure of the domain controller, network problems, or local configuration problems or because the account doesn't exist on the domain controller. In such situations, if you've configured Winbind as described in this chapter, Linux falls back on its local account database. You may want to keep this database populated with a few critical accountsmost importantly, the root account, so that you can perform system maintenance even if the domain authentication system fails. However, if you maintain redundant accounts (for instance, if linnaeus is defined both locally and on the domain controller), which account is used depends on the order of entries in the PAM configuration file and the /etc/nsswitch.conf file. As a general rule, defining an account in both ways is likely to lead to confusion, so this practice should be avoided.