| [ Team LiB ] |
|
9.3 Cross-Platform Authentication ServicesCross-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).
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 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:
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:
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:
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. 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.
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:
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:
9.3.1 A Short Discussion About KerberosNo 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:
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:
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.
|
| [ Team LiB ] |
|
