Use one ID to access multiple systems
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.
Prev. page
[1]
2
3
next page 
