If you've networked more than one or two systems together, you already know how difficult it is to maintain consistent user and password information across all your machines. Here's a better way.
The first step when working on any multi-user system is logging in, which consists of typing your username and password and proving to the computer that you are who you’re claiming to be. The general term for successfully proving your identity to the system is “authentication.” The authentication process makes possible all of the other security measures provided by the computer’s operating system, such as determining who can read, write, and execute certain files and programs, who can kill certain processes, etc.
However, proving your identity to a single computer system isn’t all that useful if what you really need is access to resources residing on other systems located elsewhere on the network. This is exactly the situation that exists with the Internet and World Wide Web, which represent a distributed computing environment where network based storage, services, and processing power are available 24/7 to users logging in from all over the world.
So what’s really needed is a mechanism that would allow users from all over a network to authenticate themselves on any computer that is located on the network, thereby accessing the resources stored there. Luckily, there are a variety of powerful systems available for dealing with this problem, and this article will cover what they are and how to set them up.
Authentication Then and Now
Long ago, when no computer system was really connected to any other computer system each computer maintained its own list of valid usernames and related passwords. On early Unix systems, this information was stored in a password file (/etc/password) that was local to each Unix system. Similarly, the list of groups that you belonged to was stored in a group file (/etc/group), which was also local to each machine. At the time, these local files were the state-of-the-art for system security.
As networks became more and more integral to the standard computing infrastructure, people needed to use greater numbers of machines and networked resources. This quickly exposed some fundamental problems with maintaining authentication information in standalone system-specific files. For example, if you routinely used two different computers and wanted to change your password, you had to change your password on both systems. Any changes made to your account on one system had to be made in exactly the same way on all the systems that you planned to use.
Some of the early solutions to these sorts of problems consisted of having monolithic programs run during off hours and synchronize password and group files between all the machines that users required access to. Not surprisingly, failures of these programs could leave the password and group files in a confused or — worst case — unusable state.
It quickly became apparent that the key to solving this problem was to store the authentication database or files on a server located on the network, rather than on each individual computer system. The other machines on the network can then access the authentication information in a client/server fashion. You still have to authenticate on each machine that you want to use, but each machine is a client of the central authentication server. Since the user and group authentication information is stored in a central network location, if you need to make any changes you only have to make them in one place — on the authentication server.
Authenticating to a single, central network resource is a great time saver for users and system administrators alike. Unfortunately, it also introduces the possibility of a single, central point of failure. What this means is that if the networked authentication server ever goes down, no one will be able to log in anywhere. For this reason most modern networked authentication mechanisms are now available on several computer systems simultaneously; if you are not able to contact one of them, then you should be able to contact one of the other servers.
Distributed Authentication Concepts
Distributed authentication is the general term for an authentication mechanism that is available over a network and which many different machines can, therefore, access. Today, almost all distributed authentication mechanisms use the client/server model. This means that any computer system on which users want to authenticate will check with a central authentication server to verify that particular user’s identity, password, and privileges.
Computing environments with a relatively small number of hosts may run their authentication servers on systems that also provide other services, but this practice is not recommended. The security of an authentication server is obviously quite important. Limiting the number of users that can log into an authentication server and the number of other services that it provides reduces the number of ways that its security can be compromised. Minimizing the number of processes that can be running on an authentication server also increases its response time to authentication requests.
Almost as important as the security and optimization of the authentication server is the need to replicate the authentication server. This means that while one primary authentication server satisfies authentication requests, there are usually one or more other systems that maintain up-to-date copies of the authentication information stored on the primary server. If the primary authentication server goes down, the replicas of the primary authentication server begin to service authentication requests until the primary server comes back online.
Providing alternatives to a single distributed authentication server is extremely important. Having a file server go down prevents people from accessing specific files; having a networked authentication server go down is much more serious because it can prevent people from actually logging in on any computer system. Some of the distributed authentication mechanisms in use today offer some rather clever workarounds to this sort of problem, as we will see later in this article when discussing specific authentication mechanisms.
A final criterion of distributed authentication mechanisms is that they must scale well. They should be designed to perform well regardless of the amount of authentication information that they maintain and the number of clients that they serve.
Integrating Distributed Authentication With the Login Process
Historically, incorporating distributed authentication mechanisms into the standard Unix login process has involved replacing the /bin/login program with a customized login program that knows how to use a specific distribution authentication mechanism. This is the case with many third-party distributed authentication systems. Some distributed authentication mechanisms, such as Sun Microsystems’ Network Information System (NIS) and NIS+ (its successor), use existing system control files to identify whether a computer system should retrieve authentication information from the password file, from NIS, or from some other authentication mechanism. Though this is an improvement over replacing the /bin/login program, it still isn’t a complete or extremely flexible solution.
Fortunately, a highly flexible new approach to incorporating authentication information into the login process has emerged recently. The new approach is based on the use of Pluggable Authentication Modules (PAMs), which are small programs that implement different authentication mechanisms. These are called by programs that require authentication and, therefore, prevent these types of programs from needing to have a specific authentication mechanisms wired in. For example, before PAMs, incorporating a new authentication mechanism such as Kerberos into the login process required rewriting the login program.
When using PAMs, incorporating a new authentication mechanism into your current login process is as simple as writing a PAM that implements Kerberos and listing that PAM in system configuration files such as /etc/pam.conf or the /etc/ pam.d directory. PAMs were originally implemented in Solaris but have gained momentum and popularity through their use in most Linux distributions. For more on PAMs, see the Web Links section at the end of this article.
Overview of Present and Future Distributed Authentication Mechanisms
The next few sections discuss some of the more popular distributed authentication mechanisms that are in use today. Again, for more detailed information about any of these authentication mechanisms, see the Web Links section at the end of this article.
Kerberos: Birds Do It, Bees Do it, Now Even Microsoft Does It
Kerberos is a distributed authentication service that was originally developed at the Massachusetts Institute of Technology (MIT) for use with MIT’s Athena project, the distributed computing environment used at MIT. Kerberos is designed to provide secure authentication for client/server applications by using strong cryptography to enable clients to prove their identity to servers. Once a client and server have used Kerberos to prove their identity to each other, they can optionally encrypt all of their communications to ensure privacy in subsequent communications.
Internally, Kerberos is much more complex than the other distributed authentication mechanisms described in this article. In its simplest form, Kerberos works by exchanging encrypted security information between clients, the Kerberos Authentication Server, and the resource that you are trying to access. One of the interesting things about Kerberos’ functionality is that it does not simply authenticate the user alone — it also authenticates the actual host computer the user is connecting from. The information that is initially exchanged when attempting to prove one’s identity is known as a “ticket.” The information used to encrypt tickets and subsequent communications is known as a key.
Kerberos is often referred to as a trusted third-party authentication service because each participant in the Kerberos authentication process believes in Kerberos’ assessment of the identity of the other parties in that process. Kerberos verifies each participant’s assessment using private keys that each participant generates during every stage of the authentication process.
Kerberos is very robust and secure due to the fact that all stages of the authentication process exchange encrypted information. At no point are passwords transmitted over the network without first being encrypted. (Authentication wizards refer to sending password as visible, unencrypted text as sending them “in the clear.”)
Kerberos was popularized by its use at MIT and in the AFS distributed file system, developed at Carnegie-Mellon University, Transarc Corporation, and now available as both a supported IBM product and an Open Source project. The security provided by Kerberos is so well respected and robust that Microsoft has adopted Kerberos as an underlying authentication model for Windows 2000 and subsequent versions of Windows. For more information about Microsoft and Kerberos, see the Microsoft’s Changes to Kerberos sidebar below. If you would like more information about Kerberos in general, see the Web Links at the end of this article.
Microsoft’s Changes to Kerberos
Microsoft’s adoption of Kerberos is a monumental event because it demonstrates that Microsoft is paying close attention to the security concerns of its users, as well as being aware of popular security mechanisms outside the scope of Microsoft’s own OSes.
In order to most easily integrate Kerberos into the authentication mechanisms currently used by Windows systems and applications, Microsoft felt the need to extend some of the functionality of Kerberos in ways that have not yet been fully released to the software development community. This is somewhat unfortunate because it undoes much of the good will that Microsoft had accumulated from adopting a well-respect security system that was not developed on the Microsoft Campus. For example, Microsoft uses an authorization extension in the Kerberos standard, called the “Auth Data” field, in a way that is not interoperable with other systems running Kerberos, such as AFS or Athena. Microsoft has announced its intention to publish its format and rationale for use so that other implementations of Kerberos will be able to interoperate with Microsoft’s. We’ll have to wait and see…
The Light-Weight Directory Access Protocol
The Light Weight Directory Access Protocol (LDAP), originally proposed in RFC 1777, is a client/server mechanism that runs over TCP/IP and is used to store large amounts of hierarchical information in a fashion that allows it to be accessed quickly over a network. LDAP directories are much like databases except that they are optimized for reading rather than for writing and are tree-structured rather than relational or object oriented. These features combine to make LDAP well suited for storing information about users, since user information is accessed frequently (for example, each time a user logs in on a machine) but is updated relatively infrequently. (When was the last time you changed your password? No, don’t tell me…)
|Figure One: LDAP directories show individuals hierarchically.|
LDAP directories are based on entries, which are a collection of at-tributes that can be uniquely identified using a distinguished name (DN), which is essentially the full path from that entity to the root of the LDAP tree. A small, sample LDAP directory is shown in Figure One, which hierarchically represents individuals within organizational unit, within companies, within countries. In this figure, the path to the entry for “Bill von Hagen” would be “cn=Bill von Hagen, ou=writers, o=WordSmiths, c=US.” The full distinguished name specification is available in RFC 1779, “A String Representation of Distinguished Names.”
Each attribute has a specific type and contains one or more values. Attribute types are typically strings whose names are abbreviated suggestions for the content of that attribute (such as “sn” for surname, “mail” for e-mail address, and so one). Attributes can be identified as being mandatory or limited to a certain set of values using a special attribute called “objectClass,” which identifies the content rules for those attributes.
All LDAP implementations provide operations for updating LDAP directories by inserting or deleting entries, changing existing entries, and modifying entry names. Since it is primarily designed as a readable source of information, LDAP implementations provide fast search operations that let you retrieve attribute values after locating the appropriate entities.
The most popular LDAP implementation currently in use is the University of Michigan’s SLAPD (Standalone LDAP Daemon). This LDAP implementation provides its own authentication mechanism and also enables administrators to control access based on IP address, domain name, and so on.
The Network Information System and Network Information System Plus
The Network Information System (NIS) is the oldest distributed authentication mechanism that is still in common use today, having been introduced by Sun Microsystems way back in 1985. Originally known as the “Yellow Pages” (or just “yp”), this distributed authentication mechanism was quickly renamed NIS because of a name/copyright conflict with some other commercial entity that I can’t think of right now. The names of many of the NIS utilities still reflect the original name of NIS; for example, “ypcat” lets you cat (in the Unix sense, i.e., concatenate and print) the contents of any file stored in NIS.
As with its Network File System (NFS), Sun was wise enough to release the basic specifications of NIS to the public, causing NIS to be made available on most Unix and Unix-like platforms then and now. Much like NFS, this has made NIS the most commonly used and popular distributed authentication mechanism in use today — you can’t beat the price or easy availability since NIS comes free with most Unix and Unix-like operating systems.
Sun showed a great deal of foresight when creating NIS in that NIS was designed to be a central repository for much more than just authentication information. Any files and information that you want to share across multiple systems can be stored and shared in NIS, including group files, host files, mail aliases, the /etc/services file (which lists valid network services for your computing environment), and so on. NIS is also very flexible and is not limited to being used with standard Unix system files; you can also use NIS to store and provide site-specific files and information. NIS is designed to be replicated, intrinsically supporting the notion of a master NIS server and replicas of that server known as “slaves.”
As mentioned earlier in this article, the ability to handle the failure of a distributed authentication mechanism is a critical aspect of a successful implementation. NIS handles this problem nicely. When you access a file on your Linux system that is actually stored in NIS, the file that you see is usually the combination of a file stub located on your local system and a bunch of NIS information that the server has appended to the stub. So if your NIS servers ever go down, you will still have administrative access to that system because, for example, the root password for your local system is stored in the stub of the password file stored locally. Even if your NIS server is dead, you were not running copies (slaves), and your NIS environment is therefore hopelessly broken, you can still restore service to your users relatively quickly after logging in as root by recreating the password file locally on critical machines.
NIS data files are known as maps. Each NIS map is typically provided in several different formats, each organized to optimize a specific type of access to that information, such as lookups by name or by some unique numeric component (such as being able to access a group map by group ID, a host map by host address, and so on).
NIS+, also from Sun Microsystems, is the successor to NIS and organizes information hierarchically, much like LDAP. NIS+ was designed to handle the requirements of today’s larger, more complex networks, but it is not nearly as widely used as plain old NIS.
For an example of how to set up NIS for use on Linux, see the Using NIS on Linux Systems sidebar on pg. 54.
The Novell Directory Service
Despite what some writers have said about the future of Novell’s NetWare product for computer networking, Novell isn’t ready to throw in the towel just yet. Realizing that TCP/IP-based networking has won out over Novell’s proprietary networking protocols, the folks at Novell have spent a good amount of time and money in researching new products and directions. The most interesting and promising of these is the Novell Directory Service (NDS), a directory service that is implemented on top of an LDAP directory.
In a refreshing break with the largely proprietary nature of their historical products, Novell has been releasing parts of NDS to the open source community in the hope that NDS will become a common mechanism for maintaining distributed directories of information. However, the majority of Novell’s NDS is still a product (known as “eDirectory”) that costs real money. But the bright side is that it is actively supported on a variety of Unix platforms and various flavors of Windows.
In today’s networked environment, on-the-go computer users need to be able to access their files from a variety of locations under a variety of circumstances. Universal access to networked files and directories requires a similarly universal, widely available authentication mechanism, such as the ones discussed in this article. Of course, networked, distributed authentication mechanisms introduce new challenges to system administrators (and hackers) in terms of security and management, but in return they promise higher availability, easier access to information from anywhere, and eventually, higher productivity. The gain is definitely worth the pain.
Using NIS on Linux Systems
As mentioned in the accompanying article, NIS is the most commonly used distributed authentication mechanism today, largely because it is shipped free with almost all Linux and Unix-like systems. Another reason for the prevalence of NIS is that it’s incredibly easy to set up, as shown in this sidebar, which walks you through the process of setting up NIS with a single client and server between systems running Red Hat 6.2 and 7.0.
NOTE: This is an extremely minimal NIS environment used as an example to illustrate how quickly you can set up and begin using NIS in your environment. As such, it exports the default password, group, host, etc. maps (files) found on the NIS server system. In a production environment, you would want to do substantially more customization before initiating NIS on your systems. You would also want to customize the NIS configuration files /var/yp/securenets, /etc/yp.conf, and /etc/ypserv.conf. For more complete information about setting up NIS, see an authoritative source such as O’Reilly & Associates’ “Managing NFS and NIS.”
Setting up a Minimal NIS server
To set up a minimal NIS server, log in as or su to root on the system you are using as a sample NIS server and do the following:
1. Make sure that the NIS software is installed on your Linux system. At a minimum, you will need the /bin/domainname, /usr/sbin/ypserv, and /usr/lib/yp/ypinit programs. If these programs are not found on your system, load the ypserv and yp-tools packages from your Red Hat CD or retrieve them from an RPM archive site and install them.
2. Next, make sure that the /etc/passwd file has an entry for your personal account, which should also be found in the password file on the system you will be
configuring as an NIS client. We’ll use this for testing later in this sidebar.
3. Set the domain name of your new NIS domain. This should not be the same as the name of your TCP/IP domain, so as to avoid confusing DNS and potentially compromising security in your domain. To set the NIS domain name (in this case to the domain foo.com), issue the following command:
4. Start the NIS server process using the command:
5. Initialize the NIS databases using a command like the following:
You will see output listing the files that have been generated and added to the NIS database.
That’s all there is to it for this minimal example. Your new NIS server is up and running.
Setting up a Minimal NIS Client
One of my favorite Zen sayings is, “If a server is running and there are no clients to use it, is it really working?” This section explains how to set up a minimal NIS client (of the server started in the previous section of this sidebar) after doing some initial configuration to be able to verify that the server is actually doing “the right thing.”
To do some preconfiguration to verify that NIS is actually working, log in as or su to root and edit the /etc/nsswitch.conf file on the system you are using as an NIS client. Find the line that tells your system how to locate password entries and modify that line to look like something like this:
passwd: nis [NOTFOUND=return] files.
This tells your system to look for password information in NIS and fail if the appropriate information isn’t found.
Next, save a copy of your system’s password file and then truncate the existing password file after the entry for halt. As the last line of the newly-abbreviated password file, add the following:
After doing this, your password file should look like Figure One at right.
This tells NIS to append the contents of the password map (file) retrieved from the NIS server whenever password information is requested.
Notice the entries for individual accounts have been removed from the abbreviated password file. This enables us to do a simple test to determine whether NIS is working; if you can log in using an account not present on your client system but which is present in the password file on your NIS server system, then NIS is working correctly.
To set up a minimal NIS client, log in as or su to root on the system you are using as the NIS client and do the following:
1. Make sure that the NIS client software is installed on your Linux system. At a minimum, you will need the /bin/domainname and /sbin/ypbind programs. Again, if these programs are not found on your system, load the yp-tools package from your Red Hat CD or retrieve them from an RPM archive site and install them. You would want to use many other NIS-related applications in a production environment, but these two programs will suffice for our simple test.
2. Make sure that the directory /var/yp exists and create it if it does not.
3. Set the domain name of the NIS domain to which this new client will belong. This should be the same name as the domain name set in the previous section of this sidebar, so issue a command like the following:
4. Start the NIS client process using a command like the following:
5. To verify that NIS is working correctly, telnet from the NIS client system back to itself and attempt to log in as yourself. Remember that your password file entry is present in the password file on the NIS server but not in the password file on the NIS client.
You should now be able to log in. Congratulations! You’re running NIS!
Bill von Hagen is president of Move2Linux.com. He can be reached at wvh@ movetolinux.com.