Using Extended Active Directory for Linux Authentication | Windows And Linux Integration Hands-on Solutions for a Mixed Environment

In the immediately preceding section, we enhanced our Active Directory sever by installing Microsoft Services for Unix (SFU). Or perhaps you downloaded the web-appendix and learned how to extend the schema using Windows 2003/R2.

Active Directory is now aware of Unix user IDs and group IDs and has provisions to store them for each user and group account. That means we can authenticate Linux clients directly against Active Directory without worrying about file ownership inconsistencies when files are moved from one Linux client to another, because Active Directory is the sole arbiter of user and group IDs. This is a great improvement over the Winbind-based approach we discussed earlier. For the full gist of this, see the sidebar earlier, titled "How Winbind Fakes Linux User IDs (and How It Can Hurt)."

But how does the Linux client obtain the Unix user ID (UIDs) and group IDs (GIDs) from the Active Directory server? Since those fields are not part of the traditional Windows networking protocols, Linux's Winbind (which emulates those protocols) can't grab the goods. Handily for us, Active Directory responds to LDAP queries and, because we can use our Linux client to make LDAP queries to Active Directory, we can just ask for those UIDs and GIDs.

Setting the Stage for Active Directory/LDAP Requests and Authentication

In the last chapter, we authenticated a Linux LDAP client to a Linux LDAP server in the section "Authenticating Linux Clients to the OpenLDAP Server." When we did this, the OpenLDAP client components on lincli1.corp.com made contact with the OpenLDAP server components on linserv1.corp.com . In one fell swoop, we looked up our user account and authenticated directly to OpenLDAP. Nice.

Now our goal is to get the OpenLDAP client components on a brand new machine, adldaplincli1.ad.corp.com , and have it talk to the Active Directory on windc1.ad.corp.com , as shown in Figure 3.12.

Figure 3.12: How a Linux client authenticates to an Active Directory with extended Unix attributes

But "talking" to Active Directory isn't enough. There are two big steps the Linux client needs to perform:

Step 1 Find the user account in Active Directory and grab the UID and GIDs (and other information home directory paths) stored therein. We'll configure the client pieces of OpenLDAP on adldaplincli1.ad.corp.com to make contact to Active Directory to do this.
Step 2 Authenticate to Active Directory. We'll use a robust protocol that Active Directory uses to do the same task: Kerberos. This is a very strong protocol that protects all authentication traffic.

If we're really feeling frisky, we can go the extra mile and encrypt the LDAP traffic whenever we ask Active Directory to find our user accounts (in that first step).

Note

Step 1 is the easy part. It'll be similar to what we did in Chapter 2's "Authenticating Linux Clients to the OpenLDAP Server." Step 2 is the new part. We'll simply configure our Linux client to authenticate directly to Active Directory's Kerberos server components. The optional "extra mile" of encrypting the initial LDAP traffic is the hard part. You'll see why a bit later.

About Kerberos Authentication

Kerberos is a standard for authenticating and authorizing users. Built into Microsoft's Active Directory at a fundamental level, Kerberos is also used by Linux and other operating systems.

Kerberos is highly secure and also has other advantages beyond simple login authentication. One of the most interesting is that Kerberos makes it much easier to implement "single sign-on," allowing a user access to many services after they log on without the need to present a password over and over again.

Unfortunately, most popular Linux applications are not yet "kerberized," so we won't benefit much from the single sign-on feature in this book. For the purposes of this chapter, the most important feature of Kerberos is its ability to authenticate logons in a highly secure fashion, but it's worth bearing in mind that additional benefits will appear as more and more applications such as web browsers and file sharing clients are " kerberized ."

Kerberos is a complex beast , and multiple books have been written about the protocol. For our purposes, here are the three fundamental crib notes:

