275 lines
13 KiB
Plaintext
275 lines
13 KiB
Plaintext
<!--
|
|
|
|
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>
|