Lightweight Directory Access Protocol
The University of Michigan developers
designed Lightweight Directory Access Protocol (LDAP) in
1989 to free clients from the Directory Access Protocol
(DAP) for X.500 directory access.
They placed a single Lightweight
Directory Access Protocol server between the X.500 directory
and the accessing clients and had that server translate
directory requests between those LDAP clients and the X.500
directory over the TCP/IP network.
The LDAP server reduced the resource load from client side
to the LDAP server, because the LDAP server performed all of
the “language” conversion from the clients to the X.500
directory “language”.
Today LDAP is no longer just a protocol. It is a directory
service in itself and no longer needs to use any type of
X.500 directory access. These standalone LDAP servers could supply a complete LDAP directory running on a TCP/IP
network.
LDAP and Active Directory
One of the main ideas behind a single
user account’s database in Windows 2000 is having a single
repository of data. Anyone that has ever run Windows NT domains
and Exchange 5.x servers knows there are often cases
of more than one. There are many case studies on the
Internet showing how all of these different network
operating systems and mail systems keep their own user
databases and just how complicated they can be when they are
intertwined in an enterprise.
Think about this scenario; you are a
networking systems administrator running a mixed Windows NT
and Novell shop, which uses Exchange Server 5.5 as its
messaging system. You need to enter into the user database
Joe Shmoe, a new hire in Accounting. Because of this
particular environment, you will be creating no less than 3
accounts for this user.
The Windows NT
security accounts database, the Novell Directory Service and
the Exchange 5.5 Directory database will all want to know
who this new user is, and since all three keep their own
separate database of users, all three will need to be
properly populated with personal information such as
preferences, access levels and permissions, mail system
rules, logon directories and scripts, passwords for each
database, etc. These separate databases would be more useful
if they were “on the same page”.
Enter Active Directory.
Active Directory stores information
about network resources such as data, printers, servers,
users, groups, computers, etc. as database objects stored in
the directory and all services within a Windows 2000 Active
Directory environment will use that single database.
All of the Active Directory objects
have a distinct named set of attributes that represents
them, (e.g. printers might include the type and location of
the printer) held in the Active Directory. When you
need to enter a new user into the Active Directory database,
other network services, (e.g. mail services) will use
connectors or connection services to access the single
Active Directory database.
[NOTES FROM THE FIELD] – My
previous articles
Active Directory Logical Architecture and
Active Directory Domains, Organizational Units and the
Global Catalog both include an in-depth look at
the Logical and Physical structure of the Active Directory
database. Also
Leonard Loro,
who also writes articles for this section has detailed some
parallel information on LDAP and Active Directory in his
Directory Services, Microsoft Active Directory and LDAP in
One Piece article. Believe me when I tell you,
there is no way to learn too much about this subject.