First, a Kerberos server is properly known as a "KDC" (Key Distribution Center). The term "KDC" appears in the Fedora authentication configuration dialogs, so we'll try to be consistent and use that term .
Second, a KDC plays host to a Kerberos "realm," which has a name of its own. A single Kerberos server could, in theory, be the "go to" server and host many different collections of security principals without name conflicts (as long as they all belonged to different realms.) In practice, however, an Active Directory domain's Kerberos realm name always matches the Active Directory domain name, but IN ALL CAPS. And that's important. Entering the Kerberos realm name in lowercase (as it typically appears in Windows) will simply not work.
Third, a Kerberos "admin server" is a KDC that has the power to change passwords on a user's behalf . It is possible to create distributed "master" and "slave" KDCs, and in that situation we might specify a separate "admin server." But for our purposes in this book, the admin server is the same as the KDC.

Warning

If you have not extended the Active Directory schema with Microsoft Services for Unix (SFU) 3.5, or Windows 2003/R2, you'll need to do that now as described earlier.

To pull this off, we'll refine our two "big steps" into five ministeps:

We'll add a user account to the Active Directory server purely for LDAP browsing purposes. The issue here is that Active Directory always requires us to authenticate at the LDAP level as a user before we can make any directory queries, so we'll create a special account for that purpose.
We'll set up our Fedora Linux workstation to use LDAP "user information" directory services. The Fedora GUI does about 90 percent of the work.
We'll set up the workstation to use Kerberos authentication and specify the name of the Kerberos KDC (Key Distribution Center). The Fedora GUI takes care of this step for us very neatly.
We'll reconfigure /etc/ldap.conf , allowing Linux to interoperate correctly with Active Directory. There are a few extra settings needed to account for differences between Active Directory and other LDAP user account directories. (See Chapter 2 for an introduction to /etc/ldap.conf .)
We'll make sure that home directories can be created as needed.

Then we'll be ready to log in to Active Directory using LDAP and Kerberos! Hold on to your seats! (And people think we lead boring lives.)

Setting Up a User Who can "Touch" Active Directory

In order for Linux clients to search Active Directory via LDAP for user accounts to utilize, you have to make a choice. You could "dumb down" Active Directory and allow "anonymous" LDAP traffic. You have to change the way the Active Directory reacts to queries. This is called the "heuristics" of the directory service. KB article 326690 describes how to modify the Active Directory heuristics to allow anonymous queries."

A better solution is to just tell our Linux clients about a regular user account for which we provide a password in the LDAP configuration file. Insecure? Maybe a little bit, but this user account won't really be able to do anything. The account will have no privileges other than be able to make LDAP queries. This special account will authenticate using LDAP "simple authentication."

Here's the bad news: simple authentication sends the user's password in cleartext. Because of this, at the end of this chapter, we'll go the extra mile and encrypt the LDAP traffic. So let's go ahead and create this special account that will enable LDAP lookups.

In this example, we'll create an Active Directory user account called dirsearch :

Select Start Programs Administrative Tools Active Directory Users and Computers.
Right-click the "Users" folder, and select New User.
Follow the wizard to create your first user. You can fill in any name you want in the "First name" and "Last name" and "Full name" fields. Just be sure to enter dirsearch in the "User logon name" field.
Be sure to enter the same password as usual: p@ssw0rd .
Once the user is created, double-click the account and select the "Account" tab. Check "User cannot change password" and "Password never expires ."

Configuring the LDAP Client with the Fedora Authentication Tool

Rather than use one of the Linux clients that we configured previously, before proceeding, we'll create a brand-spankin' new Fedora Core 3 client so we're sure to avoid interactions with other authentication methods . The goal of this Linux client is to authenticate to Active Directory using LDAP. In our examples, we'll call this fresh machine adldaplincli1.ad.corp.com (think of that as " a ctive d irectory ldap lin ux cli ent # 1 ").

We need to tell our new Linux client to look up user information using LDAP and to perform authentication with Kerberos. We'll use the Authentication tool, accessed via the "System Settings" submenu of the "Applications" menu. This was covered at length in Chapter 2.

Configuring LDAP User Information

To configure the Fedora Core 3 Authentication tool to perform lookups using LDAP:

