Using Standard Active Directory for Linux Authentication (via Winbind)

Just now, we joined a Windows XP computer to the ad.corp.com . domain. We'll assume the name was xppro1 (the same name we recommended you use in Chapter 1). This enables users in Active Directory to sit down at an Windows XP machine and log on to Active Directory. You can see this in Figure 3.3.

Figure 3.3: Windows and Linux clients can both bind to an Active Directory domain.

Linux machines can leverage Active Directory as the "go to" source for their account information. That is, you can have an Active Directory user sit down at a Linux machine and log on. This is likely desirable if you already have Active Directory; leveraging centralized account information is a good thing.

As we stated, in this chapter we're going to present two main ways of leveraging Active Directory for your Linux clients. In this first section, we'll be exploring Winbind (a subset of the Samba tools.) Winbind is great because it requires no changes to Active Directory. For those seeking to integrate Linux into an environment where changes to the Windows server are politically or practically impossible , that's very good news.

Now, here's the bad news about Winbind: it's tricky to set up Winbind correctly, and support for it in the Red Hat/Fedora GUI tools is incomplete at best. We'll spend some quality time navigating some command-line steps and performing a gaggle of edits to some configuration files.

Also, Winbind can cause consistency and security problems, as shown in the sidebar "How Winbind Fakes Linux User IDs (and How It Can Hurt)." Specifically , problems can occur where Linux users on Linux client machines attempt to copy files back and forth among themselves using a Linux-based NFS server. Problems can also occur if Winbind's Windows-to-Linux user ID mapping data is lost for any reason. See the sidebar for more information about this issue.

Go ahead and utilize this section on Winbind if you simply cannot convince your Active Directory administrator to embrace Microsoft's Services for Unix 3.5. The solution we high-light later in the chapter, in the "Extending Active Directory with Unix/Linux Information" section, is a much more complete, more robust, and ultimately more maintainable solution. However, it does require some cooperation from both the Linux and Windows sides to make it work.

How Winbind Fakes Linux User IDs (and How It Can Hurt)

Winbind helps Linux client systems be a member of a Windows domain. And when the full cooperation of the Windows administrator is not available, Winbind can't be beat. That's because a Linux client running Winbind looks like a real Windows client from the server's point of view.

But making a Linux client look like a Windows client introduces a thorny problem. Windows 2003 doesn't have a native capability (out-of-the-box) to store Linux user IDs in the same format as Linux. Windows uses a two-part user ID combination called a Security Identifier, or SID. SIDs can also identify groups and computers, but for right now, let's concentrate on users. A user SID might look like S-1-5-21-2460136348-1980938915-682000001-512

The SID is made up of a domain identifier and unique relative identifier, called a RID. The complete SID uniquely identifies a user, but it contains too much information to "fit" in the space of a normal Unix UID. A Unix UID is just a flat number, like 1002.

In the general case, a Windows SID can't be stuffed into a Linux UID. So when a Windows user logs on to a Linux machine, Winbind tries to cope. Winbind arbitrarily invents a local UID for each Windows user who logs in. Then Winbind maintains a table of which Windows user logged in and what local Linux UID they're arbitrarily getting. Here's the problem: Each Winbind-enabled Linux machine maps these local Linux UIDs separately to Windows users.

In most cases, though it's a bit sloppy , it usually works. As long as the Windows user (logging onto a Linux machine) transfers files through a Windows or Samba file server, there's no problem. But these safeguards can be circumvented in at least two cases (that we know of):

Case 1: Joe and Jane Arbitrarily Get the Same UID from Two Different Linux Workstations

