Active Directory

Will it fix the deadly sins of NT?

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

Active Directory is requiring Microsoft to throw away tens of thousands oflines 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, ActiveDirectory will fix several shortcomings­the Deadly Sins of NT. Over thenext few months, I'll describe NT's deadly sins and explain how Active Directorycorrects them.

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

This database is an encrypted flat file with a fixed set of a dozen or sofields. But what if you want to add a field to each user's record so that youcan fill in a contact phone number for each user. Or suppose you want to add abitmap 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 forDomains with more information tabs, as Microsoft did with Exchange, but I knowof no way to add fields to SAM. In contrast, you can modify the new ActiveDirectory to include just about any information. And modifying the ActiveDirectory structure doesn't require assembly language, C++, or the like. Allexamples that I've seen of modifying the Active Directory were written in VisualBasic (VB) or VBScript. These VB programs are not trivial, but they're notimpenetrable either.

To write an Active Directory-modifying program, you invoke several functioncalls in the Active Directory Service Interfaces (ADSI). VB is the glue thatholds a bunch of ADSI calls together, in much the same way that Microsoft usesVBScript to customize folders in Internet Explorer (IE) 4.0. The VB is notwhat's important; the system calls are. Finding documentation with clearexamples for the IE 4.0 system calls has been very difficult. I hope findinginformation on ADSI calls is easier.

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

Clearly, having all the network's user accounts on one machine is good, butthe down-side is that this arrangement creates a single point of failure.Microsoft has lessened this potential problem with BDCs, NT servers that holdbackup 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 adomain crashes, you might think that the BDCs would promote one of their own toPDC, but that doesn't happen. Imagine a company with a central office where thePDC lives and four distant branch offices, each with a BDC. The firm's WANconnects the central office and the PDC to the branches and BDCs. Suppose theWAN goes down. The BDC in each branch office now thinks that the PDC is down andcannot 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 cancontinue to operate without a problem. Logons don't require changing the SAM,just reading it. But suppose an administrator needs to change someone's passwordor group membership? When you start up the User Manager for Domains, you'll seea message to the effect that the PDC for this domain could not be found; you maynot be able to do certain domain-wide operations such as changing a password ora group membership. If User Manager for Domains can't contact the PDC, you can'tmake any user changes. The only way a BDC becomes a PDC is if an administratoruses Server Manager to promote the machine to PDC. And if you want to change amachine from member server to domain controller, you must reinstall NT fromscratch.

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 domaincontroller will be as simple as starting a service. When you start up a useradministration tool--Microsoft will replace User Manager with a browser-driventool called DSWeb or, optionally, a component in Microsoft Management Console(MMC)--your computer will locate the nearest domain controller and use theActive Directory information on that computer. DSWeb or MMC will save anychanges you make to that nearby domain controller's Active Directory database.

The other domain controllers will find out about those changes through asystem called multimaster replication. NT 5.0 domain controllers in anenterprise will know about each other, and they'll propagate any ActiveDirectory changes so that all domain controllers are up to date. Even better, anotion called sites will let domain controllers know how expensive it is tocommunicate with one another. (Exchange and SMS users will recognize thisconcept.) The idea is that some domain controllers are on the same high-speedLAN, a network that's fast enough that they can chatter back and forth a fairamount without compromising the network. This group of domain controllers thatshare fast, relatively clear data pathways is a site. Within a site, ActiveDirectory changes to one domain controller are replicated to its site-matesfairly quickly. Communicating with other sites, however, entails some cost ifthe transport path to the other site is slower or congested. An NT 5.0administrator 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 atthe same time. Which one should it keep: the original password, the St. Louispassword, or the Hartford password? Each piece of data in the Active Directoryhas a serial number on it, sort of a time and date stamp. If St. Louis updatesthe password and Hartford changes the user's group memberships, you don't have aconflict. 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 difficultfor third-party applications to exploit the information in the user list. Theanswer to that sin lies in Active Directory's strategic use of the LightweightDirectory Access Protocol (LDAP) standard. (For more on LDAP and ActiveDirectory, see Craig Zacker, "LDAP and the Future of Directory Services, Part 2," page 191.)