Active Directory and LDAP

Another Active Directory solution tothe sins of NT

Last month, I started talking about what Windows NT 5.0's Active Directory will do for NT; I suggested that the current system, the Security AccountsManager (SAM) database of users, committed deadly sins, two of which I discussedlast month. This month, I'd like to take up the concept of the LightweightDirectory Access Protocol (LDAP) and how it fits with Active Directory. (For adetailed description of LDAP, see Craig Zacker, "LDAP and the Future ofDirectory Services: Part 1," October 1997.)

The Sin of Access
The SAM database of users makes it difficult for outside vendors to use (oh,sorry, correct softwarespeak is "leverage") that database. With LDAP,a third party can write a secure server of some kind, and when a user wants toaccess data on that server, the server can query an NT 5.0 domain controller viaLDAP to find information about that user.

At one point in my firm, we ran an NT network, a Novell network, and acc:Mail mail system. To add a new employee, we had to create three new useraccounts: the account for NT that would go in SAM, the account for the Novellnetwork that would go into the bindery, and an account for cc:Mail thatwould go into a cc:Mail configuration file. Each of these accounts had apassword. None of these accounts talked to each other.

Every day, I'd have to prove to NT that I was Mark by punching in thepassword on the NT account. Then, I'd have to prove to Novell that I was Mark bypunching in the password on the Novell account. Then, when I wanted to check mymail, I'd have to prove to cc:Mail that I was Mark by punching in that password.

This situation was (and still is) extremely annoying. Now, many of youmight have multiple accounts but don't have to type passwords because someoperating systems remember your username and password for other systems, in muchthe same way that my Web browser remembers the usernames and passwords that Iuse for the Web sites that require paid subscriptions. I just type in theusername and password, and from that point on whenever I try to access the site,the browser supplies the username and password.

Back to my network: I want just one security authority to operate in myenterprise. My domain administrators create and maintain user accounts, and Idon't want them to have to maintain so many user accounts. Password changing dayis confusing for my users, who often get mixed up about how to change theirNovell passwords versus their NT passwords versus their cc:Mail passwords.

What do Novell, NT, and cc:Mail have in common? They all want to know thatyou are who you say you are, and you prove that with a password. Inother words, they want to authenticate you, and to that end, they keep adatabase of users. The NT, Novell, and cc:Mail folks all write code into theirproducts that keeps a database of users. Those databases of users don'thold just passwords, either. They contain important personal information such aspreferences, possibly access levels, rules (in the case of a mail system), andlogon directories and scripts. User databases are useful, but they'd be moreuseful if they were unified in some way.

Because user databases are not unified, we end up with three differentcompanies reinventing the wheel. Three different sets of database code alsomeans incompatibilities. Let's look at an example. Acme Industries has cc:Mail,and Apex Technologies uses the similar MSMail. Acme buys Apex. Now Acme has twomail systems that must talk to one another. One answer to this problem is, ofcourse, for Acme to tell Apex that a new sheriff is in town, and by the end ofthe month everyone will be using cc:Mail. Let's assume, however, that the Acmeadministrators decide that forcible conversion to cc:Mail isn't such a goodidea.

Now, MSMail and cc:Mail store messages in some format in files on shareddisk drives. Because both systems do basically the same thing, you can write aprogram that converts messages from cc:Mail format to MSMail format and viceversa. Such a program is called a mail gateway, and plenty of mail gateways areout there. The problem with building mail gateways, however, is that so manypossible combinations exist. For example, if you have 20 major email packages inthe world, you need 190 possible gateways.

