Behind the Basics: The LDAP Protocol itself, plus Schema, Attributes, and
A section of An LDAP Roadmap & FAQ: A tutorial aid to navigating
various LDAP and X.500 resources on the Internet, v2.0a
by: Jeff Hodges
is v2.0a -- a "beta" release -- it is still way under construction. You
will find version 1.5, which may or may not be more up-to-date, HERE.
Apologies for any confusion.
Begin with this section if you understand the Basics
and are wondering about stuff such as the protocol itself, attributes,
their syntaxes, object classes, etc.
There are two versions of the LDAP protocol: LDAPv2 and LDAPv3.
I discuss both in turn below, beginning with LDAPv3. Following subsections
on both, there are subsections on schema, URLs, filters, etc. You can skip
reading about the protocol itself if just you want to learn about schema
elements and such and dive into laying out your directory. But to really
understand how this all works, looking over the protocol docs is useful.
The LDAP Protocol Itself:
Note: See this page for info about
the current official standing of the various LDAP RFCs.
Lightweight Directory Access Protocol (v3). M. Wahl, T. Howes,
S. Kille. December 1997.
This is the key, full-gory-detail, LDAPv3 document. It not
only defines the elements of the LDAPv3 protocol, it also outlines the
protocol and data models, introduces and outlines the concepts of schema
and security, and defines some operational objects implementations must
support. Though, this document doesn't fully define LDAPv3 on its own.
The current incarnation of LDAPv3 is defined by this plus five other documents:
RFCs 2252 through 2256. These documents are mentioned in turn below in
the context of applicable topics.
Refer to this page for an all-in-one-place
listing of the LDAPv3 documents and their maturity levels.
Refer to this page for what is on the LDAP plate
in various IETF working groups (i.e. what's happening for the future).
Lightweight Directory Access Protocol. W. Yeong, T. Howes
& S. Kille. March 1995.
This RFC officially specifies LDAPv2. It is the official
standards-document counterpart to the Lightweight
Directory Access Protocol: X.500 Lite paper (also referenced
in The Basics section). The IETF's Applications
Area Director stated back in ca.1996 that LDAPv2 will not progress to "full
standard" because of various perceived diffenciencies. Thus the IETF's
Access and Sychronization of Internet Directories working group (ASID,
now disbanded. See this page for info on current
LDAP-oriented IETF Working Groups) developed LDAPv3 (see above).
As noted for rfc2251, this specification also depends upon other documents
in order to completely specify the protocol. There are two other documents
in this case: RFCs 1778 and 1779. They are mentioned below in the context
of applicable topics.
Though not (yet) officially denoted, LDAPv3 effectively obsoletes
LDAPv2. The future official IETF standing of LDAPv2 is presently undecided,
but given IETF procedures & conventions (see section 4.2.4 of RFC2026)
, it is likely it will be moved to the Historic maturity level at some
point in the future.
Elements of Schema: Object Classes, Attributes,
and Distinguished Names
Here's a condensed way of explaining how all this LDAP information model
stuff (i.e. schema stuff) fits together..
The documents below specify and/or explain this in greater detail.
its Distinguished Name (DN) is the "fully qualified" version of
its name, while..
its Relative Distinguished Name (RDN) is the "unqualified" version
of its name.
Overall Background Specification Docs:
The COSINE and Internet X.500 Schema. P. Barker, S. Kille.
November 1991. (Format: TXT=92827 bytes) (Status: PROPOSED STANDARD)
RFC1274 is the granddaddy of X.500-based Internet directory schema.
It is referenced by RFC1778 in LDAPv2, but was somewhat superseeded by
RFC2256 in LDAPv3 (though this hasn't been officially denoted). Steve Kille
remarked to the editor (I'd asked whether RFC1274 should go to Historic)
on 19 Jun 1998..
"The problem is that there is quite a bit of stuff in 1274 [that is]
not in 2256. Some of it is junk, but other bits are useful. There
is a need to update 1274, remove junk, remove 2256 duplication, and progress
the rest [on down the standards track]."
This work item is not currently on any LDAP-related IETF
working group's to-do list (which means someone needs to stand up and
say fixing this really matters and someone needs to volunteer to do the
work). I'll bet that the LDAPEXT
working group is the place for it to be addressed.
LDAPv3 Schema Elements:
A Summary of the X.500(96) User Schema for use with LDAPv3.
M. Wahl. December 1997.
RFC2256 is also important because it is the document that officially
defines mapping from some of the defacto-standard "short" attribute names
to the ITU-standard ones.
Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions.
M. Wahl, A. Coulbeck, T. Howes, S. Kille. December 1997.
The short summary: RFC2252 is key. This document not only defines
the syntax set for LDAPv3, but also defines the set of attribute values
that LDAP servers should support.
LDAPv2 Schema Elements:
Distinguished Names (DNs):
DNs are functionally akin to primary
keys in RDBMSs
(relational database management systems). As introduced above, an object
in an LDAP/X.500-based directory has a DN. The DN is syntactically
analogous to a fully-qualified domain name in that the object also has
a "local" name, called its Relative Distinguished Name (RDN). The
below documents are properly part of the LDAPv3 and LDAPv2 protocols because
DNs in the form of strings are carried directly in protocol in LDAP. Additionally,
in LDAPv3's case, the LDAP URL document (RFC2255, see below) is officially
considered part of the LDAPv3 protocol core (see this
page for details) and thus RFC2253 is necessary because DN strings
are defined as part of LDAP URLs in RFC2255.
LDAPv3 Distinguished Names Representation
Lightweight Directory Access Protocol (v3): UTF-8 String Representation
of Distinguished Names. M. Wahl, S. Kille, T. Howes. December 1997.
LDAPv2 Distinguished Names Representation
A String Representation of Distinguished Names. S. Kille.
In addition to defining the DN string representation, RFC1779 defines
a small set of "short" attribute names, although it doesn't define the
full set as is commonly in present use within the LDAP community. Nominally,
RFC2256 (see above) defines these for the LDAPv3 protocol family.
LDAP URLs and Search Filters:
LDAPv2 did not officially specify a string representation for LDAP Search
Filters. Search Filters are encoded in LDAP PDUs
(see below) according to the ASN.1
syntax for them specified in RFC1777. BER-encoding an object gives you
a binary object that isn't particularly readable. Having a "string representation"
of things such as search filters is useful for APIs
and necessary for constructs like URIs
which are text-string based. So, the string representation of LDAP search
filters (RFC1960) was created along with the LDAP URL format (RFC1959)
and is utilized by the LDAP API (RFC1823).
Release 3.3 of the UMich LDAPv2 implementation (see this
page) implements RFCs 1959, 1960, and 1823, as do many other LDAPv2
implementations. However, those three RFCs are not officially "part" of
The LDAP URL, DN string representation, and search filter representation
concepts were officially rolled into the core of the LDAPv3 protocol family
(see this page). The documents representing
them are being progressed along the standards track along with RFC2251.
There is an IETF effort underway to produce an LDAPv3 API, which will
reference the below docs, although it is currently constituted as an Internet-Draft.
See the section on LDAP APIs for
The LDAP URL Format. T. Howes, M. Smith. December 1997.
The String Representation of LDAP Search Filters. T. Howes.
Also in terms of URI/URLs, there is this document which is applicable
to either LDAPv2 or v3...
An LDAP URL Format. T. Howes & M. Smith. June 1996.
Definition of an X.500 Attribute Type and an Object Class to Hold
Uniform Resource Identifiers (URIs). M. Smith. January 1997. (Format:
TXT=8757 bytes) (Status: PROPOSED STANDARD)
LDAP API Specifications:
The IETF officially doesn't "do" APIs
-- at this point in time, that is. There are movements afoot within the
IETF to do so. An example of this is
which is at Proposed Standard maturity level.
First up, Tim Howes & Mark
Smith authored this book on how to utilize the LDAPv2 API to build
It is a must-read if you need to learn the ins-and-outs of utilizing any
of the LDAP APIs.
LDAP: Programming Directory-Enabled Applications with Lightweight Directory
Access Protocol, T. Howes & M.
Smith, Macmillan Technical Publishing, 1997, ISBN 1-57870-000-0.
There are not yet any RFC-level documents for LDAPv3 APIs. Work is on-going
and there are several current Internet-Draft documents. There is a set
for C and a document for Java. First, the C docs...
The Java API doc...
Also, see [Howes&Smith97]
The C LDAP Application Program Interface. M. Smith, Editor.
T. Howes, A. Herron, C. Weider, M. Wahl, A. Anantha. INTERNET-DRAFT, Work
In Progress. March 1998.
The work on the LDAPv2 API is finished. It culminated in this document...
..which is an Informational RFC, i.e. it does not denote any sort
of official standard. Effectively, though, it is widely regarded in the
LDAP community as the de-facto standard LDAP API document. This API is
implemented in "libldap.a", the code to which is available at the UMich
LDAP/X.500 client, server, and general resource repository. See
this page for more information on various
client library implementations.
The LDAP Application Program Interface. T. Howes & M.
Smith. August 1995. (Format: TXT=41081 bytes) (Status: INFORMATIONAL)
Also, see [Howes&Smith97]
Encodings for Protocol and
The document below discusses the details of how information in the LDAP
protocol is overall encoded.
The documents below discuss the UTF-8 transformation format of the ISO
10646 character set, which are specified by LDAPv3 as the encoding
algorithm and character set for all the protocol's string types, respectively.
A Layman's Guide to a Subset of ASN.1, BER, and DER. Burton
S. Kaliski Jr. An RSA Laboratories Technical Note. Revised November 1,
Note that ISO 10646 and UNICODE are related. UNICODE
is advertised as a proper subset of the former.
UCS Transformation Format 8 (UTF-8). Mark Davis, WG2 Project
Editor. ISO/IEC JTC1/SC2/WG2 N 1036, 1994-08-01
[Davis94] specifies a normative Annex P to be added by the first
proposed drafted amendment (PDAM 1) to ISO/IEC 10646-1:1993. As of this
date (1994-12-01), the PDAM 1 is being balloted by ISO membership (in an
extended balloting period). The PDAM 1 may or may not be approved and/or
modified prior to becoming part of ISO/IEC 10646 (assuming it is approved).
These documents are relevant to either LDAPv2 or LDAPv3. They discuss
Directory attributes and their syntaxes. You should read this stuff if
you're setting up your directory and mapping your organization's information
into it and/or if you're creating new object classes or attributes.
Directory Services: DIT Design, Jim Rommel, Perot Systems
Corp., presented at EMA98 29-April-1998.
Rommel98 discusses classic X.500 DIT (Directory Information Tree)
design, and then presents and analyzes newer thinking on the topic. I strongly
suggest that readers take a close look at the new thinking.
Using Domains in LDAP/X.500 Distinguished Names. S. Kille,
M. Wahl, A. Grimstad, R. Huber, S. Sataluri. January 1998. (Format: TXT=12411
bytes) (Status: PROPOSED STANDARD)
RFC2247 is a piece of the new DIT layout thinking. It defines an
algorithm which maps DNS
names to LDAP DNs. Utilizing such a mapping leverages the procedures and
conventions already in existence for managing the DNS namespace
and thus making it easier for a site to lay out the high levels of its
Preparing Data for Inclusion in an X.500 Directory, Paul
Barker, Department of Computer Science, University Colleage London, May
Barker92 is a good overview of the subject matter, though with a
Quipu orientation. Quipu is an old X.500 server implementation from the
Consortium, now morphed into ISODE, Ltd
(and the Brit owners pronounce the name "eye-sode"). This paper presents
the classic X.500 organization-hierarchy perspective.
Note that ISODE currently supplies a quite high-quality and up-to-date
X.500(93)/LDAPv3 server. Links to this and other implementations are available
on this page.
Naming and Structuring Guidelines for X.500 Directory Pilots.
P. Barker, S. Kille & T. Lenggenhager. May 1994.(Format: TXT=56739
bytes) (Obsoletes RFC1384) (Status: INFORMATIONAL)
RFC1617 discusses how to organize one's directory from the classic
X.500 organization-hierarchy perspective. It can apply to standalone LDAP-based
directories as well as X.500-based ones. Note that there is recent thinking,
experimenting, and deployment of other forms of people directory hierarchies.
For example, see [Rommel98]
The next section
of these Roadmap pages provides pointers to documents describing how to
locate LDAP directory services, other transport for LDAP, mapping the DNS
onto LDAP-based directories, etc.
Back to the LDAP Roadmap table of
Back to the LDAP FAQ contents...
Back to the main LDAP Roadmap & FAQ page...
© 1996-1999 Jeff Hodges, All Rights Reserved