Active Directory: The Sin of Subdivision

Absolution of the sins of SAM

Windows NT 4.0 is not what I call an enterprise operating system. It's a good fit for small and midsized companies, but I don't recommend NT as the primary operating system for large-scale firms. The major obstacles to large firms' implementation of NT 4.0 are the deadly sins of its simple and not-very-scalable database, the Security Accounts Manager (SAM). Microsoft's marketing department has renamed SAM "NT 4.0 Directory Services," but the name doesn't change the reality: For large firms, SAM comes up short—no matter what you call it. However, NT 5.0's Active Directory (AD) will solve the sins of SAM.

Sins Past
Over the past few months, I have examined four of SAM's sins and AD's solutions. The first sin is SAM's fixed structure. The database provides a dozen or so fields and does not let users alter this structure. (For more about the problem, see Inside Out, "Active Directory," November 1997.) In contrast, AD lets you add almost any information to the database.

The second sin is NT 4.0's reliance on a Primary Domain Controller (PDC). By adding Backup Domain Controllers (BDCs), Microsoft partially solved the problem of the PDC being a single point of failure. However, BDCs don't allow certain domain-wide operations, so they cannot fully replace a crashed PDC. AD makes all domain controllers equal, so that users connected to any domain controller can perform administrative functions, and NT's multimaster replication system will make sure that all the other domain controllers register the changes.

SAM's third deadly sin is that third-party applications must use difficult, nonstandard programming commands to access data in SAM. Third-party applications can query AD with the standard Lightweight Directory Access Protocol (LDAP).

SAM's fourth sin is the chatty, broadcast-oriented nature of the servers directory, Network Neighborhood. AD uses a radically different approach. Rather than discovering each server over and over, administrators publish server information in the AD.

Sin of Subdivision
SAM's fifth deadly sin is that subdividing control of a domain is difficult under NT 4.0. To see why this sin is a problem, consider the case of a fictitious company called Acme Technologies. Acme provides anti-pest technologies, primarily devices for eradicating the noxious pest Geococcyx californianus (see http://www.mbr.nbs.gov/id/mlist/h3850.html for details).

Acme has two main offices. The uptown office specializes in explosive devices, and the downtown group specializes in electronic and chemical devices such as the Guided Missile and Instant Hole. The offices' different approaches to control their feathered foe have created a cultural divide within Acme. The explosives guys scare the gadgets guys, as the explosives guys tend to blow things up at company parties. The explosives guys don't trust the gadgets guys either, as the explosives guys think the unreliable nature of the gadgets reflects poorly on the company's image.

When Acme implements an NT network, the company's 200 employees fit nicely into one domain. Problems arise, though, when the IS manager for the explosives group realizes that the person Acme designates as the domain-wide administrator will control not only the servers that the gadgets guys use, but the explosives folks' servers as well. How can Acme set up the domain so that the explosives team controls some servers and the gadgets group controls others?

In SAM, Acme can create global groups named Exadmins and Gadadmins and put explosives and gadgets administrators into the groups. Then these administrators can go to each server and NT workstation in the firm and manually replace the Domain Admins global group in each NT machine's Administrators group with either the Exadmins global group or the Gadadmins global group. But that's a lot of work.

AD will solve this problem by letting users divide up domains into Organizational Units (OUs). If Acme administrators use NT 5.0, they can divide their firm into OU=explosives and OU=gadgets. They can then depict their OUs in a tree-like structure, with Acme at the top and explosives and gadgets on the level below. In AD terminology, the explosives and gadgets OUs are containers; one thing they contain is user accounts. Instead of the one bin (SAM) in which NT 4.0 keeps all user accounts, NT 5.0 lets domains have two bins or more.

How does this structure help? Well, Acme must store both user accounts and machine accounts in one of the firm's two OUs. When you create a workstation or server in NT 5.0, you'll be able to put it anywhere in the tree of OUs. Different OUs will have different administrators. Thus, an administrator in the gadgets OU will be an administrator for machines in the gadgets OU by default.

Much of the work of setting up an NT 5.0 network will involve designing an efficient structure of OUs. Suppose Acme management wants not only to recognize the chasm between the two offices, but to differentiate between the managers and the engineers. Management must create four OUs: explosives managers, explosives engineers, gadgets managers, and gadgets engineers. How can they implement such a structure? They can create four top-level OUs. Or they can create top-level OUs named gadgets and explosives, then subdivide each into sub-OUs called managers and engineers. Or they can make managers and engineers the top-level OUs and subdivide them into explosives and gadgets. Which approach would serve them best? Nobody knows yet, because the current NT 5.0 code is far from the final product. But no matter how Acme designs its tree of OUs, the firm will still be able to match its NT security structure to its corporate culture, thanks to the greater flexibility of AD.

Sin of the Untrustworthy
SAM's sixth sin is its untrustworthy trust relationships. If you have three domains, A, B, and C, and set up A to trust B and B to trust C, then A does not trust C. In fact, B doesn't even trust A. If Microsoft sticks with the decision to incorporate Kerberos as the default authentication system for NT 5.0, the new NT will automatically solve the problem of transitive trusts. If you tell A that it trusts B, then B will also trust A automatically. If you then tell B that it trusts C, you will have automatically set up A to trust C, C to trust A, and C to trust B. (If you don't want B to trust A, you will have to set permissions to determine which users have permission in which OUs.) And I hope Kerberos will have less trouble with spontaneously dissolving trust relationships than NT 3.51 and 4.0 have had.

Sinful Size
The seventh and final deadly sin of SAM is its size and scalability. How many user accounts can you put in an NT domain? I have no idea. I have heard answers varying from 10,000 (the official answer back in the NT 3.1 days) to 76,000 (the number of accounts a Microsoft employee told me he'd stuffed onto a PDC).

Although Microsoft currently uses 40,000 as the Official Right Answer on the NT MCSE exams, I don't know of many people who have 40,000 user accounts on a real-world system. I ordinarily recommend that NT users not exceed 10,000 accounts on a domain. And even if the number 76,000 is plausible, it's just not enough. AD promises to solve this sin, too. Microsoft claims to have successfully loaded 10 million user accounts on an AD server.

All Sins Absolved
Since NT arrived in 1993, I've consulted with many companies looking to use NT and use it right. The seven sins of SAM have prevented me from recommending NT as a large firm's main operating system. With the introduction of NT 5.0, however, AD will correct SAM's deadly sins and I will be able, in good conscience, to tell big firms that NT is finally enterprise ready.