On your Linux client machine, from the Applications menu select System Settings Authentication. The "Authentication Configuration" dialog will appear.
You will default to the "User Information" tab. Check the "Enable LDAP Support" box.
Select the "Configure LDAP" button. The "LDAP Settings" dialog appears. Then, set the LDAP Search Base DN to dc=ad,dc=corp,dc=com and the LDAP server name to windc1.ad.corp.com . Do not check "Use TLS to encrypt connections" at this time. We'll reexamine that issue in the "Securing Active Directory LDAP Traffic" section. You can see these settings in Figure 3.13.
Click "OK" to return to the "Authentication Configuration" dialog. Now you're ready to configure Kerberos authentication.

Figure 3.13: Enter the name of the Active Directory distinguished name (dn) and the Active Directory server name.

Configuring Kerberos Authentication on the Client

Fedora makes setting up Kerberos authentication easy. Just follow these simple steps to configure Kerberos authentication with your Active Directory server. Again, we'll be performing these steps on the adldaplincli1.ad.corp.com client. To configure the Linux client for Kerberos authentication to Active Directory:

If you have not already done so, access the Fedora Authentication tool as described in the previous section.
Click the "Authentication" tab.
Check the "Enable Kerberos Support" box.
Click "Configure Kerberos"; you'll see the "Kerberos Settings" dialog.
In the "Realm" field, enter AD.CORP.COM in ALL CAPS (as shown in Figure 3.14).
In the "KDCs" field, enter windc1.ad.corp.com .
In the "Admin Servers" field, enter windc1.ad.corp.com . Note that we'll leave the two check boxes for DNS entries unchecked. That's because we're specifying the entries instead of asking the system to try to find them.
Click "OK" to exit the "Kerberos Settings" dialog.
Click "OK" to exit the Authentication tool.

Figure 3.14: Enter the Active Directory name and the name of our Active Directory Domain Controller in the Kerberos Settings in the Authentication tool.

Achieving Compatibility with SFU-Enhanced Active Directory

If we were using an ordinary Linux-based LDAP server, we'd be nearly done at this point. However, there are a few important differences between Active Directory and the OpenLDAP server we built in the previous chapter.

First, we need to spell out the key differences in /etc/ldap.conf settings when communicating with an Active Directory server (versus an OpenLDAP server).

In this section, we'll introduce each /etc/ldap.conf option that provides compatibility with Active Directory's LDAP support. Here, we need to:

Tell Linux which Active Directory account to utilize for searching.
Tell Linux which fields to use in Active Directory.
Tell Linux where to dig up a user's account information.
Tell Linux where to start searching for users in Active Directory.
Tell Linux where to locate the "username" field in Active Directory.
Speed up Active Directory searches.

Then we'll present a complete /etc/ldap.conf file that uses these features to successfully obtain user information via an SFU-enhanced Active Directory server's LDAP interface.

Tip	Panic not if you're using the Windows 2003/R2 schema. Simply download the web appendix for how to achieve the same level of compatibility with a Windows 2003/R2 schema.

Tell Linux Which Active Directory Account to Utilize for Searching

By default, Active Directory does not allow "anonymous bind" via LDAP. That means that clients must log into the LDAP interface of Active Directory with a valid username and password; that's why we created our dirsearch user in the Active Directory. Our goal is to present that dirsearch user's LDAP "distinguished name" when needed so we can touch Active Directory.

The two lines we'll need to add to the /etc/ldap.conf file are

 binddn cn=dirsearch,cn=Users,dc=ad,dc=corp,dc=com bindpw p@ssw0rd

You'll see these in the final /etc/ldap.conf file at the end of this section.

Tell Linux Which Fields to Use in Active Directory

As previously described, there are dueling standards for extending Active Directory's schema: the SFU 3.5 way and the Windows 2003/R2 (RFC 2307) way. (See the section titled "Possible ways to extend Active Directory".)

Since in this chapter, we're demonstrating the schema extensions of SFU 3.5, we need to teach Fedora Core 3 how to leverage the SFU 3.5 schema attributes.

When Services for Unix extends the Active Directory schema, the new attributes are prefixed with msSFU30 . Yes, that's right. They're msSFU30 even though we're working with SFU 3.5. So, for instance, the Unix home directory field in an Active Directory extended with SFU 3.5 is known as msSFU30HomeDirectory.

