9.3 Cross-Platform Authentication Services | LDAP System Administration

Cross-platform authentication is a term heard most often in IT departments that want to authenticate logons to Unix services using Microsoft's Active Directory,^[1] or authenticate logons to Windows clients using a Unix-based LDAP server. In this scenario, we're not interested in interoperability between directory services, but between a specific directory service and nonnative clients (for example, Active Directory and Unix clients).

^[1] Active Directory can be described as a network operating system (NOS) directory service that uses LDAPv3 as its primary access protocol and is, along with Kerberos 5, the major piece of Microsoft's larger domain infrastructure model. So while it is possible to use Active Directory as a vanilla LDAP directory service, I have never encountered a network that used Active Directory without a specific need for integration with other Microsoft technologies. More information about Active Directory can be found at http://www.microsoft.com/ad and in Windows 2000 Active Directory Services (O'Reilly).

Cross-platform authentication is the Holy Grail for many administrators, not just those dealing with Microsoft operating systems. Novell's eDirectory (formally called NDS) is available on a variety of platforms, including Windows, Linux, and Solaris. Novell provides tools such as a PAM module for NDS to integrate host authentication services with their directory. However, while Microsoft does provide some tools and sample source code for integrating Unix clients into an Active Directory domain (http://msdn.microsoft.com/library/en-us/dnactdir/html/kerberossamp.asp), there is currently no way to implement an Active Directory domain using non-Microsoft servers and technologies.

In all fairness, Microsoft's small offering of packages for Unix servers does not prevent Unix clients from using the user and group account information stored in an Active Directory domain. There are at least three methods for using Active Directory to authenticate Unix requests:

The NIS/Active Directory gateway included in Microsoft's "Services for UNIX" package allows Unix clients to access information stored in Active Directory. We discussed this product briefly in the previous section.
PADL's PAM and NSS LDAP libraries can act as a proxy server between the Unix services and Active Directory. The modules map attributes and object classes stored in Active Directory to something more suitable for consumption by Unix applications.
Active Directory domains use Kerberos 5 for authenticating users. Interoperability between the implementations of Kerberos on Windows and other platforms is better than you might expect, but perhaps not as good as you would hope.

The remainder of this section examines the PAM/NSS solution in depth. At the end of this section, we'll discuss how to use Kerberos to enhance interoperability between OpenLDAP and Active Directory. The examples use a single Active Directory domain with the name ad.plainjoe.org using the default options provided by the dcpromo installation process. The domain name implies that the domain naming context is dc=ad,dc=plainjoe,dc=org.

Chapter 6 covered how to install and configure the PADL libraries with an OpenLDAP server supporting the RFC 2307 (NIS) schema. Using these modules to access information held by an Active Directory server is almost the same. The pam_ldap library requires no additional compilation options for Active Directory support. The changes are solely to the module's configuration file.

The following excerpt from /etc/ldap.conf provides the module with the information it needs to contact the Active Directory server. For those unfamiliar with the Active Directory namespace, by default all users and groups are stored in the cn=Users container directly below the top-level entry in the domain. Therefore, if the default container is used, a one-level search beginning at cn=Users,dc=ad,dc=plainjoe,dc=org should be sufficient to locate any user or group in an Active Directory domain:

## /etc/ldap.conf for PADL pam_ldap and nss_ldap libraries ## ## Define the hostname of the Windows Domain Controller to contact. host              windc.ad.plainjoe.org         ## Active Directory does support LDAPv2, but make v3 the default. ldap_version      3         ## Users and groups are stored one level below this entry in the directory. base              cn=users,dc=ad,dc=plainjoe,dc=org scope             one

With a default installation, the PAM library searches the directory using the filter (&(objectclass=posixAccount)(uid=%s)), in which %s is expanded to the login name entered by the user. By default, Active Directory does not support the posixAccount object class or the uid attribute. To work around this, you need to develop a different search filter that can successfully locate users in an Active Directory domain.

User accounts in Active Directory are represented by the user object class; the login name is stored with the sAMAccountName attribute. Therefore, an appropriate filter for this application is (&(objectclass=user)(sAMAccountName=%s)), and you can apply this filter by setting the pam_filter and pam_login_attribute parameters as follows:

pam_filter           (objectclass=user) pam_login_attribute  sAMAccountName

Finally, you must tell pam_ldap how to change the user's password in Active Directory. The pam_ldap library provides support for changing passwords in a variety of directory servers, including the SunOne server, the password modify extended operation (RFC 3062), Novell's NDS, and Microsoft's Active Directory. The pam_password parameter decides which mechanism is selected. By specifying the ad password change mechanism, you allow users to update their Windows password using a PAM-aware application such as Linux's /usr/bin/passwd:

