<!--

Copyright 2000-2007 Sun Microsystems, Inc. All Rights Reserved.
Portions copyright 1999 Netscape Communications Corporation. All
Rights Reserved.

The contents of this document are subject to the terms of the
Creative Commons Attribution-ShareAlike 2.5 license or any later
version (the "License"). You may not use this document except in
compliance with the License.

See the License for the specific language governing
permissions and limitations under the License. You can obtain
a copy of the License at
http://creativecommons.org/licenses/by-sa/2.5/legalcode.

-->
<chapter id="understanding-ldap"><title>Understanding LDAP</title>
<indexterm>
<primary>LDAP</primary>
</indexterm><indexterm>
<primary>Lightweight Directory Access Protocol</primary>
<see>LDAP</see></indexterm><highlights>
<para><firstterm>Lightweight Directory Access Protocol</firstterm> (LDAP)
is the Internet directory protocol. Developed at the University of Michigan
at Ann Arbor in conjunction with the Internet Engineering Task Force, LDAP
is a protocol for accessing and managing directory services.</para>
<itemizedlist>
<para>This chapter explains the LDAP protocol, and the concepts behind LDAP.
This chapter covers the following topics:</para>
<listitem><para><olink targetptr="how-ds-works">How Directory Services Work</olink></para>
</listitem>
<listitem><para><olink targetptr="how-ds-organizes-data">How LDAP Servers
Organize Directories</olink></para></listitem>
<listitem><para><olink targetptr="how-ldap-clients-servers-work">How LDAP
Clients and Servers Work</olink></para></listitem>
<listitem><para><olink targetptr="understanding-ldapv3">Understanding LDAP
v3</olink></para></listitem>
</itemizedlist>
</highlights>
<sect1 id="how-ds-works"><title>How Directory Services Work</title>
<indexterm>
<primary>directory</primary>
<secondary>definition of</secondary>
</indexterm><indexterm>
<primary>entries</primary>
<secondary>definition of</secondary>
</indexterm><indexterm>
<primary>attributes</primary>
<secondary>definition of</secondary>
</indexterm>
<para>A <firstterm>directory</firstterm> consists of <firstterm>entries</firstterm> that
contain descriptive information. For example, a directory might contain entries
that describe people or network resources, such as printers or fax machines.</para>
<para>The descriptive information is stored in the <firstterm>attributes</firstterm> of
the entry. Each attribute describes a specific type of information. For example,
attributes that describe a person might include her name, also referred to
as her common name (CN), telephone number, and email address.</para>
<para><indexterm>
<primary>entries</primary>
<secondary>example of</secondary>
</indexterm><indexterm>
<primary>attributes</primary>
<secondary>example of</secondary>
</indexterm>The entry for <literal>Barbara Jensen</literal> might have the
following attributes:</para>
<programlisting>cn: Barbara Jensen
mail: babs@example.com
telephoneNumber: 555-1212
roomNumber: 3995</programlisting>
<para>An attribute can have more than one value. For example, a person might
have two common names, both a formal name and also a nickname:</para>
<programlisting>cn: Barbara Jensen
cn: Babs Jensen
mail: babs@example.com
telephoneNumber: 555-1212
roomNumber: 3995</programlisting>
<para>Attributes can also contain binary data. For example, a person's attributes
might include her photo in JPEG format, a recording of her voice as an audio
file, or her SSL certificate.</para>
<para><indexterm>
<primary>directory service</primary>
<secondary>definition of</secondary>
</indexterm>A <firstterm>directory service</firstterm> is a distributed database
application for managing the entries and attributes in a directory. A directory
service also makes the entries and attributes available to users and other
applications.</para>
<para>&cnDirectoryServer; is an example of a directory service. For example,
a user might use the directory service to look up someone's telephone number.
Another application might use the directory service to retrieve a list of
email addresses.</para>
<para><indexterm>
<primary>LDAP servers</primary>
</indexterm><indexterm>
<primary>LDAP clients</primary>
</indexterm>LDAP is a protocol that defines a directory service and access
to that service. LDAP is based on a client-server model. LDAP servers provide
the directory service. LDAP clients use the directory service to access entries
and attributes.</para>
<para><indexterm>
<primary>LDAP servers</primary>
<secondary>example of</secondary>
</indexterm><indexterm>
<primary>LDAP clients</primary>
<secondary>example of</secondary>
</indexterm>&cnDirectoryServer; is an example of an LDAP server that manages
and provides information about users and organizational structures. Examples
of LDAP clients include Identity Manager, Access Manager, <trademark>Solaris</trademark> naming
services, Messaging Server, Portal Server, NameFinder, and the Mozilla mail
client. Such clients use &cnDirectoryServer; to find, update, and add information
about users.</para></sect1>
<sect1 id="how-ds-organizes-data"><title>How LDAP Servers Organize Directories</title>
<indexterm>
<primary>LDAP</primary>
<secondary>organization of data</secondary>
</indexterm><indexterm>
<primary>entries</primary>
<secondary>organization in LDAP</secondary>
</indexterm><indexterm>
<primary>LDAP servers</primary>
<secondary>how data is organized</secondary>
</indexterm>
<para>Because LDAP is intended to be a global directory service, data is organized
hierarchically, starting at a root and branching down into individual entries.</para>
<para>At the top level of the hierarchy, entries represent larger organizations.
Under larger organizations in the hierarchy, you might find entries for smaller
organizations. The hierarchy might end with entries for individual people,
or resources, as shown in the following figure.</para>
<figure id="hierarchy-in-ldap"><title>Hierarchy of Entries in a Directory</title>
<mediaobject>
<imageobject><imagedata entityref="hierovrw"></imageobject>
<textobject><simpara>Simple directory information tree with two organizational
unit entries and two user entries</simpara></textobject>
</mediaobject>
</figure>
<para><indexterm>
<primary>relative distinguished names (RDNs)</primary>
<secondary>definition of</secondary>
</indexterm><indexterm>
<primary>RDNs</primary>
<see>relative distinguished names (RDNs)</see></indexterm><indexterm>
<primary>distinguished names (DNs)</primary>
<secondary>definition of </secondary>
</indexterm><indexterm>
<primary>CNs</primary>
<see>common names (CNs)</see></indexterm><indexterm>
<primary>DNs</primary>
<see>distinguished names (DNs)</see></indexterm><indexterm>
<primary>common names (CNs)</primary>
</indexterm>Each entry is uniquely identified by a <firstterm>distinguished
name</firstterm> (DN). A DN includes a relative distinguished name (RDN),
that uniquely identifies the entry at that hierarchical level. For example, <literal>
bjensen</literal> and <literal>kjensen</literal> are different user IDs that
identify different entries at the same level. Following the RDN is a path
of names that trace the entry back to the root of the tree, such as <literal>ou=People,dc=example,dc=com
</literal>. <literal>DC</literal> is short for domain component. The full
DN for this example would be <literal>uid=bjensen,ou=People,dc=example,dc=com</literal>.
Here, <literal>uid</literal> is the user ID of the entry. <literal>ou</literal> is
short for organizational unit.</para>
<para><indexterm>
<primary>LDAP servers</primary>
<secondary>how data is distributed</secondary>
</indexterm>The data stored in a directory can be distributed among several
LDAP servers. For example, one LDAP server at <literal>Example.com</literal> might
contain entries representing North American organizational units and employees,
while another LDAP server might contain entries representing European organizational
units and employees.</para>
<para><indexterm>
<primary>LDAP servers</primary>
<secondary>how referrals work</secondary>
</indexterm><indexterm>
<primary>referrals</primary>
</indexterm>Some LDAP servers are set up to refer requests to other LDAP servers.
For example, if the LDAP server at <literal>Example.com</literal> receives
a request for information about an employee in a Pacific Rim branch, that
server can refer the request to the LDAP server at the Pacific Rim branch.
In this way, LDAP servers can appear to be a single source of directory information.
Even if an LDAP server does not contain the information you request, the server
can refer you to another server that does contain the information.</para>
</sect1>
<sect1 id="how-ldap-clients-servers-work"><title>How LDAP Clients and Servers
Work</title>
<indexterm>
<primary>LDAP servers</primary>
<secondary>LDAP clients and</secondary>
</indexterm><indexterm>
<primary>LDAP clients</primary>
<secondary>LDAP servers and</secondary>
</indexterm><indexterm>
<primary>LDAP clients</primary>
<secondary>operations performed by</secondary>
</indexterm>
<para>In the LDAP client-server model, LDAP servers such as &cnDirectoryServer;
make information about people, organizations, and resources accessible to
LDAP clients. LDAP defines operations that clients use to search and update
the directory.</para>
<itemizedlist>
<para>An LDAP client can perform these operations, among others:</para>
<listitem><para>Search for and retrieve entries from the directory</para>
</listitem>
<listitem><para>Add new entries to the directory</para></listitem>
<listitem><para>Update entries in the directory</para></listitem>
<listitem><para>Delete entries from the directory</para></listitem>
<listitem><para>Rename entries in the directory</para></listitem>
</itemizedlist>
<para>For example, to update an entry, an LDAP client submits the distinguished
name of the entry with updated attribute information to the LDAP server. The
LDAP server uses the distinguished name to find the entry. The server then
performs a modify operation to update the entry in the directory.</para>
<para><indexterm>
<primary>LDAP servers</primary>
<secondary>connecting with LDAP clients</secondary>
</indexterm><indexterm>
<primary>LDAP clients</primary>
<secondary>connecting with LDAP servers</secondary>
</indexterm>To perform any of these LDAP operations, an LDAP client needs
to establish a connection with an LDAP server. The LDAP protocol specifies
the use of TCP/IP port number 389, although servers can run on other ports.</para>
<para><indexterm>
<primary>LDAP servers</primary>
<secondary>authentication</secondary>
</indexterm><indexterm>
<primary>LDAP clients</primary>
<secondary>authentication</secondary>
</indexterm>The LDAP protocol also defines a simple method for authentication.
LDAP servers can be set up to restrict permissions to the directory. Before
an LDAP client can perform an operation on an LDAP server, the client must
authenticate to the server. Clients typically authenticate by supplying a
distinguished name and password. If the user identified by the distinguished
name does not have permission to perform the operation, the server does not
execute the operation.</para></sect1>
<sect1 id="understanding-ldapv3"><title>Understanding LDAP v3</title>
<indexterm>
<primary>LDAP</primary>
<secondary>version 3</secondary>
</indexterm>
<para><ulink url="http://www.ietf.org/rfc/rfc4511.txt" type="text_url">RFC
4511</ulink> specifies LDAP version 3. Use this version of the protocol when
writing new client applications.</para>
<para>Many LDAP servers continue to support LDAP version 2 for use with legacy
clients. This version of the protocol is specified in <ulink
url="http://www.ietf.org/rfc/rfc1777.txt" type="text_url">RFC 1777</ulink>.</para>
<itemizedlist>
<para>LDAP v3 includes new features not present in version 2:</para>
<listitem><para>Clients and servers can specify <firstterm>controls</firstterm> that
extend the functionality of an LDAP operation.</para></listitem>
<listitem><para>Clients can request that the server perform <firstterm>extended
operations</firstterm>, operations not included in the list of standard LDAP
operations.</para></listitem>
<listitem><para>Clients can use <firstterm>Simple Authentication and Security
Layer</firstterm> (SASL) mechanisms to authenticate to the directory. SASL
is specified in <ulink url="http://www.ietf.org/rfc/rfc4422.txt" type="text_url">
RFC 4422</ulink>.</para></listitem><?Pub Caret>
<listitem><para>Servers, known as <firstterm>Directory System Agents</firstterm> (DSAs),
have <firstterm>DSA-specific entries</firstterm> (DSEs). DSEs provide information
about the versions of the LDAP protocol that the server supports. DSEs also
provide a list of the controls, extended operations, and SASL mechanisms supported
by the server. Finally, DSEs specify the naming contexts of the server. Naming
contexts are portions of the directory information tree managed by the server.</para>
</listitem>
<listitem><para>Servers make their <firstterm>schemas</firstterm>, which define
the object classes, attributes, syntaxes, and matching rules enforced by the
directory, available to clients through the root DSE.</para></listitem>
<listitem><para><indexterm>
<primary>UTF-8</primary>
<secondary>support of</secondary>
</indexterm>Both client and server applications can support data in UTF-8. <firstterm>
UTF-8</firstterm> is a transformation format of the Universal Character Set
standard. UTF-8 is specified in <ulink url="http://www.ietf.org/rfc/rfc3269.txt"
type="text_url">RFC 3269</ulink>. With UTF-8, clients can request and receive
data that is tagged with language information.</para></listitem>
</itemizedlist>
</sect1>
</chapter>
