Active Directory Solutions for Linux

By Jason Perlow

Date: Sep 16, 2005

Return to the article

Need your Windows and UNIX computer systems to talk together? Sure you do. Fortunately, as Jason Perlow explains, a number of solutions let you link Linux systems with Active Directory. His opinionated overview will save you time and trouble.

Historically, the path to Linux and Windows 2000 integration at the network level can be like the search for the holy grail: elusive, and wrought with difficulty and self-sacrifice. Rather than attempting to achieve this lofty goal in your average enterprise, more often than not, Linux systems are treated as a separate island onto themselves, with their own identity management systems, administrators, accounts, and applications.

But it doesn't have to be that way. There are now a number of solutions you can use to link Linux systems with Active Directory, all with their own advantages and disadvantages.

Samba winbind

winbind is a service that comes with the Open Source Samba client/server Windows networking/CIFS compatibility suite, which comes for free and is pre-installed with just about every Linux distribution. As of version 3.0.x of Samba, winbind not only supports Windows NT 3.x/4.x-style domains, but it also supports authentication to Active Directory.

While free, winbind is not perfect. Configuration requires fairly intensive tweaking of the /etc/smb.conf file and adjusting the /etc/nsswitch.conf to use winbind authentication. A special PAM (Pluggable Authentication Module), mkhomedir.so, also needs to be configured in /etc/pam.d/login and /etc/pam.d/gdm (on a Redhat system) to automatically create home directories for Active Directory users upon first log-on, and /etc/pam.d/system-auth needs to be changed so that the various authentication schemes used on your Linux system come up in the right order.

winbind is also not a particularly fast form of authentication, as it needs to cache the user list when it starts up. On a large Active Directory of thousands of users, this can take a while, every time a user wants to log in.

Another problem with winbind is that it does not do automatic UID/GID mapping for discrete Active Directory user accounts and groups. The "idmap" entries in the /etc/smb.conf file essentially hacks a UID and GID number range to correspond with equivalent AD user IDs and groups. There isn't a lot of granularity when using this method, however. The idmap functions can also be redirected to an LDAP server that is hosting the UNIX or Linux accounts, but this complicates matters significantly.

Alternatively, you can also manually configure winbind to map to existing Linux/UNIX accounts, but it has to be done for every single user you want to allow to log into the system.

Kerberos also needs to be configured to make winbind work, as Windows 2000/2003 uses it as its authentication mechanism. While the default Kerberos configuration may work on some systems, it's not going to work for every AD network; a bit of trial and error may be required. Kerberos is also very sensitive to time synchronization issues, so having a properly configured NTP server on your machine or your network is key to getting Kerberos with winbind to work correctly.

As with all Open Source projects, the GUI/console tools that you get with each distribution for automating the winbind configuration differ significantly, and they only go so far. More often than not, you will spend a lot of time tweaking the configuration files manually; there's no seamless integration with Microsoft Windows administration tools, per sé.

For more on configuring winbind, please refer to the following resources:

Microsoft SFU 3.5 and Vintela VAS

Microsoft Services for UNIX (SFU) 3.5 is a free suite of utilities and services for interoperating with UNIX systems. Among the things it contains are:

SFU achieves Active Directory integration with Linux and UNIX systems by not actually implementing native AD connectivity at all. Instead, Linux and UNIX clients communicate with the Windows network using their native NIS (yp) authentication stack already installed on every copy of Linux and UNIX, which communicates with a native NIS server service installed on every Active Directory Domain Controller on your network, which in turn runs a User Name Mapping Service that translates NIS logins to Active Directory logins. (Whew.) Each user account and group within Active Directory can be configured to correspond with a discrete UserID and GroupID on the Linux/UNIX side.

In theory, with a completely clean and uncomplicated Active Directory implementation and a fully cooperative IT staff, Microsoft Services for UNIX is a good solution. However, as we well know, not all ADs are clean, and not all IT departments are completely centralized or cooperative.

Perhaps one of the main issues why SFU is a difficult pill to swallow is that it requires Schema Extension. That means that the functions that SFU needs to perform the UserID/GroupID translation requires logical and physical modifications to the Active Directory database. The SFU installation adds new fields to the AD database to accommodate these new functions, and to store the extended user and group data on the Linux/UNIX side.

For many IT departments, schema extension is a deal-breaker – and it's even less desirable because there is no way to back out of the schema extension once it is done. Once the SFU schema extensions are added to your AD database, you have to live with them – permanently. In order to deal with this issue better (or rather, to force this down your throat) Microsoft is integrating the SFU schema extensions in the next major revision of Windows Server, 2003 R2.

What Vintela Does

A similar product to Microsoft SFU is Vintela Authentication Services (VAS), a spin-off of SCO which was recently acquired by Quest Software. Like SFU, Vintela uses NSS and NIS to "trick" Linux and UNIX systems into believing they are talking to a native network authentication scheme. However, unlike SFU, it doesn't require installing a NIS server or a User Name Mapping Service on your Windows servers. Most of the magic occurs at the VAS client-side level, which is supplied as a bunch of PAM modules and a service running on the client.

Unfortunately, to make this product work, it also requires schema extensions, which may or may not be palatable to your particular IT environment. However, once Vintela VAS is installed on your clients and the schema extensions are installed into your AD, it does work very well. Vintela also supplies Microsoft Management Console (MMC) modules for administrating your Linux and UNIX machines from Windows-based workstations.

Centrify DirectControl

Centrify DirectControl , a product from a two-year-old startup based in Mountain View, CA, offers perhaps the most compelling and comprehensive solution for Active Directory integration, at a price of about $50 per client and $300 per server, which is competitive with Vintela's licensing costs. Centrify also has the benefit on running on just about every UNIX version and Linux distribution, as well as on Mac OS X.

Like Vintela, Centrify works almost completely at the client level. However, there are some key differences. For starters, Centrify doesn't use a NIS/NSS bridge service to communicate with AD Domain Controllers; instead, they implemented their own modified version of the MIT Kerberos PAM stack to natively communicate with Windows 200x's Kerberos. And, in lieu of schema extensions, Centrify opted to store the UID and GUID mappings in an object class container within Active Directory. What's the difference? Well, just as the new OUs and User objects are normally stored within AD, Centrify uses non-proprietary text information stored in pre-existing object classes within AD to store extended Linux and UNIX user data. These objects can be easily removed from Active Directory, and their locations can be defined and moved by the network administrator.

Another unique benefit of Centrify is that — unlike the three other approaches listed above — the DirectControl client is tightly integrated with Windows 2000's password enforcement policy management. So, for example, if your user accounts are set to expire their passwords every 90 days, Centrify will put up a GUI or console-based dialog to prompt the user to change his password.

There are also no tricky synchronization issues or political infighting involved to bring Centrify into your shop. The process of installing Centrify on a Linux client and connecting to an Active Directory is totally painless: install one RPM, issue a single "net join" command, supply your administrator credentials, and presto, your Linux box is joined to the network just as is a Windows workstation. And guess what – if you've already brought SFU into your shop, Centrify supports the SFU extensions, so there is no downside to bringing the software into your environment after the fact.

To administrate the extended UNIX user data, Centrify provides a Windows-based GUI application that can be run from any Windows-based workstation. Absolutely nothing is installed on the server. Using the GUI, you can enforce granular Windows 2000 Group Policy controls, by department, geography, function, system type, or any means you wish. You can also grant administrators granular levels of privileges to fine tune their actual effective rights on the network.