Hack5.Authenticate Linux Users with a Windows Domain Controller

Hack 5. Authenticate Linux Users with a Windows Domain Controller

To a busy sysadmin, centralization is usually more important than philosophy.

Much has been made in the Linux press about using Samba to bridge the gap between Linux/Unix and SMB/CIFS environments. Samba is not just one of the most impressive pieces of open source software everit's also as impressive a job of reverse engineering as "Hacking the Xbox."

However, using Samba for authentication is often more of a philosophical point than an organizational need. Frankly, if you already have a huge, well-designed, functional Windows environment that supports authentication, groups, ACLs, and Exchange (to name a few "popular" Windows services), converting all that to Linux can be more work than it's worth. If you're just starting to integrate Linux boxes into your user desktops in a coherent fashion, why not swim against the standard Linux tide and configure the login mechanisms on your Linux boxes to use the authentication provided by your existing Windows domain controllers? You can always convert them later, when your yearly ransom demand from Microsoft arrives.

1.6.1. Software Requirements

To integrate Windows domain and Linux authentication, you'll need to have the PAM, samba-winbind, and smb-client packages installed on your system. The core pieces of software that you'll need are the daemon that enables you to communicate with a Windows domain controller, known as the winbindd daemon (usually installed as /usr/sbin/winbindd), a correctly configured /etc/samba/smb.conf file (used by the winbind daemon to obtain information about your domain and domain controller), and the PAM for domain authentication through this daemon (/lib/security/pam_winbind.so). The winbindd daemon and the pam-winbind.so module are both provided in the samba-winbind package, though to use the PAM you must have the PAM package installed and working on your system. The current versions of these packages at the time this book was written were pam-0.78-8, samba-winbind-3.0.13-1.1, and samba-client-3.0.13-1.1.

Of course, if your environment has enough Windows dependencies to make you want to authenticate your Linux boxes using Windows, you're probably already using Samba to access your Windows shares from your Linux system or your Linux filesystems from your Windows systems. Nowadays, most Linux systems come with Samba installed. To get complete support for Windows domain authentication, you'll want to make sure your system is running Samba 3.x or better. If you're using a package manager, you can run the command rpm -q packagename to find out which version of each of these is installed on your system.

If you're missing any of the packages that you need or want, you can either consult your favorite package repository (RPMBone and RPMFind.net come to mind) to find a prebuilt package for your system, or download the complete Samba source code from http://www.samba.org and build the whole thing yourself. It's quite easy.

1.6.2. Critical Samba Configuration for Using Windows Authentication

As mentioned in the previous section, the winbindd daemon obtains the information that it needs to communication with your primary domain controller from the standard Samba configuration file (usually /etc/samba/smb.conf, unless you installed Samba elsewhere). The following are the critical entries used by the winbindd daemon, all from the [global] section of the Samba configuration file:

workgroup

The name of the Windows domain to which you want the Linux system to authenticate.

winbind uid

A range of integer user IDs (UIDs) for the users that you want to be able to authenticate using Windows authentication. An example range is 10009999, which is the typical range of UIDs for non-system Linux user accounts nowadays.

winbind gid

A range of integer group IDs (GIDs) for the groups you want to be able to authenticate using Windows authentication. An example range is 100999, which is the typical range of GIDs for non-systems Linux groups nowadays.

security

The type of security you want your system to use. When using Windows domain authentication, this should always be set to domain.

username map

The name of a file that contains mappings between Windows user-names and Linux usernames. This is typically the file /etc/samba/smbusers. In general, if you're going to be authenticating Linux users against a domain controller running on Windows, it's easiest to simply use the same login names on your Windows and Linux systems (even though bill.vonhagen is uglier and requires more typing than more traditional logins such as wvh).

obey pam restrictions

If you are using the Linux PAM mechanism to authenticate your Linux users, this should always be set to yes to force Samba to use all of the bells and whistles of PAM authentication.

1.6.3. Updating /etc/nsswitch.conf

To cause your system to consult the winbindd daemon for password and group authentication, you will also have to modify your system's name service switch to integrate Windows domain authentication. To do this, modify your /etc/nsswitch.conf file to specify that the system obtains password and group information from the Windows domain controller. Correct entries would be the following:

 passwd: files winbind group: files winbind 

This tells the name service switch to first check the local password and group files on the client system for authentication information and then check the winbindd daemon. This enables you to create local accounts when necessary, giving these local accounts priority while still using Windows domain authentication for most accounts.

1.6.4. Integrating the pam_winbind.so PAM into System Authentication