The Linux clients attempt to use a Linux-based NFS (Network File System) server to share files. (We'll explore NFS in more detail in the next chapter, so bear with us.) NFS identifies users by UID and expects that UIDs will be consistent between computers. With most centralized authentication systems, that would be a reasonable expectation, but since Winbind assigns user IDs to Windows SIDs on a per-workstation basis , the following scenario can occur. There are two Linux workstations involved, adlincli1 and adlincli2 :

• Jane logs into adlincli1 for the first time. Winbind on adlincli1 arbitrarily assigns her the UID 5010.

• Jane creates files and copies them to the NFS server. These files now belong to UID 5010 on the NFS server. She sets the permissions so that the files should only be readable by her.

• Joe logs into adlincli2 for the first time. Winbind on adlincli2 arbitrarily assigns the UID 5010 to him. Remember, Winbind's UID mappings are independent on every Linux workstation .

• Joe attempts to access Jane's files on the NFS server and succeeds , because he has the same UID.

We really don't want Joe to see Jane's files, but because they are arbitrarily assigned the same UID on their local Linux machine, the security is circumvented. NFS doesn't magically prevent this.

Case 2: User ID Mappings Are Lost on a Workstation

Imagine now that a month goes by. The administrator accidentally deletes the location on the Linux workstation that holds the Windows user to Linux UID mapping table. Specifically, the location is /var/cache/samba .

Samba is successfully reinstalled, but the user ID mappings (stored in /var/cache/samba ) have been lost.

The system shows that many files on the hard drive belong to UID 5010, but which Windows user does this correspond to? Nobody knows .

To recover from this, the system administrator asks each Windows user to log in to adlincli1 . But doing so creates a new UID mapping. The user IDs will not match their old values. The old mapping, having been lost, can only be recovered the hard way: the system administrator must manually reassign files to the new UIDs.

Ouch!

Samba, theoretically, offers a way to centrally manage SID to UID mappings through a central LDAP server, but there are currently no standard tools for making that magic happen.

Our recommendation to alleviate this problem is a one-two punch using free stuff. Later, in the section "Extending Active Directory with Unix/Linux Information," we'll show you how to do it using:

• Microsoft's Services For Unix 3.5 (with Active Directory). This will get us Linux account information inside Active Directory. We'll also describe in general how Windows 2003/R2 has similar functionality (and what you'll do when you're ready for Windows 2003/R2).

• Fedora's LDAP authentication mechanism to ask Active Directory for account information. Because Active Directory will be enhanced to additionally store Linux user IDs directly, we'll be in clover.

Before we continue, there is some additional hope on the horizon. Some ultramodern versions of Winbind and Samba offer the option of determining the Unix user ID based on the Windows RID of the user.

Since the Windows RID is unique within the domain (and takes the same basic "flat" format as a Linux UID), Winbind wouldn't have to arbitrarily make up any ol' ID. It could just determine what Joe and Jane's Windows RIDs were and use them as Linux UIDs. If you choose to research this option, the new mechanism in Samba that supports this is called idmap_rid .

This could be a very attractive option for environments containing only one Windows domain, but it falls apart in multidomain environments because the RID for a user Harold in the CORP domain might be the same RID as a user Gary in the FLORP domain. There would be no way to distinguish Gary's files from Harold's files when present on a single Linux client.

As of this writing, idmap_rid is not standard in Fedora Linux. If you want to go at it alone, it's conceivable that you could compile your own SAMBA which includes the idmap_rid module. However, that's impractical for a variety of reasonsmostly because SAMBA is frequently updated for security reasons, and you'd have to recompile that extra feature into Samba each and every time.

In short, idmap_rid looks promising and clears up some issues, and there is an excellent chance it will be standard in future revisions of Fedora Linux. But it is not standard equipment at this time.

 

By the end of this section on Winbind, you'll have your Linux clients authenticating directly to an Active Directory domainusing only the tools found inside the box. It's not pretty, but it works.

Before you begin, let's make sure you have the supplies you need for our journey:

• You must have an Active Directory Domain Controller to talk to! In our examples, that server is called windc1.ad.corp.com .

• You'll need a Linux client you want to authenticate via Active Directory. If you don't have a machine that fits the bill, you'll need to spend some time creating one using the basic steps outlined in Chapter 1. Here's a tip: use a hostname for the Linux client that makes sense for its intended use. For instance, in our examples, we'll be going with the name adlincli1.ad.corp.com for this Linux client workstation that is going to authenticate to Active Directory.

• Regardless of how you name the client, it must be in the ad.corp.com subdomain. Otherwise , domain membership simply will not work.

authconfig : The First 90 Percent of the Journey

Fedora's authconfig tool can do 90 percent of the work associated with permitting the use of Active Directory domain logins on your Linux client workstation using Winbind. (Of course, figuring out the remaining 10 percent is what makes grown men cry. Not that I'm saying that happened while writing this book.)

