Make UNIX and Linux Speak AD

Active Directory (AD) is prevalent in most enterprises today, so it makes a lot of sense to leverage it to support your UNIX and Linux systems (in this article, I use the term “UNIX” to mean any UNIX flavor or Linux). One obvious benefit of this approach is the ability to consolidate your user provisioning and access management to a single directory, rather than trying to individually provision users and access rights for independent Windows, UNIX, and Linux networks. This quickly translates into increased security and reduced cost.

Traditionally, UNIX has relied on the Network Information Service (NIS) as the means of providing a directory of accounts and group membership. In the past several years however, UNIX has made a very dedicated transition to LDAP as the central directory service. This is important because it means that much of the groundwork for integrating UNIX into AD has already been done for you—in this article, we just help you take the final steps.

Samba
The first and most common solution is to install and configure the free and open source Samba (http://www.samba.org) on each UNIX system to join AD. This can be done using the Winbind functionality in Samba, and is generally a painless process, especially if you are already familiar with UNIX. For environments with a large number of UNIX systems the process can be automated via scripting.

There are several benefits to using Samba, including:

Samba really is a very solid piece of software, and is quite widely used. Still, there are a few caveats, including the fact that it doesn’t support Group Policies, and you will need to find a vendor to support it if you don’t have the internal resources to do so yourself.

LDAP
Although not as common, you can configure UNIX to use AD sans Samba. This is done with the pam_ldap (http://www.padl.com/OSS/pam_ldap.html) package, which is a Pluggable Authentication Module (PAM) that is installed on your UNIX system. With pam_ldap, you configure the module to translate attributes found in AD (or any LDAP provider) to their UNIX equivalents. For example, in AD a user’s username is stored in the LDAP attribute sAMAccountName. In UNIX however, the username is known as the uid, so pam_ldap translates sAMAccountName attribute to uid. Pam_ldap also does other types of translation, such as translating AD groups to UNIX groups.

Using pam_ldap is a very lightweight method of integrating UNIX and AD. On the other hand, there is a security issue: Unless you create and install a SSL certificate on your AD DCs, communication between pam_ldap and AD is via plaintext LDAP. This is insecure because authentication credentials are then passed out in the open whenever a user logs into a UNIX system.

To be honest, Samba is normally used for AD integration rather than pam_ldap, but pam_ldap certainly is an option.

Microsoft Services for UNIX Applications
Microsoft’s Services for UNIX Applications (http://www.microsoft.com/windowsserver2003/r2/unixinterop/default.mspx), formerly known as Services for UNIX (SFU), provides an alternative way to provide AD support for UNIX. With Services for UNIX Applications (SUA), AD is configured to support UNIX, rather than UNIX for AD. Specifically, SUA modifies the AD schema to include UNIX attributes (e.g., uid). When an AD account is created, these attributes are automatically populated. You can either connect to AD via LDAP (e.g., pam_ldap) to use these attributes directly, or, more likely, use the NIS Server provided in SUA to support an existing UNIX legacy NIS network.

If you don’t need or want to support NIS, SUA gives you another option: The SUA Password Synchronization tool allows you to synchronize password changes between accounts in AD and UNIX systems. Rather than directly integrating UNIX into AD, this tool allows you to maintain separate account systems, but to still ensure that the passwords on all of your systems are the same. This is a poor man’s CSO, but it certainly works.

Commercial Options
And, finally, we come to commercial applications that ease the integration of UNIX and Windows. Three that immediately come to mind are Centeris (http://www.centeris.com/), Centrify (http://www.centrify.com/), and Vintela (http://www.quest.com/identity_management/). The concept behind these products is to reduce the burden of integrating UNIX and AD to a painless single point-and-click interface. The applications install and configure software that implements the needed Kerberos and LDAP connections for you. They also generally include other features, such as the ability to compartmentalize UNIX systems into groups so that only a given set of AD users can access a group of UNIX systems (think placement in an AD OU and Group Policies).

These products also provide a way to tightly integrate Kerberos into your UNIX applications. For example, you can integrate Apache access control with Kerberos, allowing for SSO support by Apache web applications.

In addition, Centrify gives you the ability to support Group Policies on UNIX. Obviously, some Group Policy settings don’t translate well to UNIX (e.g., specifying the desktop background), but others, such as password management and firewalls, are well suited. To boot, custom Group Policies can be implemented, meaning you can expand what you can centrally manage via AD.

Conclusion
In this article, we explored the ways in which AD can be used as an identity and management source for UNIX environments, and how this is easing the administration burden for IT departments. Keep in mind that you have several options for making this happen, so be sure to find the solution that works best for your environment.

For more information on interoperability, go to http://www.microsoft.com/interop.