Unless you're using a Linux distribution such as Red Hat, which provides a graphical tool for configuring system authentication (system-config-auth, shown in Figure 1-1), you'll need to manually modify the PAM configuration files for services that will authenticate using your Windows domain controller. At a minimum, this is the login configuration file (/etc/pam.d/login), and probably also the PAM configuration file for SSH logins (/etc/pam.d/sshd).

Here's a sample PAM configuration file that uses Windows authentication to enable logins:

 #%PAM-1.0 auth sufficient /lib/security/pam_winbind.so auth required /lib/security/pam_securetty.so auth required /lib/security/pam_stack.so service=system-auth debug  use_first_pass auth required /lib/security/pam_nologin.so account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth session optional /lib/security/pam_console.so 

Figure 1-1. Red Hat's graphical application for configuring Windows authentication

Note that this PAM configuration file accepts Windows authentication as being sufficient to enable a login, but then falls through to the standard Linux authentication sequence if this fails. This enables you to use a mixture of central authentication (through the Windows domain controller) and local authentication (using the traditional Linux/Unix password and group files).

1.6.5. Starting the winbindd Daemon

One of the last steps in integrating Linux systems with Windows authentication is to make sure the winbindd daemon starts automatically whenever you boot your system. To do this, make sure a symbolic link to the /etc/init.d/winbind startup script exists for your system's default runlevel. To start the winbindd daemon manually (i.e., the first time), you can simply run this script with the start argument, as in:

 # /etc/init.d/winbind start 

1.6.6. Joining the Domain

The final step is to actually join the domain from your Linux system. You can do this using the net command, which is part of the Samba suite and is found in the samba-client package mentioned earlier in this hack:

 $ net join member -U Administrator 

You'll be prompted for the Administrator password for the target domain. You do not have to join as the user Administratorany user with sufficient privileges to join the domain will do.

1.6.7. Testing Windows Authentication

You should always test any fundamental change to your system's core authentication sequence before logging out of your system. The easiest way to do this is to enable a service that requires login authentication and then use this to log in via a network connection to your system while you are still actually logged in on the machine. My favorite service for this is the telnet service, but ssh is just as easy (though you will have to modify the /etc/pam.d/sshd PAM configuration file in order to test ssh authentication via your Windows domain controller).

1.6.8. Debugging Windows Authentication Problems

Both Samba and the pam_winbind.so PAM provide excellent debugging options. To put the winbindd daemon in debug mode, log in as root using a local account, add the debug keyword to the pam_winbind entry in the PAM service configuration file that you are using for debugging, and restart the winbindd daemon manually with the -d debug-level option, which displays tons of useful information. I prefer to use debug level 5, which shows each byte in every packet exchanged by the winbind daemon and the domain controller that it is talking to. If this doesn't provide you with enough information to identify and resolve your problem and you suspect Samba misconfiguration, you can increase the logging level in the Samba configuration file (/etc/samba/smb.conf) by adding the log level winbind:NN command and restarting Samba. This enables you to specify the logging level for Samba activities related to winbind authentication. If you are using an older version of Samba or want coarser logging, you can remove the winbind restriction and simply increase the general Samba logging level by using the command log level NN in your Samba configuration file and restarting Samba. A log level of 5 is sufficient for most debugging. (Remember to disable logging when you've resolved your authentication problems, as this creates a huge logfile and has a negative impact on Samba performance.)

Another useful command when analyzing or debugging problems with using Windows domain authentication to authenticate Linux users is the wbinfo command. You can use this command to make sure you're actually talking to the domain controller and to query the domain controller for various types of information. The following output example shows both the options available to the wbinfo command and a sample command that retrieves the names of known users from the domain controller:

 $ wbinfo Usage: wbinfo -ug | -n name | -sSY sid | -UG uid/gid | -tm | -[aA] user%password Version: 2.2.7-security-rollup-fix -u lists all domain users -g lists all domain groups -n name converts name to sid -s sid converts sid to name -N name converts NetBIOS name to IP (WINS) -I IP converts IP address to NetBIOS name (WINS) -U uid converts uid to sid -G gid converts gid to sid -S sid converts sid to uid -Y sid converts sid to gid -t check shared secret -m list trusted domains -r user get user groups -a user%password authenticate user -A user%password store user and password used by winbindd (root only) -p 'ping' winbindd to see if it is alive --sequence show sequence numbers of all domains --set-auth-user DOMAIN\user%password set password for restrict anonymous $ wbinfo -u _Template Administrator bill.vonhagen build [additional output deleted] 

1.6.9. See Also

• http://rpm.pbone.net

• http://www.rpmfind.com

• "Customize Authentication with PAMs" [Hack #4]

• "Centralize Logins with LDAP" [Hack #6]