Using Winbind Authentication

auth requisite pam_securetty.so
auth requisite pam_nologin.so
auth required pam_env.so
B
auth required pam_unix.so nullok B


account requisite pam_time.so
B
account required pam_unix.so

session required pam_unix.so
session optional pam_lastlog.so
session optional pam_motd.so
session optional pam_mail.so standard noenv

password required pam_unix.so nullok min=6 max=255 md5

This configuration adds lines to the auth and account stacks, inserting a call to pam_winbind.so just before a call to pam_unix.so. These calls are marked as sufficient, meaning that if Winbind gives its OK, subsequent modules need not succeed. This is very important when combining multiple authentication tools, such as Winbind and pam_unix.so (which is the standard tool that validates users against /etc/passwd and /etc/shadow).

Other modules called in these stacks don’t actually verify passwords; instead, they perform additional checks, such as verifying that root isn’t logging in via telnet. You might optionally want to add another line to the end of the session stack:

session required pam_mkhomedir.so
skel=/etc/skel umask=0027

(This line has been split for publication purposes, and should be recombined into a single line if you add it.) This automatically creates a home directory for the user if one doesn’t exist. This can be handy if you want users to be able to log into the Linux system without your having to manually create home directories for them.

On some distributions, you must change the PAM configuration files for all of the services that you want to use Winbind. For instance, if you want to use domain accounts for text-mode console logins, logins via the GNOME Display Manager (GDM), for X screensaver password prompts, and for POP mail retrieval, you would have to modify the login, gdm, xscreensaver, and pop files in /etc/pam.d/. This can be tedious, so some distributions use a module called pam_stack.so instead of pam_unix.so. The pam_stack.so module calls an entire stack of PAM modules itself, as specified in the file defined by the service= option to this module (typically /etc/pam.d/system-auth). The end result is that, if your system uses pam_stack.so, you can probably modify system-auth rather than all of the other files. This can be a great time-saver, but if you want to use Winbind for some services but not others, you’ll still have to modify the individual files.

One service requires a special note: passwd. This service (and its /etc/pam.d/passwd configuration file) controls how the passwd command interacts with PAM. For a Winbind configuration, it’s probably best to leave this configuration alone. Users can then use the passwd command to change their local passwords (if they exist), and use smbpasswd to change their passwords on the domain controller. Alternatively, if you add a call to pam_winbind.so to the password stack, then the passwd command changes the password on the domain controller.

If a server or other program is running, you may need to restart it before you can use any new authentication tools you’ve defined in PAM. In the case of many login tools, logging in and then logging out again does the trick. You may need to restart some servers via their startup scripts, though.

Configuring NSS

At this point, your system should be able to use the NT domain controller for authenticating users; however, they must still have accounts defined locally, in /etc/passwd and /etc/shadow. Thus, implementing this system isn’t likely to save a lot of effort.

The final step is to link NSS to Winbind. You can do this by editing the /etc/nsswitch.conf file. Look for two lines in this file that begin with passwd and group, and add the string winbind to these lines. These two lines are ordinarily separated by one called shadow, but you don’t modify that line. The result might look something like this:

passwd: files winbind
shadow: files
group: files winbind

Some distributions use other options instead of or in addition to files; compat is one popular alternative. The key is to add winbind to the passwd and shadow lines, rather than use precisely the configuration shown here.

When you’re done with this, NSS will use both its original configuration and Winbind for the purposes for which /etc/passwd and /etc/shadow are normally used. This will enable you to use your normal Linux-only local accounts and groups, such as root and any users you want to define locally, without the help of the domain controller.

While you’re modifying /etc/nsswitch.conf, you might want to change one other line: hosts. This line tells the system what tools to use to resolve hostnames. If you add wins to this line, Linux will use NetBIOS name resolution methods in addition to any other methods (such as /etc/hosts and DNS). The order of items on this line defines the order Linux uses.

For instance, you might end up with a line like this:

hosts: files wins dns

This configuration isn’t strictly necessary, and it requires its own library (libnss_wins.so, installed much like libnss_winbind.so, as described earlier). Still, it can be handy if your system is running on a network that uses NetBIOS names locally and you don’t want to maintain all your local names in /etc/hosts or run a local DNS server.

You needn’t restart anything to have NSS begin using the new configuration you’ve specified in /etc/nsswitch.conf. You may want to check that the NSS portion of the configuration is working by using getent. This command returns information on user and group database entries. In particular, typing getent passwd returns user information, and getent group returns group information. On Linux systems with default configurations, these commands’ outputs are similar to what you’d get by typing cat /etc/passwd or cat /etc/group. On a system with a working Winbind NSS configuration, you should see the contents of these files plus accounts maintained by the NT domain controller. If you don’t see these accounts, review your configuration and consult your log files (on both the Linux system and the domain controller) for clues.

Testing the Configuration

At this point, everything should be working, and you should have tested the Winbind and NSS subsystems. To test PAM and everything else, you should try an ordinary login using a domain account — that is, one that’s defined on the domain controller but not on the local system. You can do this via whatever login methods you chose to configure in PAM, and in fact you should test all of these login methods, to be sure there’s not a problem with some of them but not others.

Be sure to test both valid and invalid logins, that is, correct usernames and passwords, correct usernames and incorrect passwords, and incorrect usernames. Some configurations will enable anybody to log in, using correct or incorrect passwords. Presumably that’s not what you want to do! You should also test your local accounts while you’re at it — some types of configurations will disable those accounts, but you should leave them enabled. If nothing else, root should be defined locally, not via the domain controller.

Roderick W. Smith is the author or co-author of over a dozen books, including Linux in a Windows World and The Definitive Guide to Samba 3. He can be reached at class="emailaddress">rodsmith@rodsbooks.com.