First, open a terminal window and type su - to log in as root.

Next, run the command authconfig , which will present a reasonably friendly CUI (character user interface) with keyboard-driven dialog boxes. Although you must walk through these dialog boxes using the arrow keys, the Tab key, the spacebar, and the Enter key (rather than the mouse), they are otherwise roughly as friendly as regular GUI tools.

Warning 

A similar GUI-based tool does exist in Fedora, but unfortunately it does not complete as large a percentage of the task at hand. We're sure it'll be nice when it's finished! In the meantime, authconfig command can do the job properly.

authconfig will display two lists. On the left is a list of sources of user information; these resources are consulted to determine a user's full name, user ID, group ID, and so forth. On the right is a list of valid authorities to authenticate a user's password. By default, Fedora fetches user information from the traditional Unix /etc/passwd , /etc/shadow , and /etc/group text files. When "Use Shadow Passwords" is checked, then password hashes are stored in the more secure /etc/shadow file instead of /etc/passwd .When "Use MD5 Passwords" is checked, the modern MD5 hashing algorithm is used instead of the old Unix "crypt" hashing algorithm. These two should remain checked, because, at a bare minimum, we still need to be able to log into the workstation as the local root user for maintenance when network authentication is not available.

What we want to do now is add the option of logging in by an additional method. In the list on the left, put a check (a "star" really) next to "Use Winbind." In the list on the right, put a check next to "Use Winbind Authentication." You'll see this shown in Figure 3.4. Then move to the Next button and press Enter.

Figure 3.4: Use the "Authentication Configuration" screen to select both "Use Winbind" and "Use Winbind Authentication" options

In the "Winbind Settings" screen, shown in Figure 3.5, you'll specify information about your Active Directory configuration.

Figure 3.5: Use these Winbind Settings to specify your Active Directory and shell information.

Here's how to set up the "Winbind Settings" screen:

• Security Model: Select "ADS."

• Domain: Enter the short NetBIOS "Windows NT" name of your Active Directory domain. In our examples, it's AD .

• Domain Controllers: Enter the Fully Qualified DNS name of an Active Directory server. In our example, this is windc1.ad.corp.com .

• ADS Realm: Enter AD.CORP.COM in this field.

• Template Shell: We suggest you leave this set to /bin/bash , but if you have a different Unix shell standard at your organization, that's fine too. This field is necessary because an unmodified Active Directory does not contain information about the preferred Unix command-line shell of each user.

When you are satisfied with your selections as shown in Figure 3.5, click the "OK" button (not that tempting "Join Domain" buttonjust "OK").

Warning 

Although a "Join Domain" button is provided, we do not recommend using it because authconfig does not provide particularly enlightening feedback as to whether it works or not!

There's Something about PAM

While the authconfig tool looks good, it doesn't quite do the entire job. Although it configures most of the crucial authentication-related files in the system correctly, the system still doesn't have what it needs to create local home directories for users. Without a local home directory, login attempts for any user will fail. We can take care of that problem by modifying two of the configuration files used by PAM, the "pluggable authentication modules" system. The PAM standard allows anyone to add support for a new way of authenticating users. All applications that support PAM will automatically take advantage of it. A related standard, NSS, allows anyone to add support for a new way of looking up user information, also referred to as directory services . Let's get a clearer understand of both PAM and NSS.

What are PAM and NSS?