About a decade ago, different mail systems stored messages in differentways, which was a big problem. To simplify the matter, the world settled on astandard format (X.400) for mail messages. This standard wasn't the mail formatfor any particular mail system, just an intermediate format that everyone agreedon. In theory, with X.400, you don't need to write gateways between cc:Mail andMSMail, PROFS, All-in-1, CEO, Simple Mail Transfer Protocol (SMTP), and so on.You write just one gateway from cc:Mail to X.400. Similarly, you get a gatewayfrom MSMail to X.400, and mail can go from Acme to Apex as cc:Mail to X.400 toMSMail. Terrific. We've solved the "How do I send mail from a cc:Mail userto an MSMail user in a format MSMail can understand" problem. But that'snot the whole mail interface problem because the user databases that MSMail andcc:Mail use present another point of incompatibility.

An Acme employee can fire up cc:Mail and create a new message, and cc:Mailwill present the user with a list of the users that cc:Mail knows. At the end ofthat list, a bogus user such as X400GTW will appear. cc:Mail is convenientlyshowing the Acme employee its user database, but no MSMail users appear on thelist. To send mail to an Apex user, the Acme employee must send mail to X400GTW.Then cc:Mail will prompt the employee for the name of the person on the otherside of the gateway that she wants to communicate with. Bummer. Now she has tocall the person she's mailing to and ask him his email name. The same kind ofthing happens to an Apex user trying to use MSMail to email a cc:Mail person.

The problem of connecting mail systems is, then, twofold. First, differentmail systems use different message formats; a standard intermediate formatcalled X.400 solves this part of the problem. Second, different mail systems usedifferent formats for querying their databases of recognized users. Again, thestandards folks came to the rescue with something called X.500, a standard foraccessing databases of users.

Is this situation starting to sound familiar? Many database vendors havevery different database engines, but most vendors have agreed on a set of verbsfor accessing a database: Structured Query Language (SQL). The beauty of SQL is(in theory) that a client accessing data on a database can be relativelyignorant of whether the data is stored in DB-2, Oracle, Informix, or SQL Server.(I say in theory because every vendor likes to enhance SQL, making for someincompatibilities.)

The Directory Server Solution
Now suppose the MSMail and cc:Mail programmers (and the Novell and NTprogrammers, for that matter) decide that they're tired of writing code to keeptrack of a database of users. Instead, they'll let anyone do it, so long asusers can query that database in some standard way. Just as you can have file,print, and Web servers provide services on the network, you can also have a "userdatabase server" (or directory server) keep the user database andrespond to queries from MSMail, cc:Mail, Novell, NT, and the like. Ultimately,that's what a domain controller will do under NT 5.0. In NT 5.0, third-partyclient-server products such as databases, mail systems, and groupware systemscould all "open hailing frequencies" to their nearby domain controllerto find out about a user.

But those programs still need an interface, a standard set of programmingcommands to query the directory. Writing a program to interrogate an NT 3.x or4.0 domain controller about what's in its SAM is possible, but the language andprotocol to do that job is a proprietary Microsoft one. SQL could be the answer,but it's awfully resource-heavy. Making every domain controller speak SQL wouldbe overkill, because SQL is designed to solve a wide range of data queryproblems in a relational model. In contrast, databases of users, directories,are simpler: They tend to be flat files, and they tend to be read morefrequently than they are written. As Microsoft's Steve Judd said, "You putthings into Active Directory that need to be visible in a lot of places but thatdon't change very often." The term for such a database is a directory. Youcan think of X.500 as SQL for directories.

Many people considered X.500 to be something of a cumbersome protocol, andthe Internet world came up with LDAP, an alternative method of accessing X.500directories. Running an LDAP client imposes less system overhead than X.500.Also, LDAP is an Internet protocol, and X.500 is a Consultative Committee forInternational Telegraphy and Telephony (CCITT) protocol. LDAP will definitelycorrect one of the sins of NT.

Before I go, let me add one more point. I've been referring to the ActiveDirectory as a database of users, but that's not all you'll find in the ActiveDirectory. Under NT 5.0, Active Directory will also contain information aboutthe machines on the network, shares available on the network, and availableapplications. Active Directory will be the central repository of networkconfiguration information.