Executive Summary: Microsoft Windows Server 2003 R2’s Identity Management for UNIX feature and Microsoft Windows Server 2003’s Services for UNIX (SFU) 3.5 let you use Active Directory (AD) to integrate UNIX and Linux clients into a Windows operating system (OS) environment. Identity Management for UNIX and SFU let your AD domain controllers (DCs) act as Network Information Service (NIS) Master and Slave servers and let your UNIX and Linux clients act as NIS clients. However, Lightweight Directory Access Protocol (LDAP) offers a more secure alternative than NIS. Learn how to implement LDAP in a UNIX/Linux environment.

In “Integrating Windows with UNIX/Linux” and “Migrating NIS Domains”, I explain how to use Windows Server 2003 R2’s Identity Management for UNIX feature (or Windows 2003’s Services for UNIX—SFU—3.5) to easily integrate UNIX and Linux clients into a Windows environment, using Active Directory (AD) as the authentication store for user accounts. Identity Management for UNIX and SFU let your AD domain controllers (DCs) act as Network Information Service (NIS) Master and Slave servers and let your UNIX and Linux clients act as NIS clients. Depending on your configuration, users can use one set of credentials to log on to both Windows and UNIX/Linux clients.

Although NIS is easy to set up and configure, many administrators prefer not to use it because of past security problems or because NIS isn’t secure enough for their enterprise (especially if they use the UNIX crypt method instead of MD5 to protect passwords). UNIX vendors such as Sun Microsystems are moving away from NIS, instead favoring LDAP for authenticating users and accessing system-related data. Many security administrators believe LDAP is a more secure alternative than NIS. LDAP requires the use of a central directory on an LDAP server, which stores user and computer data. Most modern UNIX and Linux distributions support LDAP, AD can impersonate an LDAP directory, and each DC functions as an LDAP server. In this article I explain how to configure UNIX and Linux clients to use Windows 2003 R2-based AD as an LDAP authentication solution. Although you can use Windows 2003-based AD and SFU for LDAP integration, I don’t discuss this solution. Nor do I discuss using AD to store information about hosts, services, protocols, etc., for use by UNIX and Linux hosts. (For information about using Windows 2003 with SFU, try searching the Microsoft TechNet Web site at technet.microsoft.com/en-us/default.aspx.)

Getting Started
Before UNIX and Linux clients can use AD for authentication, you need to configure your Windows and AD environment. First, you must ensure that your UNIX and Linux clients have network connectivity to the AD DCs they’ll use as LDAP servers. I recommend that you use standard network diagnostic tools such as Ping and Nslookup. If you aren’t already doing so, use your Windows DNS servers as the DNS servers for your UNIX and Linux clients as well.

Next, you need to raise your AD domain functional level to Windows 2003. From a DC, run the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in (dsa.msc from the command line), right-click the name of your domain, and select Raise Domain Functional Level from the context-sensitive menu.

The next step is counterintuitive. If you haven’t already done so, you need to install the Identity Management for UNIX feature on at least one Windows 2003 R2 DC, and configure Server for NIS. Although you won’t be using NIS, installing this optional software extends your forest’s schema with necessary classes and attributes that support your UNIX and Linux-based users, as well as extends the Active Directory Users and Computers snap-in to manage them.

Then, install the necessary software, as I describe in “Integrating Windows with UNIX/Linux” (techxworld.com/community/blogs/features/archive/2007/05/02/integrating-windows-with-unix-linux.aspx), and configure NIS domains that represent your Windows domains. (You don’t need to follow the instructions to configure NIS on your UNIX and Linux clients.) Installing Identity Management for UNIX on every DC is unnecessary, but I recommend installation on several DCs, to ensure that the Active Directory Users and Computers extensions are available to domain administrators.

After configuring Server for NIS, you should use the MMC Services snap-in (services.msc from the command line) to disable this service on each DC on which you installed it. Right-click Server for NIS, select Properties, and select Disabled from the Startup Type drop-down list. If the service is running, click Stop. Click Apply, OK to close the dialog box. Disabling and stopping Server for NIS prevents a user from joining a UNIX system to the NIS domain that represents your Windows domain.