Once upon a time, Unix systems could only look up account information or authenticate users by looking at the local Linux computer's /etc/passwd file (and its relatives). In more recent years , a variety of network-based directory services have come into being, including NIS, Active Directory, and LDAP. All of these provide account information in a centralized way. Additionally, you might choose to use more than just one of these systems to store user account information, so your enterprise's account information could be distributed across many of these centralized systems.

Unfortunately, many Unix applications continued to stubbornly expect their answers from the /etc/password file. It was clear that standardized interfaces to centralized account information and user authentication were required.

Two standards emerged as a result: one for authentication and one for directory services. PAM (Pluggable Authentication Modules) is the new universal authentication interface for Unix. Anyone can create a new authentication method by writing a suitable PAM module for it, and all Unix applications that support PAM will automatically support it.

A second modern Unix standard, NSS (Network Service Switch), provides a way to tell applications which directory service they should use to look up user information.

PAM and NSS make adding support for LDAP user authentication and directory services much easier. We simply use the pam_ldap and nss_ldap modules. These provide Linux with the ability to perform authentication and directory searches, respectively, via an LDAP server. We won't have to grapple with these modules ourselves . Instead, we use the Fedora Authentication tool, which configures them for us under the hood in the /etc/pam.d configuration files.

Configuring PAM To Create Home Directories as Needed

Linux is all about choice. Because of that, you can log on to Linux in any number of ways. Specifically, you can log on via:

• The normal desktop GUI (such as gdm the GNOME Display Manager)

• Text-based Linux virtual consoles

• ssh secure remote logins

When you do log on via one of these methods, a home directory needs to automatically be created. No home directory equals nowhere to keep user information. Since Linux doesn't have a registry or a notion of user profiles, the home directory is crucial. PAM has a separate configuration file for all three methods of logging on to the system, so in all three cases, we need to tell PAM how to create a home directory if it does not already exist. Andyou guessed itsomeone has written a PAM module for that!

PAM is configured via text files in the /etc/pam.d directory. If you take a quick look inside that directory, you'll see a configuration file for any number of ways someone could "log on" to this server.

We only need to make changes to three files inside the /etc/pam.d directory: gdm , login , and sshd . We'll tell these files to create home directories for users. We need to add the following line to each file:

 session required pam_mkhomedir.so skel=/etc/skel umask=0077 

For more information on skel and umask , check out the "About skel and umask " sidebar in Chapter 2.

Use your preferred text editor (launched as root) and edit the first file, /etc/pam.d/gdm .

The /etc/pam.d/gdm file should look something like Figure 3.6 when you're done adding your one line at the end of the file.

Figure 3.6: Edit /etc/pam.d/gdm to add the last line as shown.

Next, use your text editor and modify /etc/pam.d/login .

Warning 

While inside this file, you may see a comment which says to leave the last line as is. If yours says this, enter the line circled in Figure 3.6 just before the comment.

When done, it should look like Figure 3.7.

Figure 3.7: Edit / etc/pam.d/login to create home directories for command-line logins.

Finally, edit /etc/pam.d/sshd . Enter the same line as before to the end of the file. When finished, it will look something like Figure 3.8:

• We're almost there!

Figure 3.8: Edit the /etc/pam.d/sshd file to tell it how to create home directories

Just two more steps are required:

• A bit of client-side Samba configuration to specify what a home directory path should look like for each user

• A command to actually join the Active Directory domain

Samba/Winbind Configuration

Samba, as previously mentioned, is a suite of services and client applications that provide Windows file-sharing protocols to Linux clients and servers. Winbind (the thing that gets us authenticated to Active Directory) is part of the Samba suite. Most people think of Samba as a technology that can serve up files and printers. And, sure, we'll be doing that on our servers in the upcoming chapters on file and print serving. But here, Samba configuration is still required on the Linux client to tell Fedora exactly where to create home directories when users log on via Active Directory.

It's all configured via the /etc/samba/smb.conf configuration file.

As a first step, we'll need to create a parent directory that houses our users' home drives , and we'll do it in a smart way. That is, we'll choose a top-level directory that specifically avoids conflicts should we add additional Active Directory domains later.

