Another Active Directory solution to
the 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 Accounts
Manager (SAM) database of users, committed deadly sins, two of which I discussed
last month. This month, I'd like to take up the concept of the Lightweight
Directory Access Protocol (LDAP) and how it fits with Active Directory. (For a
detailed description of LDAP, see Craig Zacker, "LDAP and the Future of
Directory 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 to
access data on that server, the server can query an NT 5.0 domain controller via
LDAP to find information about that user.
At one point in my firm, we ran an NT network, a Novell network, and a
cc:Mail mail system. To add a new employee, we had to create three new user
accounts: the account for NT that would go in SAM, the account for the Novell
network that would go into the bindery, and an account for cc:Mail that
would go into a cc:Mail configuration file. Each of these accounts had a
password. None of these accounts talked to each other.
Every day, I'd have to prove to NT that I was Mark by punching in the
password on the NT account. Then, I'd have to prove to Novell that I was Mark by
punching in the password on the Novell account. Then, when I wanted to check my
mail, 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 you
might have multiple accounts but don't have to type passwords because some
operating systems remember your username and password for other systems, in much
the same way that my Web browser remembers the usernames and passwords that I
use for the Web sites that require paid subscriptions. I just type in the
username 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 my
enterprise. My domain administrators create and maintain user accounts, and I
don't want them to have to maintain so many user accounts. Password changing day
is confusing for my users, who often get mixed up about how to change their
Novell 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 that
you are who you say you are, and you prove that with a password. In
other words, they want to authenticate you, and to that end, they keep a
database of users. The NT, Novell, and cc:Mail folks all write code into their
products that keeps a database of users. Those databases of users don't
hold just passwords, either. They contain important personal information such as
preferences, possibly access levels, rules (in the case of a mail system), and
logon directories and scripts. User databases are useful, but they'd be more
useful if they were unified in some way.
Because user databases are not unified, we end up with three different
companies reinventing the wheel. Three different sets of database code also
means 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 two
mail systems that must talk to one another. One answer to this problem is, of
course, for Acme to tell Apex that a new sheriff is in town, and by the end of
the month everyone will be using cc:Mail. Let's assume, however, that the Acme
administrators decide that forcible conversion to cc:Mail isn't such a good
idea.
Now, MSMail and cc:Mail store messages in some format in files on shared
disk drives. Because both systems do basically the same thing, you can write a
program that converts messages from cc:Mail format to MSMail format and vice
versa. Such a program is called a mail gateway, and plenty of mail gateways are
out there. The problem with building mail gateways, however, is that so many
possible combinations exist. For example, if you have 20 major email packages in
the world, you need 190 possible gateways.