pam_password          ad

Be aware that this setting does not affect how the actual authentication is done; Chapter 6 describes the authentication process. To summarize, the PAM library performs these steps:

It requests an entry matching the search filter from the directory server.
It attempts to bind to the directory server using the DN of the returned entry and the clear text of the password.

SASL support in pam_ldap, both for searching and for user authentication, is planned for a future release.

Step 1 is a problem because by default Active Directory does not allow LDAP clients to make anonymous searches for user or group account information. There are several ways around this problem. One solution is to specify values for the binddn and bindpw parameters in /etc/ldap.conf. Because this file must be readable by all users on the system, the account credentials stored in the configuration file will be exposed to anyone who can log onto the host. You will have to be the judge of how this security concern will impact your network. A second solution is to allow anonymous searches of specific attributes within Active Directory. This has the same effect on pam_ldap as defining an account to use when searching the Active Directory domain, but now anyone can search for usernames using basic LDAP requests. I'll cover both methods for the sake of completeness, even though allowing anonymous access to Active Directory is often avoided by administrators.

To relax the access control lists on users and groups within Active Directory, launch the Active Directory Users and Computers administration tool. To view the properties of the Users container, right-click on the Users icon and select Properties . . . from the menu that appears (see Figure 9-1).

Figure 9-1. Modifying the ACL on the Users container to allow anonymous searches of user and group names

Next, move to the security tab of the resulting dialog box and select the Advanced button. You need to add three entries to the access control list, as shown in Figure 9-2:

The Everyone group requires the List Contents permission on the User container itself.
The Everyone group requires the ability to read certain properties of User objects. This permission should apply to the User container and all of its children.
The Everyone group requires the ability to read certain properties of Group objects. This permission should apply to the User container and all of its children.

Figure 9-2. Allowing the Everyone group access to read user attributes

To simplify this exercise, the Everyone group has been given the permission to read all properties for a user. This list can be shortened to the attributes that compose an entry in the passwd(5) file (the actual password is not needed). Again, you will have to judge whether this fits within the boundaries of your network security policies. Note that Read All Properties does not include the permission to read a user's password anonymously.

Enabling anonymous access frequently leaves a bad taste in the mouths of Active Directory admins. Because of this, you should choose to use an account named padl for searching the directory. This user account was created using normal means with the default set of security policies. Now, you must add the directives in ldap.conf for binding to the Active Directory server:

## Bind as the user padl in the ad.plainjoe.org domain binddn    cn=padl,cn=Users,dc=ad,dc=plainjoe,dc=org bindpw    padl-secret

Now that pam_ldap can locate the DN for an account using a search based on the sAMAccountName attribute, it is time to move on to the second problem: the PAM library currently sends the user (and binddn) credentials in clear text. The obvious solution to this problem is to use SSL to secure the information in transit.

Active Directory on a Windows 2000 server does not implement the StartTLS extended operation for negotiating a secure transport layer,^[2] but it does support the LDAPS protocol on port 636. There are two preconditions for implementing this solution:

^[2] The Windows 2003 Server release due in April 2003 reportedly supports the StartTLS extension.

The Windows Active Directory server must support 128-bit encryption. If you're using Windows 2000, you can obtain 128-bit encryption by installing the high-encryption version of the latest service pack. See http://www.microsoft.com/windows2000/downloads/servicepacks/ for details on obtaining and installing Windows 2000 updates.
The Active Directory server must have been issued a digital certificate. Our network will use the Certificate Authority (CA) included with the Windows 2000 Advanced Server OS. For more details on installing the Windows 2000 Certificate Authority, refer to the Windows 2000 Resource Kit online at http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp.

After installing the Windows Certificate Authority, reboot the server before attempting to connect using the LDAPS protocol.

After the directory server has been configured to support LDAPS, add the following lines to /etc/ldap.conf:

## Instruct pam_ldap and nss_ldap to use LDAPS when connecting to the directory. ssl       on port      636

By default, pam_ldap does not verify the LDAP server's certificate (see the tls_checkpeer parameter from Chapter 6). For our purposes, that's acceptable.

The OpenLDAP 2.1 client tools will fail if the server's certificate cannot be verified. This can result in some strange problems if you are using ldapsearch to issue queries to Active Directory. To work around this problem, place the following line in the OpenLDAP client library configuration file (/usr/local/etc/openldap/ldap.conf):

TLS_REQCERT never

