Learn AD in 15 Minutes a Week: Lightweight Directory Access Protocol Page 2

Download the authoritative guide: Data Center Guide: Optimizing Your Data Center Strategy

Download the authoritative guide: Cloud Computing: Using the Cloud for Competitive Advantage

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.


This article was originally published on Jun 6, 2002
Page 2 of 4

Thanks for your registration, follow us on our social networks to keep up-to-date