Chapter 2: Linux Authentication Services

Overview

Authentication is the point at which some server provides your clients the "keys" to get on the network and do stuff. Without authentication, you can't really get around or do too much. Sure, you can authenticate to your local box, but that's not that exciting. It only really gets exciting when you have some kind of centralized authentication authority for your network. (Okay, perhaps our definition of exciting is different than yours, but we digress.)

Older Windows authentication (NT 4 and earlier) used NT authentication (LM, NTLM, and NTLMv2 protocols). Modern Windows authentication uses Kerberos (or, if necessary, it can drop down to NTLMv2) with user information stored in Active Directory for centralized authentication. Though some shops certainly still use Novell's eDirectory or possibly even other services, Active Directory is pretty much the industry standard way Windows clients get on the network.

Unix and Linux traditionally store accounts and passwords locally in a file called /etc/passwd (or possibly a combination of /etc/passwd and /etc/shadow .) Inside an /etc/passwd file, you'll find a simple list of lines, one line for each user, laid out like this:

  accountname  :  password  :  uid  :  gid  :  GECOS  :  directory  :  shell  

Here's a breakdown of what all this stuff means:

• accountname What the user is called on this specific Linux machine. A user might have a totally different accountname on another system.

• password Unix systems never store passwords directly. Instead, they store the result of hashing the password using a cryptographic function. When the user attempts to log in, the password entered is also hashed and then compared to the password hash. Originally, this was considered good security because having the password hash doesn't tell you what the user's password is. However, it does allow you to make password-guessing attempts as fast as you like using an automated process, so most modern Unix systems don't store the password hash in /etc/passwd . Instead, it is stored in an additional file called /etc/shadow as part of a scheme called shadow passwords . Since only the root user can read /etc/shadow , this is an effective way to limit the speed of password guessing attempts. On a typical Fedora Core 3 system, the password field in /etc/passwd just contains an "X"

• uid This is the user identifier . Each user must have a unique uid on any particular Linux machine.

• gid This is the default group identifier . A user can be a member of more than one group, and the /etc/group file records additional group membership information. However, every user is always a member of a default or primary group. The group ID number (gid) of the user's default group is given here. Group IDs and group names are defined in the /etc/group file.

• GECOS No, this isn't the company that can save you 15 percent or more on car insurance. This is the General Electric Comprehensive Operating System field. It typically contains only the full name of the user, but it can also contain the user's full name , office location, office telephone extension, and home phone number as comma-separated subfields.

• Directory This is where the home directory of the user is.

• Shell This is set to the path of the shell the user uses when they log in; for instance, /bin/sh or /bin/bash .

As noted, a second file called /etc/shadow actually contains the hashed password, plus information about when the password will expire. We won't go into detail about the password expiration fields; try the command man 5 shadow if you are curious . The /etc/shadow file is only readable by the root account, so it's got more protection on it than the /etc/passwd file, which is readable by applications and mere-mortal users.

If you're only trying to authenticate users to this local box, this little system works great. But you might need to provide access to thousands of users across 30, 300, or 3000 Linux boxes. You could set up a synchronization job to share a single /etc/passwd file between many Linux machines, but it's cumbersome at the very least. In short, you need a way to get centralized.

Linux has a myriad of centralized authentication and directory services options. These provide a shared, networked alternative to /etc/passwd files on individual unrelated systems. Here's a quick breakdown of the possibilities you could find on your Linux (or pre-Linux) network:

• NIS This system, originally designed by Sun Microsystems, helps centralize accounts. The point is to help get away from only being able to look at locally contained /etc/passwd files. Instead of looking up passwords stored on the local machine, this scheme allows administrators to put all passwords on master and secondary servers. In the Precambrian era, this was formerly called "Yellow Pages" until the phone company got all uppity and hired some lawyers and made Sun change the name from Yellow Pages to something else (NIS). NIS is not hierarchical. That means there is no efficient way to examine, for instance, only the users in the marketing department. NIS also has major difficulties working through a firewall.

• NIS+ NIS is riddled with security problems. A quick Google search for "NIS security issues" yields dozens of pages explaining all the possible attacks. A nice article that explains the problem and has some solutions can be found at www.securityfocus.net/infocus/1387 . NIS+ attempts to solve some of these problems by adding in "security levels" (and other added protections ), some support for a hierarchical structure, and other fixes for the problems of traditional NIS. NIS+ is a Sun Microsystems-centric solution that isn't generally available for Linux systems and is not included with Fedora.

• OpenLDAP This is an up-and-comer in the Unix world. It's meant to provide directory services to Unix clients. Some critics have described its scalability as needing a bit of work. It's hierarchical, which means it is potentially a better choice than NIS when a large number of accounts is involved. And, since it was designed with the expectations of modern firewalls in mind, it is also much easier to pass through a firewall than NIS.

• Samba 3. x Samba allows a Linux machine to pretend to be a Windows file server, print server, or NT 4 Primary Domain Controller, or PDC for short. Samba can also act as a Backup Domain Controller (BDC), provided that the PDC also runs on Samba. Samba 4. x (forthcoming as of this writing) will additionally provide the ability to pretend to be an Active Directory Domain Controller (yikes!). This means Samba can store accounts centrally in its own database or in an LDAP database, and then Windows users can authenticate to Samba. It is also possible, in theory, for Linux users to authenticate to Samba, but since Windows domain authentication has no concept of uids or gids, this approach can lead to aggravation. As we'll explore later in this chapter, we chose instead to layer Samba on top of LDAP. That way, Linux users can authenticate directly to LDAP, and Windows users can authenticate to Samba. One OpenLDAP server can serve as the back end for both.

  Note 

  There's another option on the horizon (but not explored in this book): Netscape Directory Server. This is, arguably, a more robust LDAP implementation than OpenLDAP, but it had one major drawback: it was expensive. Recently, Red Hat bought this Netscape asset and announced it will be open -sourcing the product. So, in theory, it will be free to use. We'll all stay tuned to see how this pans out.

• Kerberos Kerberos is a highly robust network authentication protocol, and both Linux and Windows clients and servers can use Kerberos to authenticate logons . However, Kerberos is not a directory service. Its task is to authenticate user identities, not to store information such as user and group IDs. "Kerberized" Linux systems use Kerberos in addition to, not in place of, directory services such as NIS or LDAP, which store the rest of the information traditionally found in /etc/passwd .

Table 2.1 shows a quick comparison of the more popular authentication and directory information systems.

Table 2.1: A Comparison of the Various Authentication Methods Available

	NIS	NIS+	OpenLDAP	Kerberos	Active Directory
Namespace	Flat	Semi-hierarchica	Hierarchical	Flat (but not meant to store all user details)	Hierarchical
Server Types	Master/slave	Root domain master/Subdomain master/Replica	Master/slave	Master/slave	Multi-master (in full native mode), master/slave in mixed mode
Security	Wide open	DES public/private key	SSL and/or Kerberos and SASL	Kerberos	Kerberos

In this chapter and the next chapter, we'll discuss and demonstrate how you can leverage existing Active Directory or Linux authentication services. In other words, we're going to show you how to have Linux clients use Active Directory as their authentication point and how to have Windows clients use Linux as their authentication point.

Again, this book is about harmony, not about building walls, so there might be legitimate times where you want one camp to "own" the authentication services. With that in mind, we'll present the most common cases of sharingand also of keepingall the marbles .

In this chapter, we'll survey the various Linux authentication mechanisms and show how you can get your Windows machines to utilize them.

Hold on to your hats, folks, making peace can be a bumpy ride.