LDAP Authentication

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.