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

by ServerWatch Staff

Jason Zandri's latest article in the Learn Active Directory Design and Administration in 15 Minutes a Week discusses the Lightweight Directory Access Protocol (LDAP) and how it's used within Windows 2000 and Active Directory.

by Jason Zandri

Welcome to the sixth installment of Learn Active Directory Design and Administration in 15 Minutes a Week, a weekly series aimed at current IT professionals preparing to write the new Windows Active Directory Design and Administration exams (70-219 and 70-217 respectively), as well as newcomers to the field who are trying to get a solid grasp on this new and emerging directory service from Microsoft. This installment is going to discuss the Lightweight Directory Access Protocol (LDAP), a tiny bit of its history and for the most part, how it is used within Windows 2000 and Active Directory.



The Lightweight Directory Access Protocol (LDAP) is an Internet standard protocol that was originally put into use at the University of Michigan. Developers wanted to free clients from the Directory Access Protocol (DAP) that was in use at the time for X.500 Directory Service access. This was often resource intensive on the client side and required the Open Systems Interconnection (OSI) protocol to be used.

The Open Systems Interconnection protocol was poised as the likely replacement for TCP/IP at one point in its history as many governments around the world as well as educational institutions made the OSI protocol the preferred protocol on their systems. Due mainly to incompatibility issues across different systems and the insurgence of the internet, TCP/IP overtook the OSI protocol as the preferred protocol and became the defacto standard due to its popularity and cross platform functionality.

X.500 Directory Service database is stored in a hierarchical design and uses the Directory System Agent (DSA) which provides fast searches and retrieval of data.

The Directory User Agent (DUA) can be implemented in different user interfaces via dedicated clients. E-mail applications that utilize this framework is just one example of this.

The Directory Access Protocol (DAP) is used in X.500 Directory Services for controlling communications between the Directory User Agent and
the Directory System Agent.

The X.500 Directory Services run as processes at the OSI application layer and are used to provide a universally unified naming service for all elements in a single network while providing the structure for unique names for all objects in the Directory. X.500 also serves as a translator between different networks.

[NOTES FROM THE FIELD] - Much of this historical information is not an Exam Requirement for either of the 70-217 or the 70-219 exams. Knowing the background information may help you, though, on questions relating to the Lightweight Directory Access Protocol (LDAP) and how it is used within Windows 2000 and Active Directory. LDAP and Active Directory are two big pieces of both exams.

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.


Active Directory is not an X.500 directory in and of itself, but it does follow the X.500 information model. It uses LDAP as the access protocol on TCP port 389 by default. The LDAP naming structure follows the X.500 naming design and looks similar to this:


[NOTES FROM THE FIELD] - Encrypted LDAP requires secure authentication and transport and uses TCP PORT 636 by default.

An LDAP URL names the server holding Active Directory services and the distinguished name of the object, which looks similar to this:


[NOTES FROM THE FIELD] - The relative distinguished name (RDN) of an object is the part of the name that is an attribute of the object itself. While the distinguished name of a printer object might be /DC=COM/DC=gunderville/OU=sales/OU=printers/CN=HP5SI, the relative distinguished name of the printer object is HP5SI. The only "problem" is the distinguished name of this printer object /DC=COM/DC=gunderville/OU=accounting/OU=printers/CN=HP5SI is also HP5SI, yet they are two separate objects and are allowed because they are in different locations in the Active Directory hierarchy. You can have duplicate relative distinguished names for Active Directory objects, but you cannot have two objects with the same relative distinguished name in the same Organizational Unit.

Active Directory integrates the Internet concept of a name space with the Windows 2000 directory services by using DNS for its name system and can exchange information with any application or directory that uses LDAP version 2 and version 3 or Hypertext Transfer Protocol (HTTP).

LDAP utilizes the Active Directory database servers to provide access to a Directory Information Tree (DIT) which is composed of data objects.

The class of all the objects in the DIT are identified by its Globally Unique Identifier (GUID).

[NOTES FROM THE FIELD] - The American National Standards Institute (ANSI) is in charge of assigning the "upper portions" of GUIDs to requesting organizations. For example, Microsoft Corporation has been assigned the 1.2.840.113556 branch and can assign GUIDs from 1.2.840.113556 downward by adding additional decimal place identifiers.

There are a few different naming formats that are supported in Active Directory, and I have outlined them in the table below.

RFC 822 RFC 822 is also called a User Principal Name and looks like any standard internet email address: Jason@Zandri.net
HTTP Uniform Resource Locator (URL) http://www.gunderville.com   http://www.zandri.net http://www.2000trainers.com http://www.swynk.com/friends/zandri/  http://www.swynk.com
Universal Naming Convention (UNC) Any path you might type in an explorer window or at a command line to get to a given location on a system: D:\DATA\Saved\Online\70-219\70-219-6
LDAP URLFollowing the RFC 1779 paper, Active Directory uses the LDAP URL naming convention of


