David HM Spector
And it was not happy.
So it set off in search
of its missing piece.
And as it rolled
it sang this song-
Oh I'm lookin' for my missin' piece
I'm lookin' for my missin' piece Hi-dee-ho, here I go,
Lookin' for my missin' piece
Linux is a lot like that semi-circle from Shel Silverstein's famous and endearing children's book: almost a complete circle, but not quite. With all of the incredible strides that Linux has made from the smallest embedded devices to the some of the largest supercomputers ever made, there is one piece of its complete adoption in the enterprise that's still missing--a not so little piece still to be done: integration and interoperability with Active Directory (AD).
As I type this opening paragraph I can almost hear the screams of indignation in the distance: Work with AD?! Why would anyone need to work with AD? Active Directory is not a standard! It's been embraced and extended! Who needs that? We've got LDAP and NIS and Kerberos and... Well, let's look at where we are in the grand scheme of things and see if we can disambiguate things a bit:
Linux has really reinvigorated the UNIX family of operating systems, as well as competition in the server market place. The hard work and talents of thousands of developers have made Linux an unstoppable force in the data center. They have also set the foundation for Linux (and other UNIXes) to provide credible and well-implemented alternatives to Microsoft Office on the desktop, but Microsoft still has absolutely no competition in the directory space. The directory space is the key to the desktop marketplace and the possibility of Linux's total integration in mainstream environments, because that's where all the really important metadata--the stuff that businesses run on--lives.
Enterprise Directory Services in 250 Words or Less
You're probably wondering what's the big deal about a directory. It's just LDAP, right? Sort of. It's hard to do justice in a couple of paragraphs to a topic about which no fewer than 200 books have been written, but here's a quick primer.
An enterprise directory is a repository of concrete and metadata objects which describe the relationships between all of the objects in a computational ecosystem. Examples of concrete data objects include usernames, passwords, computer names, printer names, IP addresses, home directories, and so on. In general, these are objects you can see, touch, or manipulate directly.
The other set of objects managed by a directory are almost all "metadata"--literally "data about data." Metadata objects don't have any meaning unto themselves. Some aggregate concrete objects. Others describe relationships: to a concrete object, to a concrete object's attributes, or to other metadata objects. Examples of directory metadata objects include groups of users or groups of computers, organizational units such as the marketing department, access control lists, password expiration times, computer configurations, software configurations, application license keys and end-users rights identifiers, print queue descriptions, campus locations, office/cubicle numbers, phone number data, and even relationships between enterprise applications that need to talk to each other.
A fully developed directory service contains enough information to allow an IT staff to manage totally an infrastructure from the infrastructure's configuration to the day-to-day operational data needed for simple tasks: from allowing users to print to the right printers to complex tasks like holding credentials and data transformation rules used by applications. It must also allow for the delegation of roles and responsibilities so that interns can't destroy enterprise databases or modify accounts but senior sysadmins aren't clearing paper jams from print queues either.
Directory Services under Linux/UNIX
I've drawn a pretty distinct line in the sand, and now I have to cross it. How does the scenario I've laid out relate to Linux/Unix and what's Microsoft's Active Directory got to do with all of this?
Directory services as we use them today are an outgrowth of an unlikely victory in a standards battle that took place in the mid-1980s. The academically generated IETF standards of networking (TCP/IP) and email (RFC822) battled the corporately funded International Standards Organization's (ISO) ISO Networking Stack and the X.400/X.500 email and email directory system. The details are fascinating, if not a bit tedious and out of place here. The IETF network standards were better designed in terms of implementations, but the ISO standards--especially those for email directories--were richer in terms of the data that could be stored and used effectively for email. The result was a middle of the road compromise that took the best of the ISO email directory and made it useful as a general-purpose attribute-based token storage system. The resulting protocol was the Lightweight Directory Access Protocol (LDAP).
LDAP allows the storage and retrieval of rooted trees of data where each tree represents some related and hierarchical relationship of information. How that data is stored is implementation dependent, but the syntax descriptions mechanisms for storing data and accessing data are the same regardless of the kinds of data stored. This is accomplished by the definitions of database schema that describe data to be stored in an implementation independent way. It was XML for organizational data before XML was invented.
In the UNIX world, LDAP has been typically used to store phonebook type information. In fact a quick look at Freshmeat.net and SourceForge shows that the majority of Open Source LDAP projects are about keeping phone directory info. Another common use for LDAP is for the storage of credentials for email systems (such as POP3 or IMAP) or for remote access solutions such as RADIUS.
A less common UNIX  use for LDAP, even though it's supported by every major Linux and UNIX vendor, is for storing user login information. Unfortunately, few people use LDAP to store esoteric information such as Kerberos keys or access control lists or to knit together all of this information into one cohesive data pool. That would decouple user, application, and rights information from the physicality of the hardware where it is stored.
Microsoft, for all of its embrace and extend philosophy, does know a good thing when it sees it. In LDAP it discovered a solution to a long standing problem since the release of Windows NT: How do you describe everything that can go on in an enterprise and manage that information without the resulting system being so fragile that it's broken by change?
With few exceptions, Active Directory is basically an LDAP engine in which Microsoft has defined every possible relationship between data and actions one can perform on a Microsoft-based platform. To make the whole thing secure from a authentication management perspective, they use Kerberos (albeit with a couple of very controversial and proprietary extensions) and Globally Unique Identifiers (GUIDs). From user-logins and groups to the storage and management of authentication tokens (Kerberos tickets and GUIDs); from the management of application information to the management of print queues, Active Directory manages it all. Administrators can replicate this information across large organizations and delegate bits of functionality and authority. This avoids the root privilege problem one typically sees under UNIX when someone needs to reconfigure a printer.
Where's the Disconnect and What Does it Mean??
Since LDAP, Kerberos, and most of the other tools that Microsoft has aggregated into Windows Active Directory were developed in the Unix world, it should be a no-brainer to integrate them under Linux/UNIX. What happened?
First, Microsoft is in a unique position. For good or ill, it controls all aspects of what goes into the operating system and how those pieces interoperate. It can lock out 3rd parties from adding or changing how those pieces work. The result is a very well-constrained set of administrative APIs and pools of data, even in a mixed 95/98, NT, Win2000 and WinXP environment.
In the Linux/UNIX world, as Perl programmers like to say, there's
more than one way to do it. Because UNIX-like systems are not a
monoculture in terms of base operating systems, services, and
facilities, there has never been a single set of unifying drivers that
can be applied universally to every network of UNIX machines. The X
Window developers once described the lack of a User Interface Standard
as a difference between believers in policies versus believers in
religions. In UNIX environments, there are at least 6 commonly used
methods for dealing with user accounts alone (vanilla
/etc/passwd, passwd+shadow, NIS, NIS+, RDB and LDAP)--all
policies to choose from, no hard and fast religion that says here's
how it should be done. Once you get into all of the management of
peripherals like printers, address books, and remote access, your
options get exponentially more complicated. Then there's
interoperability with a common administrative/management framework
that works and plays well with non-UNIX environments like Active
The end result? This is a problem; it's keeping Linux off of the corporate desktop because IT managers can't easily integrate Linux systems into their existing environments .
Also in Linux in the Enterprise:
Why Hasn't Anyone Solved this Under UNIX?
It's a very hard problem. LDAP may be useful and powerful, but deploying it piecemeal by hand is neither for the faint of heart nor the weak of stomach. LDAP schemas (the files that tell LDAP how to parse data for a given tree of information) are not easy to develop, let alone read or write. Since there are so many different mechanisms for everything from user-login to ACLs, there is no standard set of LDAP schemas for implementers to draw from . Add to this that LDAP's base configuration files are so user-unfriendly as to provoke need of deep, deep psychotherapy. In short, it's a bear to set up.
Despite being really powerful and really challenging to deploy at the same time, there are a couple partial solutions that can enable Linux/UNIX shops to take advantage of the power of an enterprise-like directory:
Sun's ONE Directory Server, formerly iPlanet, is an impressive offering. It's a full featured LDAP solution that does a lot of what Active Directory does. It has one huge failing: it is completely incompatible with AD. To be fair, Sun is trying to position this as an alternative. They provide all sorts of tools and libraries to allow Windows clients to be equal players in a Sun ONE directory environment, which is more than Microsoft does. (Then again Sun doesn't control over 95% of the worlds desktop computing market. Microsoft has few obvious economic incentives to be nice to competitors.)
Directory Administrator is a nice GUI front end to an OpenLDAP server that can be used to make a limited single-sign-on solution for a UNIX network. This makes using and administering LDAP quite a bit easier, but it works best if you already have a running LDAP implementation.
In the next part of this series we'll explore exactly what needs to be brought together to make Linux/UNIX equal players as both clients and servers in the enterprise directory-enabled space.
David HM Spector is President & CEO of Really Fast Systems, LLC, an infrastructure consulting and product development company based in New York
1. The one exception to this is Apple's implementation of Netinfo on top of LDAP, which we'll talk about in depth in Part II.
2. Purists will say Hey! PAM can talk to LDAP and therefore AD. Yeah, but try and change your password or use almost anything else served up by the directory.
3. There are several LDAP standards for UNIX login data and phone books. These too will be covered in Part II.
Read more Linux in the Enterprise columns.
Return to the Linux DevCenter.