At this point, the Unix client can potentially validate connection requests for a PAM-enabled service using Active Directory. However, as we saw in Chapter 6, PAM and NSS solutions are often implemented together. Next you must configure the nss_ldap module to retrieve Unix account information from Active Directory, in combination with using pam_ldap for authentication. The problem you need to deal with this time is that Active Directory does not normally maintain any attributes related to Unix accounts.

The exception to this rule is the NIS server included in Microsoft's SFU. To support NIS clients, the SFU installation process modifies the Active Directory schema to include attributes and object classes for storing information such as Unix user and group identifiers (numeric UIDs and GIDs), Unix-style home directory paths, and Unix login shells. So you can extend the Active Directory schema by installing the SFU package, and using the schema it provides even if you don't intend to use Microsoft's NIS server itself.

Another approach is to extend the Active Directory schema yourself. After all, it's really just another LDAPv3 server. The AD4Unix plugin developed by CSS Solutions (http://www.css-solutions.ca/ad4unix/) allows you to manage Unix-related attributes using the standard "Active Directory Users and Computers" Microsoft Management Console (MMC) interface. The MKSADExtPlugin extension is freely distributed in binary form as a Windows Installer (MSI) package. The installation process gives you the opportunity to import the SFU schema without installing SFU itself.

Modifying the schema of an Active Directory forest should not be taken lightly. Once you've extended the schema, you cannot remove any of the new classes or attributes. Make sure to back up the directory server before proceeding.

Active Directory designates one domain controller as the schema master; all schema changes must take place on this server. In order for the MKSADExtPlugin installer to import the schema changes, two conditions must be met:

The user attempting the schema update must be a member of the Schema Admins group.
The domain controller serving as the Schema Master must be configured to allow schema changes.

By default, a Windows 2000 Active Directory installation does not allow the schema to be modified; this limitation has been removed in Windows 2003. To change this setting, you must register and open the "Active Directory Schema" MMC snap-in. To register the snap-in with the operating system, execute the following command on the domain controller:

C:\WINNT\System32\> regsvr32.exe schmmgmt.dll

The Active Directory Schema snap-in should now appear in the list of available modules for the MMC. After opening the MMC application and adding the schema management tool, as shown in Figure 9-3, you can access the Change Schema Master dialog window by selecting the Operations Master . . . option from the right-click context menu on the Active Directory Schema icon. Check the box that determines whether the schema may be modified.

Figure 9-3. Using the "Active Directory Schema" MMC snap-in

Now that the directory server is configured to access the imported schema, the MKSADExtPlugin installation process can begin. You may see messages about components being successfully registered. These are normal and can be safely ignored.

When the Windows Installer has completed, you will see the configuration tool for MKSADExtPlugin's general settings under the Start menu. This application, shown in Figure 9-4, allows you to specify a range of numeric UIDs and GIDs that are automatically allocated to Active Directory users and groups as necessary. These IDs are allocated by the snap-in but can be set manually. The "Allowed NIS" field defines the syncNisDomain attribute for a user. This attribute is provided for the SFU NIS server and is not needed by either pam_ldap or nss_ldap. However, unless a user is placed in one of the listed NIS domains, the remaining Unix attributes will not be available, as shown in the user properties dialog in Figure 9-5.

Figure 9-4. The AD4Unix configuration application

Figure 9-5. Accessing the Unix Settings for a user account from the MMC snap-in

Back on the Unix side, the NSS library can handle the AD/SFU schema only if it is compiled with the enable-schema-mapping option. The enable-rfc2307bis option is frequently used in combination with schema mapping to define individual suffixes for the various NSS databases such as passwd and netgroup. The installation steps now become:

$ ./configure --enable-schema-mapping --enable-rfc2307bis $ make $ /bin/su -c "make install"

The /etc/nsswitch.conf file should include the settings used in the earlier discussion of nss_ldap (see Chapter 6):

## Portion of /etc/nsswitch.conf needed to support LDAP lookups in AD passwd:  files ldap shadow:  files ldap  group:   files ldap

Since pam_ldap and nss_ldap share a common configuration file, setting up the latter doesn't require much effort. The nss_ldap library must be instructed to map necessary attribute and object class names on the AD server to a member of the RFC 2307 schema commonly used to represent Unix service information. To do this, use the nss_map_attribute and nss_map_objectclass parameters:

## Excerpt from /etc/ldap.conf ## < . . . other parameters not shown . . . > ## Map AD attributes and objectclasses to ones expected by nss_ldap.   nss_map_objectclass     posixAccount    User nss_map_objectclass     shadowAccount   User nss_map_attribute       uid             sAMAccountName nss_map_attribute       uniqueMember    Member nss_map_attribute       homeDirectory   msSFUHomeDirectory nss_map_objectclass     posixGroup      Group nss_map_attribute       gecos           name

