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
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
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
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
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
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
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
the relative distinguished name of the printer object is
HP5SI. The only "problem" is the distinguished
name of this printer object
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
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
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) ||
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:
|LDAP URL||Following the RFC 1779
Directory uses the
LDAP URL naming convention
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
[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
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.
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.
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
Below are some of the fields and entry
values for searching Active Directory.
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
Located in the
Advanced tab, FIELD allows you to define specific search
criteria to locate objects when you choose custom
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.
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
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
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
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
This article was originally published on Thursday Jun 6th 2002