David HM Spector
In the first part of this discussion about Enterprise Directory Services and Linux, I made the assertion that Linux is currently not a competitive player in this space because of the lack of complete, integrated implementations of LDAP and other tools that Microsoft has been able to bring to bear in delivering an integrated directory service package.
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
- Domain membership through a domain controller.
- 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?"
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
- Print queues
- Volume mappings
- Policies (such as ACLs, security policies, etc.)
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.
Pages: 1, 2