Certain attributes, such as the uidNumber and gidNumber, are not mentioned in the configuration file. If a mapping is not defined for an attribute or an object class, nss_ldap assumes that the attribute has the same name in the directory. If you browse the directory using the Active Directory Schema snap-in, you can verify that these two attributes are included in the SFU schema.

It is time to test the configuration. Start by configuring a user named kristi in Active Directory. Next, verify that this user has been assigned to an NIS domain and that the appropriate Unix attributes have been stored in the directory (refer to Figure 9-5 for an example). The client on which the PADL libraries have been installed should be able to map the Active Directory user kristi to a valid Linux user using the getent tool:

$ getent passwd kristi kristi:x:1002:1000:Kristi Carter:/home/garion/kristi:/bin/bash

To test the PAM portion of this setup on a Linux host, define the following auth section for the OpenSSH service in /etc/pam.d/sshd. The modules are stacked so that if a user can be validated by Active Directory, the authentication test returns succes:

## Portion of /etc/pam.d/sshd ## ## If a user can be authenticated using LDAP, that is enough. auth   required    /lib/security/pam_env.so auth   sufficient  /lib/security/pam_ldap.so auth   sufficient  /lib/security/pam_unix.so use_first_pass likeauth auth   required    /lib/security/pam_deny.so

The Active Directory user kristi should be able to log onto the Linux host (garion) using the Active Directory password associated with her account:

$ ssh kristi@garion kristi@garion's password: Last login: Sat Oct  5 20:29:14 2002 from ahab.plainjoe.org         [kristi@garion kristi]$ id uid=1002(kristi) gid=1000(Domain Users) groups=1000(Domain Users)

If anything fails at this point, here are some items to check:

Ensure that both the users and group containers can be searched using the account specified by the binddn in /etc/ldap.conf, or that the containers allow for anonymous searches
If the LDAPS protocol is suspect, verify that everything works as expected with ssl no in /etc/ldap.conf. If this works, verify that the Active Directory server has a valid certificate. When all else fails, use a network-monitoring tool such as Ethereal, or run OpenLDAP's ldapsearch with a debug value of -1 to isolate the point of failure in the SSL negotiation.
Verify that the gidNumber on the Unix Settings tab of the account properties can be resolved to a real group in Active Directory.
Follow the PAM and NSS troubleshooting tips provided in Chapter 6.

9.3.1 A Short Discussion About Kerberos

No discussion of Active Directory authentication or interoperability would be complete without at least some mention of Microsoft's Kerberos 5 implementation, and how well it plays with other Kerberos distributions, such as the one from MIT. Microsoft has provided a white paper at http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp on the varying levels of trust that can be achieved between Active Directory and MIT Kerberos realms. If Kerberos is new to you, the following web sites provide general information on its protocol and how it works:

The MIT Kerberos Project, http://web.mit.edu/kerberos/www/
Windows 2000 Kerberos Authentication, http://www.microsoft.com/TechNet/prodtechnol/windows2000serv/deploy/kerberos.asp

Why is Kerberos mentioned in a chapter on directory interoperability? Because one of the first, and sometime the most difficult, hurdles in directory interoperability is being able to access information without having to remember which username and password goes with which service. While this isn't an interoperability problem in the strict sense, practically speaking, your directory isn't worth much if it makes things harder for you and your users. When Active Directory is part of the equation, there are two scenarios for using Kerberos authentication:

Have the non-Microsoft clients use a Windows Kerberos authentication service (AS) for authentication.
Establish a trust relationship between the Active Directory domain and a non-Microsoft Kerberos realm.

To implement the first solution, you can use PAM modules that support Kerberos tickets, or you can have the Unix service function as a service principal in the Active Directory domain. The second solution is feasible only if an existing Kerberos realm is in place.

I won't describe how to implement either of these solutions in detail because many of Microsoft's applications have not been kerberized. For example, it would be convenient to search an OpenLDAP server from Microsoft Outlook running on a member of an Active Directory domain without having to define an OpenLDAP-specific login name/password combination. However, there's no configuration that allows current versions of Outlook to use the GSSAPI SASL mechanism to authenticate when connecting to an OpenLDAP server.^[3] Perhaps things will be easier in the future. For now, Kerberos may or may not help in your directory interoperability needs. You will have to test and decide for yourself.

^[3] The Kerberos administrators have confirmed that they can't come up with a working configuration, either.