Unfinished Business : Closing the Circle

Courtesy: Nitin

The response to Part 1 was interesting. Many people agreed with me that this is very important area in which Linux/UNIX needs to make inroads before the quest for desktop domination can be considered complete. Several people took me to task for failing to give credit to Novell's NDS package which, to be fair, is the granddaddy of modern commercial enterprise directory services. As predicted, several people told me I was out of my mind and that Microsoft's Active Directory is a piece of <expletive deleted> and Linux didn't need that kind of software in order to be successful. Unfortunately, a couple of folks were downright hostile and threatening — I'll chalk that up to bad manners or failure to take medications as directed. :-) With all due respect to Novell, however, NDS is a fine product, and very popular; in fact, it was the first widely used enterprise directory and the only true competition Microsoft still has in its own space. But a majority of medium and large enterprises have switched over to Active Directory because it's not possible to run a large Windows shop without it. One of the benefits to Microsoft of its de-facto monopoly is that when they enter a product category by delivering a feature with its OSes, it becomes the dominant player in that space by default, just because of the sheer force of numbers. Everyone else gets effectively dis-intermediated instantly. Look what happened to Netscape. This lack of enterprise directory compatibility affects Linux in that it gives nervous IT managers and those who dislike the very idea of open source an excuse for not allowing Linux systems into their desktop environments. It also hinders the deployment of Linux servers into application environments where AD has been deployed as the enterprise authorization and authentication mechanism. Unfortunately, in this instance the IT managers would be right — an integrated enterprise directory service does give network managers a much greater ability to manage large-scale networks and resources from almost every perspective. Selective Breeding Versus Monoculture Unlike most UNIX systems, Windows environments are homogeneous. There are three modes of operation in terms of user and resource management in the Windows universe:    1. Stand-alone.    2. Domain membership through a domain controller.    3. Organizational-unit membership in an LDAP-based directory such as Active Directory (or via a third-party directory such as NDS, but those are declining as more organizations switch to AD). That's it. Because Microsoft provides all of the OS pieces, there is almost no variation on how Windows systems get their information about logins and other network resources. Windows is a monoculture. Now, let's look at UNIX side of the equation. Amazingly, the environments we have under Linux and UNIX are they way they are by design, albeit the accidental design of evolution. UNIX evolved in a world focused around research and hard-core computational environments. In many environments, UNIX-type systems have never needed to support more than a few dozen users on a single server or cluster or workstations — easily handled by even the most junior sysadmin. In larger environments, UNIX systems have often been the heavy lifting machines that handle process control, supercomputing, rendering, and payroll. Here too, the need for the kind of soup-to-nuts enterprise directory services that we see in the Windows world generally weren't needed until the boom of the late 1990s and the drive towards process integration that propelled the IT economy. Throughout the 1980s and into the early 1990s, where more centralized controls and facilities were needed, they were developed ad-hoc or by a single vendor and slowly percolated out into the wider environment. For example, Sun's YP/NIS and similar packages have served the UNIX world quite well in supporting basic network computing capabilities; they even made inroads into the Windows world (long before it Microsoft even included a TCP/IP stack in Windows or DOS). They ran under DOS and Win3.1 and allowed Windows machines to NFS mount UNIX file systems using third-party TCP/IP stacks from vendors such as FTP Software, Digital, and The Wollongong Group. With the tool-building history of UNIX systems, people (and UNIX vendors) built, and continue to build, tools to meet the needs of the moment. Those that address deeper and longer-term needs (like YP/NIS) tend to propagate; those that don't fade away or become niche utilities. The UNIX world is the result of natural evolution, not the outgrowth of a planned community. UNIX is a lot like New York City: dynamic, always reinventing itself, adapting to new needs and realities. Windows is a lot like Celebration, USA: static, a set piece of predictability, slow to provide new services and very resistant to change or difference of view or opinion. Active Directory Components Three major pieces of software make up the bulk of what Active Directory does:     * LDAP, the Lightweight Directory Access Protocol.     * Kerberos, the authorization system originally developed as part of MIT Athena (later, the basis for the security components in OSF's DME).     * A SQL database. These components interact with the Windows APIs to deliver a one-stop repository for any attribute that can be used to describe a system, a service, a device, users, groups, a relationship, a policy, an authorization, or another relationship in a computing environment. You're probably thinking, "Hey, these same components are available on almost every currently shipped Linux and UNIX platform! What's the big deal?" objects managed by ActiveDirectory Figure 1. Some of the objects managed by AD's LDAP schema As shown in Figure 1, LDAP in AD is used to manage:     * DNS addresses     * Workstation and server descriptions     * Printers     * Print queues     * Volume mappings     * Certificates     * Licenses     * Policies (such as ACLs, security policies, etc.)     * Groups     * Users     * Contacts All of these data are stored in one unified system, which can be broken down relatively easily (with some major caveats) by physical location (site), division, organization unit, or department and workgroup, and managed in a distributed fashion. These data can be replicated for redundancy and performance purposes. All Windows APIs must operate within this system if they are to participate in the network and have access to its resources. Repository data is wrapped up by and authenticated through the use of Kerberos Tickets, which makes the system (again, general Windows caveats applied) secure. The big win here is that the homogeneity of Windows allows this to work as an integrated system that can be set up and managed using one set of tools. Compare this to UNIX and Linux environments, where login and authentication information can come from:     * Local files (/etc/passwd, /etc/group) and their shadows     * NIS files (/var/yp)     * LDAP     * NIS encapsulated in LDAP     * Databases (PostgreSQL, MySQL, etc.)     * Third-party enterprise directories (though none are generally shipped with major Linux distributions) Authorization and access-control information can come from:     * File system permissions     * Kerberos (only for a very small range of objects unless you've done a lot of work)     * Third-party enterprise directories (though none are generally shipped with major Linux distributions)     * Homegrown authorization systems Access control lists are not yet generally/widely implemented, except on experimental platforms such as the NSA's SELinux or via homegrown ACL-like systems. User, group, and organizational policies are not yet implemented. Host information (IP addresses, resource records, etc.) can come from:     * Local files (/etc/hosts)     * BIND Systems management information can come from:     * DNS (Resource Records, SNMP HINFO data, etc.)     * External SNMP management systems And so on ... What's Missing? What's missing from this picture is, to hearken back to the XWindow team's observation, a religion. Linux and UNIX have several tools and processes that may be applied (policy) but almost none that must be applied (religion). In order to both play in and compete in the enterprise directory space, the Linux/UNIX community needs to come up with three things:     * A unified set of PAM modules that provide the glue so that workstations and servers can fully operate with Active Directory without the use of third-party products. Right now, most Linux distributions ship with the ability to get login information from an LDAP directory, but login data only accounts for a small part of AD's available metadata and resource and access controls. Adding more access modules that allow Linux to have more complete native access to AD will get it on more desktops and more servers in sites that are right now stuck with Windows systems.     * Changes to glibc and the kernel that enforce compartmentalized security and mandatory access controls. I believe that some of these features will be part of the 2.6 kernel, but a really complete implementation can, again, be seen in the NSA's SELinux.     * A unified set of metadata and services that map directly to those supported by Active Directory so that the open source community can develop and deploy a native enterprise directory service on the scale of Active Directory. In order to meet AD on its own turf (so that Linux can seamlessly integrate today) and do what AD does, but do it better and more cost-effectively, all of these services must be able to be driven by LDAP and secured through Kerberos. The most interesting part of this story is that 95% of the hard work has already been done! Microsoft didn't invent totally new LDAP schemas to make Active Directory as comprehensive as it is — as usual, they embraced and extended the work of others. LDAP schemas already exist, and are publicly available to cover:     * Contact management: The InetOrgPerson schema     * IP Addresses, Users, Server/Workstation Info: The NIS schema     * Kerberos tickets: IETF Kerberos KDC schema Of course, Microsoft's own schemas are available for perusal on any Active Directory server (or, if you happen to have a Macintosh OS X box, look in /etc/openldap, for all of Microsoft's schemas are there). Microsoft's schemas are interesting in that they allow us to determine where they have deviated from the published standards (notably in ACL information in Kerberos extensions, which was the point of some heated debate back in 1998-1999). Finally, we (the Linux community, in particular) tend to think that a lot of what we're doing is new, but the MIT Athena project had done a lot of this way back in the late '80s and early '90s. They did it across multiple versions of UNIX (AIX, Ultrix, SunOS, and several others). Where Do We Go From Here? There are two directions that Linux and UNIX must go in simultaneously in order to get up to speed in this important area of integration: At the Workstation Level Take the ACL code and other security hooks from the NSA's Security Enhanced Linux (SELinux) and use them as the platform into which PAM modules can be used to tie Linux into AD (and eventually a native Linux directory). SELinux enforces MACs (Mandatory Access Controls) in the system — some people will bridle at the thought of adding such potentially draconian security into what is a very friendly OS, but the addition of such security controls will only help the community write better software that only uses a privilege where it's needed, and not just because someone didn't take the time to code a correct solution. It will also help cut down on potential security breaches down the road. At the Enterprise Level First and foremost, Linux vendors need to ship fully configured LDAP and Kerberos servers with their distributions with full-fledged database back ends, not just a DBM-style library, as is currently the case. The single hardest part of either of these systems is the setup. Wizards need to be provided (the existing ones in most distributions are dreadfully inadequate) that make the configuration of parameters simple and activate available schemas without forcing the administrator to become either an expert in LDAP or Kerberos. Next, from the perspective of making a Linux enterprise directory AD compatible, is frankly to dissect Active Directory's schema and implement the proprietary bits under Linux. When Microsoft does such things they call it "embrace and extend" because they usually take an open standard and add some proprietary extension to make it non-portable and lock in their customers, as they did with their extensions to Kerberos. I would suggest we take a page from their playbook but call it "enhance and open." As long as this is not done with internal Microsoft documents that are subject to NDAs, this should not be a problem. (Hint: the information was reverse-engineered long ago and is readily available).

 

< Prev		Next >