Next, follow the instructions in “Integrating Windows with UNIX/Linux” (techxworld.com/community/blogs/features/archive/2007/05/02/integrating-windows-with-unix-linux.aspx) to configure the groups and user accounts that will be used by UNIX and Linux users, placing each into an NIS domain; assigning them a user ID (UID), login shell, and home directory; and placing them into a primary group (group ID—GID). Because of the differences in how various versions of UNIX and Linux use an LDAP server for authentication, I recommend that you place all of your UNIX and Linux users into one AD organizational unit (OU) or container.

Finally, create a user account called a proxy account. This account needs no special permissions or privileges on the DCs; it will be used to perform directory searches and lookups. Configure the account so that the password never expires and can’t be changed.

LDAP Security
Before you can configure UNIX and Linux clients to use LDAP as an authentication method, you need to be aware of potential security problems and make the necessary changes to your Windows environment. When users are authenticated on UNIX and Linux clients, those clients attempt to connect to LDAP servers and authenticate using the credentials provided by the users. If authentication to the LDAP server is successful, the user is authenticated to the UNIX or Linux client and his or her user information (e.g., home directory, UID) is downloaded.

The first issue is that many LDAP servers permit a client to bind (the LDAP term for authenticate) as an anonymous user and provide access to the information stored in the LDAP directory. Windows 2003 disables anonymous binding except in limited circumstances. Although you can permit clients to bind anonymously, I advise against this practice. If users can bind anonymously, they can search the directory looking for information that can be used to launch attacks against systems and networks. Instead, you need to create a proxy account (as I discuss in the previous section) that’s used by UNIX and Linux clients to bind to your DCs, so they can search the directory for user account information.

The second issue is that when clients bind to an LDAP server they can, and often do, send credentials in clear text. Anyone with a packet sniffer can see credentials pass over the network. The solution is to use Secure Sockets Layer (SSL) to encrypt the network communications between UNIX and Linux clients and LDAP servers. Before you can use SSL for secure communications, each LDAP server must have an SSL certificate issued by a Certification Authority (CA) that’s trusted by both the client and server. Thus, you need a certificate for every DC that will be used by UNIX and Linux clients for authentication. You can purchase SSL certificates from a number of public CAs, or you can install and use Microsoft’s Certificate Services. I recommend the latter option.

Use Certificate Services to create an enterprise root CA. Installing Certificate Services is relatively easy because you don’t need to purchase additional software or certificates. In addition, features such as autoenrollment make deployment of certificates that can enable LDAP over SSL (LDAPS) automatic.

Client Configuration
Although some UNIX and Linux systems let you configure LDAP as an authentication method when you install them, I recommend that you use the following instructions to configure LDAP after system installation. The instructions I provide, which highlight three common UNIX and Linux variants (i.e., Solaris 10, FreeBSD 6.2, and openSUSE 10.2), also work for previously installed systems. Configuring LDAP on alternative UNIX/Linux versions is similar also.

Solaris systems. Although Solaris 10 supports the use of LDAP for user authentication in the OS out-of-the-box, configuration is somewhat involved. The first step is to create a certificate store that will be used by LDAP, and install the root certificate of the CA that issued the SSL certificate used to enable LDAPS on DCs that will function as LDAP servers. The following commands should be run by root to accomplish this step. You need a file containing the Base64-encoded certificate of the root CA.