Fortunately, nss_ldap supports a technique called schema remapping . This allows us to tell the Linux system that the homeDirectory field can be found in the msSFU30HomeDirectory field when talking to an Active Directory server. We accomplish this using the nss_map_attribute option in /etc/ldap.conf . Here are the key lines we'll add to /etc/ldap.conf . Again, you'll see the complete file at the end of this section.

 nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute gecos name nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_objectclass posixGroup Group nss_map_attribute uniqueMember member nss_map_attribute cn sAMAccountName

Tell Linux Where to Dig Up a User's Account Information

Active Directory also calls the account object, which contains all information about an account, by a different name. In a typical Unix LDAP directory, the account object would be called a posixAccount , and the "shadow password" information would be in a similar object called a shadowAccount ; Active Directory, however, has a single type or class of object, called a user , that serves both purposes.

We'll use the nss_map_objectclass option to tell Linux where the account information it expects can be found in Active Directory. Here are the key lines we'll add to /etc/ldap.conf . Again, you'll see the complete file at the end of this section.

 nss_map_objectclass posixAccount user nss_map_objectclass shadowAccount user

Tell Linux Where to Start Searching for Users in Active Directory

The nss_base_passwd , nss_base_shadow , and nss_base_group options are similar to the base option we've discussed previously.

They must be identical to or " beneath " the base. They indicate where in the LDAP hierarchy nss_ldap should start looking for user, shadow password, and group objects. Here are the key lines we'll add to /etc/ldap.conf :

 nss_base_passwd dc=ad,dc=corp,dc=com nss_base_shadow dc=ad,dc=corp,dc=com nss_base_group  dc=ad,dc=corp,dc=com

For instance, in our example, all three are set to dc=ad,dc=corp,dc=com . This allows all users in any part of the Active Directory LDAP database to log into this workstation.

You might want to set the base to a lower point in the LDAP hierarchy, such as a particular department's organizational unit. Although beyond the scope of this book, creatively restricting the nss_base_passwd, nss_base_shadow , and nss_base_group options and the base option can improve performance and help to enforce policy. Or you might want to restrict the search to just one portion of the LDAP tree, say, an OU (organizational unit) such as Sales. This could be an effective way to restrict the use of a workstation exclusively to salespeople.

Such restrictions can also improve performance by avoiding the need to exhaustively explore tens of thousands of accounts for each login attempt when the only people who should be using a particular workstation are salespeople. Such a restricted setting might look like: nss_base_passwd ou=Sales,dc=ad,dc=corp,dc=com

But in our case, we want to search the whole Active Directory domain.

Tell Linux Where to Locate the "Username" Field in Active Directory

The user logs on by entering a username. What field in the LDAP schema should be searched for a match with that username? The key line we'll add to /etc/ldap.conf is

 pam_login_attribute sAMAccountName

We use the pam_login_attribute option to set this to sAMAccountName , which is the Windows "username" field. This allows users to log into Linux workstations using the same username they would use on a Windows workstation.

Speed Up Active Directory Searches

We've covered the bare necessities, but there's one more option that will help keep us out of trouble. One additional line we'll want to add is

 pam_filter objectcategory=User

By setting pam_filter to objectcategory=User , we ensure that our LDAP search doesn't waste time or generate bogus results by trying to match usernames to objects that don't contain account information at all. While it may seem unlikely that such objects will have a sAMAccountName field, they certainly could , and we speed up our search by skipping them.

Tip

Note that there are many attributes with darn similar names . Specifically , be very careful and set pam_filter to objectcategory=User (and not to objectclass=User) . These are not the same. Specifically the User object class includes computer objects. Setting it to objectcategory=User specifically hones in just on user objects.

The Complete /etc/ldap.conf File for a Linux Client to Authenticate Using LDAP to Active Directory with SFU 3.5

In this chapter, the goal is to provide LDAP authentication against an SFU-enhanced Active Directory server (in our case, windc1.ad.corp.com ). Our Active Directory domain name is ad.corp.com , and to search Active Directory via LDAP we're leveraging a basic user account named dirsearch (with the password p@ssw0rd ). Each of these options is explained in the preceding section.

Listing 3.1 shows the full /etc/ldap.conf file. We'll have this file available for download on www.WinLinAnswers.com .