LDAP names, used to identify Directory Information Tree objects, are based on the X.500 naming convention using the object class along with the actual name of the object.

The following table outlines the most common LDAP object classes.

Common LDAP object classes.

 Object Class





 Domain Component




 Organizational Unit


 Common Name

[NOTES FROM THE FIELD] - On the exams, don't confuse DC=Domain Component with Domain Controller. More so, do not confuse CN=Common Name with Container Name. I have never had a large amount of Novell exposure, but I've been told that many Novell Engineers are used to referring to CN as Container Name, and while not actually untrue, (they effectively mean the same thing) this will be INCORRECT on the Microsoft exam.

Using LDAP to Query Active Directory Objects

To search the Active Directory for objects you would open the Active Directory Users and Computers console and choose whichever domain or container in the console tree you wanted to search and click Find.

You can change the FIND field by dropping the selection window and choosing from the different selections given. Also, if you decided that you no longer wish to search the domain you have chosen but rather the entire directory, you can change that in the IN field.

The global catalog contains a partial replica of the entire Active Directory. The local global catalog server stores all of the information about every object in the local domain and a partial subset of information from all objects in every other domain in the tree and forest. Because the global catalog contains information about every object, a user can find information regardless of which domain in the tree or forest contains the data. Active Directory automatically generates the contents of the global catalog from the domains that make up the directory.

Below are some of the object types that can be found via the FIND method

Object Type


User account

Allows a user to log on to Windows 2000. This object will have other optional fields that can be filled in as well, usually dealing with the user. (e.g. phone number, email address, etc.)


This object will have information pertaining to the workplace or organizational, as well as other optional fields. (e.g. phone number, email address, etc.).


This object is a collection of user accounts, groups, or computers that you can create to simplify administration.

Shared folder

This object is a pointer (think alias or shortcut) to the shared folder on a computer. The actual shared folders and printers exist in the registry of a computer. When a shared folder is published in Active Directory, an object that contains a pointer to the shared object is created.


This object is a pointer (think alias or shortcut) to the shared printer on a computer. You must manually publish a printer on a computer that is not in Active Directory, such as Windows 95, 98 and NT. Microsoft Windows 2000 automatically adds printers that you create on domain computers to Active Directory.


The information about a computer that is a member of the domain.

Domain controllers

This object contains the information about the domain controllers, their Domain Name System (DNS) names, its legacy alias, the version of the operating system it is running, the location, and the name of the administrator who is responsible for managing the domain controller.

Organizational Unit (OU)

Contains other objects, including other OUs. Used to organize Active Directory objects.

Below are some of the fields and entry values for searching Active Directory.

Search Data

Description of Field


A list of object types for which you can search. A custom search builds the Lightweight Directory Access Protocol (LDAP) query or allows you to enter your own LDAP query based on parameters you enter.


Sets the focus of the search.


Allows you to look for a search path or parameter.


Allows you to define specific search criteria to locate objects. When you choose custom search, the Advanced tab allows you to type in the query or create a search using one of the common available attributes, organized by object type on the Custom Search tab. The Custom Search tab provides the same elements that are otherwise found on the Advanced tab.


Located in the Advanced tab, FIELD allows you to define specific search criteria to locate objects when you choose custom search.


Located in the Advanced tab, it allows you to further define the search criteria for an attribute.


Located in the Advanced tab, VALUE allows you to enter the value for the condition of the field (attribute) that you are using to search the Directory.

Search Criteria

Located in the Advanced tab, this box lists each search criteria that you have defined. To define a search criterion you use the Field list, Condition list, and Value box, then click Add. To remove search criteria, select the criteria, then click Remove. You can add or remove search criteria to broaden or narrow your search.


Using LDP.EXE to Perform Active Directory Searches

In the Windows 2000 Resource Kit there is the LDP.EXE utility, which is a GUI-based tool that can be used to perform LDAP searches. This also allows administrators to query data that might not otherwise be visible through the Administrative tools, such as objects stored in Active Directory along with their metadata, security descriptors and replication metadata. LDP.EXE is found in Support Tools kit under \support\tools.

In-depth information on this tool and its use can be found in the Microsoft Knowledgebase article - Using Ldp.exe to Find Data in the Active Directory (Q224543)


Well, that wraps up this section of Lightweight Directory Access Protocol (LDAP). I hope you found it informative and will return for the next installment of Learn Active Directory Design and Administration in 15 Minutes a Week.

If you have any questions, comments or even constructive criticism, please feel free to drop me a note.

I want to write good, solid technical articles that appeal to a large range of readers and skill levels and I can only be sure of that through your feedback.

Until then, best of luck in your studies.

Jason Zandri


This article was originally published on Thursday Jun 6th 2002
Mobile Site | Full Site