| Downloads |
|---|
| 25319.zip |
As small businesses and enterprises find their closets and server rooms filling up with Windows and Linux servers, a crucial concern has surfaced: how to handle multiple logon accounts for users. Small businesses or departments that have just a few servers rarely encounter this problem. After all, it takes a systems administrator only a minute or two to reset the passwords on a few accounts spread across two or three servers. As the number of servers increases, however, this chore becomes a growing burden for systems administrators and a hassle for users.
When businesses approach vendors for a fix to this problem, vendors typically offer a single sign-on (SSO) solution. (For a detailed explanation of SSO and centralized authentication, see the sidebar "SSO vs. Centralized Authentication.") Unfortunately, implementing SSO can be difficult and expensive. An alternative solution within a heterogeneous network—a solution that works well in many environments—is to centralize user account information. This solution differs from SSO: Users are still required to log on as they move between servers, but they use the same usernames and passwords each time they access another system or service.
If your database users, software developers, and managers want to run reporting software hosted on Linux or to compile cross-platform applications, this solution can be both a time-saver and a security precaution. You'll save Help desk time because users will require fewer password resets. You also increase security because you can enforce stronger password requirements, and password resets are much easier because only one system, the centralized user database, is affected.
How do you centralize logon information? Read on for a simple and effective solution for centralizing logon information for Windows, Linux, Sun Microsystems' Sun Solaris, and FreeBSD. The solution relies on a core Windows network that runs either Windows 2000 or Windows NT 4.0. Figure 1 gives an example of such a network.
What Is It and How Does It Work?
The solution uses Pluggable Authentication Modules (PAM)—capable Linux systems. Sun Microsystems originally created PAM for Solaris. PAM is a flexible mechanism for authenticating users that provides a way to develop programs that are independent of any authentication scheme. In PAM, the authentication layer relies on a series of modules you can plug into a server's security subsystem; the modules either accept or reject a user who requires authentication. For example, if you want to use a SecurID card with Linux, the vendor will give you a PAM module that supports the SecurID hardware. Our particular solution uses Dave Airlie's pam_smb module.
The PAM system has no idea how the user is authenticated and doesn't care. It cares only whether the module accepts or rejects the user's credentials. This arrangement creates a powerful, technology-agnostic authentication layer within the OS. And as vendors release new solutions, you can easily introduce new PAM products into an existing system without having to patch or modify it.
As I mentioned, this solution relies on pam_smb, a PAM module that uses LanManager (LANMAN) to authenticate users. Essentially, pam_smb authenticates users the same way a Windows 98 machine authenticates users against a Windows server: It sends encrypted information across the network to a domain controller (DC) that stores user information. The DC then decides whether the user's credentials are correct. Unless you manually disable the feature in the registry, pam_smb uses encrypted LANMAN. (Using LANMAN raises concerns because of its vulnerability to attack over shared networks. For information about a similar solution that doesn't rely on LANMAN, see the sidebar "The Samba Solution.")
PAM modules don't require you to make difficult modifications to your Linux system. You simply compile, install, and configure pam_smb and PAM to allow domain logons.
Compiling and Installing Pam_smb
I used Red Hat Linux versions 7.2, 7.1, and 6.2 as test systems. If you're running another release, distribution, or UNIX OS that supports PAM, consult your documentation for information about how to install PAM modules.
If you're using Red Hat Linux 7.0 or later, Pam_smb is either already installed on your system or available on your installation CD-ROM with the filename format pam_smb-version.rpm. If the software isn't already installed on your system, use the Linux rpm command to install it from your installation CD-ROM:
# mount /mnt/cdrom # cd /mnt/cdrom/RedHat/RPMS # rpm -Uhv pam_smb-<version>.rpm
The first command above mounts the Red Hat Linux distribution CD-ROM. The second command changes to the Red Hat Package Management (RPM) System directory, in which the OS stores software packages. The third command installs the RPM file pam_smb-version.rpm, where version is the version of the package on your distribution CD-ROM. The U, h, and v options, respectively, tell rpm to install the specified package, display a status bar as you install the package, and print verbose information during the installation process.
If you aren't running the latest release of Red Hat Linux or if you aren't running Linux but have PAM-capable systems, you must download and install pam_smb yourself. First, download the software from http://www.skynet.ie/~airlied/pam_smb. I used release 1.1.6 because it's the most current production release, but you can get a later development version, release 1.9.9, from Concurrent Versions System (CVS) at http://cvs.samba.org. (CVS is a network-transparent revision-control system that both open- and closed-source software projects use heavily. For more information about CVS, go to http://www.cvshome.org.) Release 1.9.9 fixes several simultaneous-authentication problems and adds multidomain and username mapping support.
After you download the software, copy it to a test Linux system, then use the tar command to extract the files from the archive. For example, the command
# tar xvfz pam_smb-1.1.6.tar.gz
extracts pam_smb source code from the pam_smb-1.1.6.tar.gz archive into the current directory. (As with rpm and most UNIX and Linux commands, tar relies on command-line options. In this case, the x, v, f, and z specify that tar perform an extraction, run in verbose mode, extract from a file specified in the command line, and uncompress the file using gunzip before extracting the files.) Next, change to the source directory:
# cd pam_smb
You're now ready to compile and install the software. Like most open-source software, pam_smb relies on Autoconf, a source-code-configuration utility available under the Free Software Foundation's (FSF's) GNU's Not Unix (GNU) General Public License (GPL). Autoconf is almost always installed when you install the Linux OS. However, if Autoconf isn't installed on your system, you can find it on the distribution CD-ROM, usually as an .rpm file (autoconf-version.rpm). Autoconf lets the source code configure itself to your system to ensure maximum compatibility. Start by running the configure script that's included with the pam_smb source code:
# ./configure
At this point, the software is ready to compile, so you can begin the make process:
# make
Finally, you must manually copy the compiled module, pam_smb_auth.so, to /lib/security, the location for PAM modules:
# cp pam_smb_auth.so /lib/security
With the software compiled and installed, you can configure the software.
Configuring the Software
Configuring pam_smb requires that you inform the module of your domain and the names of the domain's PDC and BDC, and that you alert PAM to the new module's presence. Begin by configuring the domain and DC information.
Edit the text file /etc/pam_smb.conf and enter your domain's name and the name of one or two DCs. (You can use any editor that's installed on your system, such as vi, emacs, joe, or pico.) The workgroup name goes first; subsequent lines contain DC names:
EXAMDOM PDC1 BDC1
Entering multiple DCs allows for redundancy. Unfortunately, pam_smb supports only two DCs, so select two that are physically close to each other and are stable.
Typically, pam_smb (and many Linux services) is dependent on TCP/IP. That dependence isn't a problem, but it can cause confusing errors when you expect a network service to use broadcasting or some other Windows-centric method to resolve computer names. Instead of relying on broadcasting, specify a resolvable host name for your DCs. If you aren't using DNS, add entries to /etc/hosts (/etc/hosts contains static mappings of hostnames to IP addresses) to establish the mappings:
192.168.0.50 pdc1 pdc1.example.com 192.168.0.51 bdc1 bdc1.example.com
Now that pam_smb is configured, you must update PAM to use the new module. You need to know only two core facts about PAM. First, each service that relies on PAM uses a configuration file that in Red Hat Linux is located in the directory /etc/pam.d. For example, Telnet uses the configuration file /etc/pam.d/login and Secure Shell (SSH) uses /etc/pam.d/sshd. Second, each configuration file contains a series of lines that specify which modules the service should use and how to use them. We'll concentrate solely on configuration lines that begin with auth and configure that service's authentication requirements.
Start by configuring Telnet to use logons for Windows accounts. In Red Hat Linux 6.2, when you view /etc/pam.d/login, the configuration file will look like the example that Listing 1 shows.
You can ignore everything except the lines that begin with auth (the first three lines in the sample file). The first line, pam_securetty, determines which terminal a user logs on to; the third line, pam_nologin, checks for /etc/nologin, which disables system logons. (Systems administrators use /etc/nologin as a temporary measure to stop users from entering the system.) We're interested in the second line, which contains pam_pwdb.
The pam_pwdb modules check a user's credentials against /etc/passwd, the system password database. Our goal is to modify the authentication process so that the system will instead authenticate users against the DC. Add the following configuration line after the pam_securetty.so entry:
auth sufficient /lib/security/pam_smb_auth.so debug
This configuration line specifies that this authentication service use the auth keyword. The sufficient keyword informs PAM that if pam_smb accepts a user's credentials, that action is sufficient for allowing access. Because you've left the pam_pwdb entry intact, if pam_smb rejects the user's credentials, PAM will request that pam_pwdb perform its own check. (This step is necessary if, for example, you want to let the system's administrative user, root, log on if the system can't access the network.) The debug parameter specifies that pam_smb log all authentication attempts, successful or not, to syslog. Typically, you'll find this output in /var/log/secure or /var/log/message. After you're sure pam_smb is working, you can remove this parameter.
For newer Red Hat Linux releases (e.g., version 7.2), in which you install pam_smb by source and not by using RPM, the /etc/pam.d/login configuration file will look a little different because Red Hat Linux 7.2's PAM configuration is slightly different from Red Hat Linux 6.0's configuration. Regardless, you'll use the same method to configure Telnet to use logons for Windows accounts. Simply add the pam_smb configuration line immediately after the pam_securetty.so entry. The modified configuration file will be similar to Listing 2.
You've now configured pam_smb and PAM. Although Linux will now authenticate users against your DCs, users must have local accounts. To meet that need, create a user on the system that corresponds to the Windows account. For example, if a user named john is going to log on, create the same user on the system:
# useradd john
This step isn't strictly necessary; pam_smb has an optional feature that authenticates users who don't have local system accounts. However, this feature is primarily for use by services that need to authenticate users without giving them interactive access to the system. Because our users need interactive access, this option doesn't apply.
Think of the Possibilities
After you install pam_smb, users can easily and efficiently log on to your Linux servers. You should now be ready to configure other services, such as SSH and FTP, to use pam_smb.
Any system that allows centralized authentication requires users to remember fewer passwords. The passwords users choose can be more complex, and thus, more secure. In addition, because pam_smb is open source, you can modify its code to suit your environment, extend the utility's abilities, and further organize your logon capabilities.
Systems administrators who use pam_smb might be concerned about its reliance on LANMAN. Even when LANMAN is encrypted, it isn't entirely safe from attack in a shared-network environment. However, comprehensive solutions are available that don't rely on LANMAN.
One such solution is Samba, which now offers Windows 2000 and Windows NT 4.0 directory integration. To accomplish this integration, Samba uses a new service known as winbind, which works in conjunction with Linux's authentication subsystem. For more information about Samba and winbind, visit the Samba Web site at http://www.samba.org.