/usr/sfw/bin/certutil -N -d /var/ldap chmod 444 /var/ldap/* /usr/sfw/bin/certutil -A -n “<Display name of root CA certificate>” -i </path/to/certificate> -t CT -d /var/ ldap

Next, run the following command to test LDAPS connectivity between your Solaris systems and each of your DCs:

ldapsearch -p 636 -h <FQDN> -P /var/ldap/ cert8.db -D cn=administrator,cn=users,dc=contoso, dc=com -w - -b dc=contoso,dc=com -v -s base ‘(objectclass=*)’

Replace FQDN with the Fully Qualified Domain Name (FQDN) of the DC. The command assumes that your administrator account is in the default location in AD (i.e., the Users container under your domain). Replace all instances of dc=contoso,dc=com with the appropriate information for your domain. For example, if your domain is corp .fabrikam.local, you would use dc=corp,dc= fabrikam,dc=local. If the command runs successfully, the output will show configuration data for the domain.

The next step is to configure Pluggable Authentication Modules (PAM) to use LDAP for authentication, account control, and other user management functions. The file you need to modify is /etc/pam.conf. Follow the directions in the EXAMPLES section of the pam_ldap(5) manual page to configure PAM to use LDAP for user authentication and account management. Web Listing 1 shows a sample pam.conf file for Solaris.

Next, run the command ldapclient as root to configure Solaris to use LDAP to authenticate users. The command takes a lot of arguments, so I recommend that you create an executable shell script (e.g., /tmp/initldap.sh) and populate it with the contents of Web Listing 2. You'll need to make some changes for your environment. Change defaultServerList on line 2 so that it contains the IP addresses of your DCs that Solaris will use as LDAP servers. You must use IP addresses because when the ldapclient command runs, it temporarily disables the DNS client and /etc/hosts file lookup. On line 3, change defaultSearchBase to point to the root of your domain. On line 4, change the remainder of the line after passwd: to point to the OU or container in your AD that contains your user objects representing UNIX and Linux user accounts. On line 5, change the remainder of the line after group: to point to the OU or container that contains your group objects representing groups on UNIX and Linux clients. On line 6, change domainName so that it's the name of your domain in AD. On line 8, change the remainder of the line after proxyDN= to point to the account you created earlier, which is used by UNIX and Linux clients when binding to DCs so that they can search AD. On line 9, change the password to the password of the proxy account. Then, run the shell script that you just created. If the script works, you'll see the system being configured and you'll receive the message System successfully configured. The proxy username and password specified in the shell script as arguments to the ldapclient command are written to files in the folder /var/ ldap. Only root needs access to this folder, so you should use chown and chmod to set ownership and permissions to the folder to restrict access and thus prevent users from accessing the files containing credentials.

The last step is to edit the file /etc/nsswitch .conf, to reflect your specific environment. When ldapclient runs, it overwrites this file, on the assumption that you'll use LDAP for all lookups, including hosts, services, and protocols. Test your setup by running exec login from the command line, or by logging in from the GUI logon screen.

FreeBSD systems. FreeBSD doesn't come with an LDAP client or the ability to use LDAP for user and group lookups - although the Ports collection includes the necessary software. Download, build, and install nss_ldap, which you can find in /usr/ports/net/nss_ldap, and pam_ldap, which you can find in /usr/ ports/security/pam_ldap. For more information about the Ports collection, go to the Free- BSD Project Web site (www.freebsd.org).

After you've installed the prerequisite software, you need to import the root CA certificate of the public key infrastructure (PKI) that issued the certificates for your DCs acting as LDAP servers. To do so, place a copy of the Base64-encoded root CA certificate into your OpenSSL certificates directory (e.g., /usr/local/ ssl/certs) and run the following command, replacing RootCAFile.cer with the name of the file containing the root CA certificate:

ln -s RootCAFile.cer 'openssl x509 -hash -noout -in RootCAFile.cer' .0

ldapsearch -D cn=administrator,cn=users,dc= contoso,dc=com -W -s base

Replace dc=contoso,dc=com with your domain information. You'll be prompted for the administrator password. If everything is configured correctly, you'll see information returned from a DC acting as an LDAP server.

Then, configure the LDAP configuration file used by PAM. This file is also named ldap .conf; you can find it in /usr/local/etc/ldap .conf. Make sure you don't confuse the two LDAP configuration files. Web Listing 4 contains a sample PAM ldap.conf file. Change line 1, replacing the base in the sample with your domain's base. Change line 2 so that one or more of your DCs is listed. Remember to prefix each with ldaps://. In line 3, change the sample account name listed for the proxy account you created to support UNIX and Linux clients; specify its password in line 4. In lines 5 and 6, specify the container or OU that your user accounts are stored under. In line 7, specify the container or OU that your groups are stored in. In line 11, specify the OpenSSL folder that your root CA's certificates are stored in. Only root needs read access to this file. Ordinary users shouldn't have access, because the file contains the credentials of the proxy account.

Next, configure PAM to use LDAP. Edit the file /etc/pam.d/system so that it includes the lines in Web Listing 5 in the appropriate sections of the file.

Then, edit the file /etc/nsswitch.conf so that the group and passwd entries look like Web Figure 1. Finally, configure the file nss_ ldap.conf, which you can find in /usr/local/ etc/ldap.conf. The LDAP configuration information in this file is used by the name service lookup provider functions when looking for users and groups using LDAP. In most cases this file is exactly the same as the ldap.conf file used by PAM, so you can use a symbolic link to point to the PAM ldap.conf file. Create the symbolic link by going to the command line and entering the following command:

cd /usr/local/etc ln -s ldap.conf nss_ldap.conf

You can test your configuration by using one of FreeBSD's virtual consoles (obtained by pressing Alt+F2 through F8) and trying to log on as a user configured for use by UNIX and Linux clients. If a configuration problem exists, errors will be logged to the console (press Alt+F1 to switch back to the console to check for errors), as well as to /var/log/messages.

openSUSE systems. openSUSE, like most modern versions of Linux, includes OpenSSL and LDAP client software by default. What's missing, however, is support for using LDAP to authenticate users. The openSUSE distribution CD-ROM contains the nss_ldap and pam_ldap packages, which are necessary for the solution to work. Install these packages before proceeding.

The first step in configuring an openSUSE system is to import the certificate of the root CA of the PKI that issued the SSL certificates to your DCs. Copy the Base64-format root CA certificate to /etc/ssl/certs, and run the following command:

ln -s RootCAFile.cer 'openssl x509 -hash -noout -in RootCAFile.cer '.0

Next, you need to edit the file /etc/open ldap/ldap.conf. This file has the same format as the ldap.conf file used by FreeBSD, which Web Listing 3 shows. Follow the previous instructions for FreeBSD when customizing this file. The only difference between FreeBSD and openSUSE is the location of the directory in which root certificates are stored. Update the configuration file so that TLS_CACERTDIR is configured as /etc/ssl/certs. Test the configuration by running the following command:

ldapsearch -D cn=administrator,cn=users,dc= contoso,dc=com -W -s base -x

The only difference between this command and the command used with FreeBSD is the addition of the -x flag, which directs ldapsearch to use simple authentication to the LDAP server(s) in the configuration file. This is necessary because OpenLDAP on openSUSE is built with Simple Authentication and Security Layer (SASL). The -x option instructs the LDAP client to use a simple bind, using the credentials specified by the user.

The next step is to edit the ldap.conf file used by PAM and used by the Name Service Switch (NSS). On openSUSE and similar Linux systems, the file is in the /etc directory. As with the OpenLDAP configuration file, the format is the same as that used by FreeBSD. Use the file in Web Listing 4 as the basis for your open- SUSE system, and follow the previous FreeBSD instructions to customize the file. Add the following line to the file:

sasl_secprops maxssf=0

As with FreeBSD, you need to update the file /etc/nsswitch.conf. Add ldap to the group, shadow, and passwd entries so they look like Web Figure 2.

Next, configure PAM to use LDAP. Doing so is simple on openSUSE; you don't even need to edit files. Simply run the following command:

pam-config -a --ldap

Finally, if you use the Name Service Cache Daemon (nscd) you need to stop and restart it for the changes to take effect. Run the following commands:

nscd -K nscd

You can test your setup by running the command exec login within a terminal window and attempting to log on as a user who is configured in AD with UNIX attributes using Identity Management for UNIX. If everything is configured correctly, you'll be able to log on as the user.

A New Standard
LDAP is quickly becoming the new standard for user authentication, edging out NIS. (For information about LDAP's limitations, see the Webexclusive sidebar 'LDAP Limitations,'( www.windowsitpro.com, InstantDoc ID 97292.) LDAP is more secure and is supported by most UNIX and Linux systems, as well as by many enterprise applications that run on these platforms. LDAP can also be used for more than simply authentication. An LDAP database can store information about hosts, protocols, services, and applications. Using LDAP will enable your enterprise to grow securely.

John Howie