Active Directory

Of all Windows NT 5.0's anticipated features, the most important is probably the Active Directory. It will change how NT handles user accounts, domains, trust relationships, browsing, and security, to name a few items. Basically, if you're currently an NT expert, Active Directory will change that status.

Active Directory is requiring Microsoft to throw away tens of thousands of lines of code and write perhaps a few hundred thousand or million in its place. What benefits does Microsoft hope to see from all that work? As I see it, Active Directory will fix several shortcomings­the Deadly Sins of NT. Over the next few months, I'll describe NT's deadly sins and explain how Active Directory corrects them.

Sin of SAM
The first deadly sin is NT's fixed user database structure. Currently, NT stores user information in the Security Accounts Manager (SAM), a file in \winnt\system32\config. (SAM has no extension such as .exe or .dll.) SAM is a database that stores a user's name, password, full name, description, the groups that the user is a member of, what hours the user can log on, what machines the user can log on from, where the user's profile lives, which logon batch script to run when the user logs on, what the user's home directory is, when the account expires, and what rights the user has. SAM also contains information about each machine that is a member of the domain and any trust relationships to other domains, but let's just consider the user information.

This database is an encrypted flat file with a fixed set of a dozen or so fields. But what if you want to add a field to each user's record so that you can fill in a contact phone number for each user. Or suppose you want to add a bitmap with a user's picture. Can you get SAM to do that?

Of course not. SAM has a fixed format. You can extend the User Manager for Domains with more information tabs, as Microsoft did with Exchange, but I know of no way to add fields to SAM. In contrast, you can modify the new Active Directory to include just about any information. And modifying the Active Directory structure doesn't require assembly language, C++, or the like. All examples that I've seen of modifying the Active Directory were written in Visual Basic (VB) or VBScript. These VB programs are not trivial, but they're not impenetrable either.

To write an Active Directory-modifying program, you invoke several function calls in the Active Directory Service Interfaces (ADSI). VB is the glue that holds a bunch of ADSI calls together, in much the same way that Microsoft uses VBScript to customize folders in Internet Explorer (IE) 4.0. The VB is not what's important; the system calls are. Finding documentation with clear examples for the IE 4.0 system calls has been very difficult. I hope finding information on ADSI calls is easier.

The Domain Controller Sin
The second deadly sin is how NT currently relies on Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs). An NT domain is a bunch of machines sharing a SAM. Rather than making you sit down at every NT server and every NT workstation and type in the name, password, description, and so on of every user of those machines, NT lets you nominate one machine, the PDC, to be the keeper of a central SAM. The other machines then treat information in that central machine's SAM as if it exists in their SAM.

Clearly, having all the network's user accounts on one machine is good, but the down-side is that this arrangement creates a single point of failure. Microsoft has lessened this potential problem with BDCs, NT servers that hold backup copies of the SAM. BDCs can perform logon services just as PDCs do, allowing load balancing in busy networks.

But BDCs are limited in what they can do to back up PDCs. If the PDC in a domain crashes, you might think that the BDCs would promote one of their own to PDC, but that doesn't happen. Imagine a company with a central office where the PDC lives and four distant branch offices, each with a BDC. The firm's WAN connects the central office and the PDC to the branches and BDCs. Suppose the WAN goes down. The BDC in each branch office now thinks that the PDC is down and cannot communicate with any BDCs. If BDCs automatically promoted themselves, you'd end up with five PDCs in this network. When you restored the WAN links, you'd have chaos.

Instead, the BDCs remain BDCs. They can still do logons, so each office can continue to operate without a problem. Logons don't require changing the SAM, just reading it. But suppose an administrator needs to change someone's password or group membership? When you start up the User Manager for Domains, you'll see a message to the effect that the PDC for this domain could not be found; you may not be able to do certain domain-wide operations such as changing a password or a group membership. If User Manager for Domains can't contact the PDC, you can't make any user changes. The only way a BDC becomes a PDC is if an administrator uses Server Manager to promote the machine to PDC. And if you want to change a machine from member server to domain controller, you must reinstall NT from scratch.

Active Directory will change that situation. You won't have PDCs or BDCs; you'll have only domain controllers. And designating a machine as a domain controller will be as simple as starting a service. When you start up a user administration tool--Microsoft will replace User Manager with a browser-driven tool called DSWeb or, optionally, a component in Microsoft Management Console (MMC)--your computer will locate the nearest domain controller and use the Active Directory information on that computer. DSWeb or MMC will save any changes you make to that nearby domain controller's Active Directory database.

The other domain controllers will find out about those changes through a system called multimaster replication. NT 5.0 domain controllers in an enterprise will know about each other, and they'll propagate any Active Directory changes so that all domain controllers are up to date. Even better, a notion called sites will let domain controllers know how expensive it is to communicate with one another. (Exchange and SMS users will recognize this concept.) The idea is that some domain controllers are on the same high-speed LAN, a network that's fast enough that they can chatter back and forth a fair amount without compromising the network. This group of domain controllers that share fast, relatively clear data pathways is a site. Within a site, Active Directory changes to one domain controller are replicated to its site-mates fairly quickly. Communicating with other sites, however, entails some cost if the transport path to the other site is slower or congested. An NT 5.0 administrator can adjust those costs to optimize site-to-site communication.

Suppose an administrator in St. Louis modifies Joe's password at 8 a.m., and an administrator in Hartford modifies Joe's password at 8 p.m. the same day. Due to slow WAN links, the Samoa office hears both updates to Joe's password at the same time. Which one should it keep: the original password, the St. Louis password, or the Hartford password? Each piece of data in the Active Directory has a serial number on it, sort of a time and date stamp. If St. Louis updates the password and Hartford changes the user's group memberships, you don't have a conflict. Joe's entire record is not replicated, just the fields that change.

And More Sin
Next month, I'll examine the next Deadly Sin, where NT makes it difficult for third-party applications to exploit the information in the user list. The answer to that sin lies in Active Directory's strategic use of the Lightweight Directory Access Protocol (LDAP) standard. (For more on LDAP and Active Directory, see Craig Zacker, "LDAP and the Future of Directory Services, Part 2," page 191.)