Listing 3.1: /etc/ldap.conf for LDAP Authentication against Active Directory

 # Here, we'll use unencryupted LDAP port 389. ("ldap") uri ldap://windc1.ad.corp.com base dc=ad,dc=corp,dc=com binddn cn=dirsearch,cn=Users,dc=ad,dc=corp,dc=com bindpw p@ssw0rd nss_base_passwd dc=ad,dc=corp,dc=com nss_base_shadow dc=ad,dc=corp,dc=com nss_base_group  dc=ad,dc=corp,dc=com nss_map_objectclass posixAccount user nss_map_objectclass shadowAccount user nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute gecos name nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_objectclass posixGroup Group nss_map_attribute uniqueMember member nss_map_attribute cn sAMAccountName pam_login_attribute sAMAccountName pam_filter objectcategory=User

Tip	For additional information about /etc/ldap.conf , see Chapter 2.

Making Home Directories on the Fly

We've configured the Linux workstation to use LDAP and added the crucial options to achieve compatibility with SFU-enhanced Active Directory. There's only one step to go.

When a new user logs into a particular workstation for the first time, that user doesn't have a local home directory yet. As you saw in Chapter 2, a user can log in via three methods:

The shell
Encrypted shell (via ssh)
The GNOME interface

We address this by adding the pam_mkhomedir.so module to the sshd, gdm , and login files in /etc/pam.d . See Chapter 2 (in the "Authenticating Linux Clients to the NIS Server" section) for a detailed discussion of this step.

Briefly, the procedure is:

As root, open the file /etc/pam.d/sshd with your text editor.

Add the following line to the end of the file:

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

Repeat steps 1 and 2 for /etc/pam.d/gdm and /etc/pam.d/login .

Logging into Active Directory Using Linux via LDAP

We're there! Log out of your Fedora workstation and log in again as salesperson1 with the password p@ssw0rd .

You should receive a message explaining that a home directory has been created for salesperson1 , and your desktop should then appear as normal.

Congratulations!

Your Linux workstation is now authenticating against an Active Directory server.

Thanks to Microsoft Services for Unix, the Active Directory server now provides centralized management of Linux user IDs and group IDs, as well as all other account informationand Windows workstations can log on with the very same accounts!

If it Doesn't Work

Here are some suggestions if it doesn't go quite as planned:

Be sure that Windows workstations can log into the Active Directory domain using the same credentials you are testing on your Windows workstation. It bears repeating: always, always rule out the obvious.
Make sure you installed Microsoft Services for Unix 3.5 on the Active Directory server as described in the section "Services for Unix 3.5 Components and Installation."
Did you create the dirsearch and salesperson1 accounts on the Active Directory server? If not, do so following our instructions.
Double-check your / etc/ldap.conf file to make sure it matches our configuration.
As root, try the command su - salesperson1 . This opens a new shell running as salesperson1 rather than root. Root can switch to any other user at any time, so you will not be prompted for a password. You should receive an illuminating error message if this command fails. If it succeeds, you'll be returned to the prompt logged in as salesperson1 , so type exit to return to root's shell prompt. When this command succeeds but logon attempts still fail, it is likely that you are not logging in with the right password.
Add a new line to /etc/ldap.conf to help you debug: just add a single line ( anywhere ) that says debug 1 . Then try step 5 again. You should receive quite a bit of debugging output, which may shed some light on the problem. Be sure to remove that line afterward.
As recommended at the end of Chapter 2, use the command tail -20 /var/log/messages to check for error messages relevant to the logon process.
Always try Google searches for error messages you receive.

Checkout

To authenticate a Linux client via the LDAP interface of an Active Directory server:

We installed Microsoft Services for Unix.
We created a dirsearch account in the Active Directory for LDAP binding purposes. We also created a user account named salesperson1 for testing purposes.
We used the Fedora Core 3 GUI Authentication tool to enable LDAP authorization and authentication and specified the Active Directory server as the LDAP server.
We customized our /etc/ldap.conf file to enable compatibility with Active Directory's significantly different LDAP schema.
We added support for creating home directories on the fly using pam_mkhomedir.so .