LDAP System Administration

by Gerald Carter

  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.

  * * *

  Tip

  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:

  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.

  * * *

  Warning

  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.

  * * *

  Warning

  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.

  * * *

  Warning

  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:WINNTSystem32> 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