So, as root, at the command line, execute the following command:

 mkdir /home/AD 

In a real-world environment you will replace AD with the Windows NT-style "short" name of your Active Directory domain in all caps. Yes, that's right: IN ALL CAPS. If you try it with lowercase (as many commands and syntaxes in Linux are), it won't work. So in our case, all Active Directory user's home directories will conveniently be tucked away in /home/AD .

Now, we'll need to set the permissions on the new /home/AD directory so that everyone can list its contents (in order to find their own home directory) but only root can modify it. This is straightforward using the familiar chmod command. Here we grant read and "execute" permissions to everyone and write permissions only to root. For a directory, "execute" permission is required in order to access subdirectories:

 chmod a-rwx,a+rx,u+rwx /home/AD 

Next, edit /etc/samba/smb.conf with your text editor while running it as root. To the section of the file that begins with the line:

 [global] 

add the following line:

 template homedir = /home/%D/%U 

The %D variable is replaced with the NT-style short Windows domain name, and the %U variable is replaced with the Windows user logon name in lowercase. Thus, a user successfully logging in as AD\salesperson1 will receive the home directory /home/AD/salesperson1 . The pam_mkhomedir module we added to the login configuration files will take care of creating user home directories for those who have not logged into this particular workstation previously.

Now, restart the Winbind service using the following command, as root:

 service winbind restart 

Joining the Linux Computer to the Active Directory Domain

Once the preceding steps are completed, we are almost ready to join our Linux computer to the Active Directory domain. Just a few things to triple-check first:

• Make sure the system clocks on the client and the Active Directory server are in close agreement. Joining a domain simply won't work without it.

• Make sure the DNS name of the computer you are joining to the domain is a part of the ad.corp.com subdomain (example: adlincli1.ad.corp.com ). A name such as client.whatever.com will not work, because the Active Directory is looking for ad.corp.com not whatever.com .

As root at the command line, enter the following command:

 net ads join -U administrator 

Note 

Of course, if your Active Directory server does not have an administrative account called administrator , you will substitute the appropriate username.

When prompted, enter the password of the administrative user, which is p@ssw0rd in our examples.

Congratulations, you have joined a Linux computer to an Active Directory domain. You can verify your success by checking for the new computer in "Active Directory Users and Computers" on the Active Directory server. If you don't see it, double-check the two bullet points mentioned above: the system clocks must be in sync, and the Linux computer must be in the ad.corp.com subdomain. Then try the join again.

Logging into Active Directory via Winbind

This is it, the moment of truth: time to log in to Linux using an Active Directory account! Log out of your current session to return to the "gdm login" screen. Then, assuming you are following our examples with regard to domain and usernames, log in with the username AD\salesperson1 and the password p@ssw0rd .

If all goes well, you will receive a notice explaining that a home directory has been created for AD\salesperson1 , and your login should then complete in the usual fashion. Your Linux client workstation now accepts any login that is valid for your Active Directory domain.

If All Does Not Go Well

We suggest the following steps to resolve or determine the cause of any problems you may have when logging in:

• Make sure your Active Directory server is successfully validating logins for actual Windows XP clients. Always rule out the obvious!

• Verify that the system clock of the Linux workstation and the Active Directory server are in agreement.

• Make sure the workstation's full name includes the ad.corp.com suffix.

• Reboot the Linux workstation to ensure that all relevant services have been restarted.

• Use the tail /var/log/messages command immediately after a failed login attempt to learn more about the nature of the error.

• Bill Boswell's excellent article "Linux-Windows Single Sign-On" in the January 2005 edition of redmondmag.com is the source for much of the information in this section. Bill was instrumental in making this section possible. You can find his article at: www.redmondmag.com/ columns /article.asp?EditorialsID=858 .

• Although documentation tends to lag behind the capabilities of the Samba suite, the Samba website at www.samba.org is a crucial primary source of information on Samba-related issues.