Mozilla LDAP SDK Programmer's Guide/Understanding LDAP
Lightweight Directory Access Protocol (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.
Contents
How Directory Services Work
A directory consists of entries that contain descriptive information. For example, a directory might contain entries that describe people or network resources, such as printers or fax machines.
The descriptive information is stored in the attributes 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.
The entry for Barbara Jensen might have the following attributes:
cn: Barbara Jensen mail: babs@example.com telephoneNumber: 555-1212 roomNumber: 3995
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:
cn: Barbara Jensen cn: Babs Jensen mail: babs@example.com telephoneNumber: 555-1212 roomNumber: 3995
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.
A directory service 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.
Directory Server 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.
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.
Directory Server 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, SolarisTM naming services, Messaging Server, Portal Server, NameFinder, and the Mozilla mail client. Such clients use Directory Server to find, update, and add information about users.
How LDAP Servers Organize Directories
Because LDAP is intended to be a global directory service, data is organized hierarchically, starting at a root and branching down into individual entries.
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.
Each entry is uniquely identified by a distinguished name (DN). A DN includes a relative distinguished name (RDN), that uniquely identifies the entry at that hierarchical level. For example, bjensen and kjensen 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 ou=People,dc=example,dc=com. DC is short for domain component. The full DN for this example would be uid=bjensen,ou=People,dc=example,dc=com. Here, uid is the user ID of the entry. ou is short for organizational unit.
The data stored in a directory can be distributed among several LDAP servers. For example, one LDAP server at Example.com might contain entries representing North American organizational units and employees, while another LDAP server might contain entries representing European organizational units and employees.
Some LDAP servers are set up to refer requests to other LDAP servers. For example, if the LDAP server at Example.com 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.
How LDAP Clients and Servers Work
In the LDAP client-server model, LDAP servers such as Sun/Oracle Directory Server, OpenLDAP, Red Hat Directory Server, ForgeRock OpenDJ, Apache Directory Server and others make information about people, organizations, and resources accessible to LDAP clients. LDAP defines operations that clients use to search and update the directory.
- Search for and retrieve entries from the directory
- Add new entries to the directory
- Update entries in the directory
- Delete entries from the directory
- Rename entries in the directory
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.
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.
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.
Understanding LDAP v3
RFC 4511 specifies LDAP version 3. Use this version of the protocol when writing new client applications.
Many LDAP servers continue to support LDAP version 2 for use with legacy clients. This version of the protocol is specified in RFC 1777.
Clients and servers can specify controls that extend the functionality of an LDAP operation.
Clients can request that the server perform extended operations, operations not included in the list of standard LDAP operations.
Clients can use Simple Authentication and Security Layer (SASL) mechanisms to authenticate to the directory. SASL is specified in RFC 4422.
Servers, known as Directory System Agents (DSAs), have DSA-specific entries (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.
Servers make their schemas, which define the object classes, attributes, syntaxes, and matching rules enforced by the directory, available to clients through the root DSE.
Both client and server applications can support data in UTF-8. UTF-8 is a transformation format of the Universal Character Set standard. UTF-8 is specified in RFC 3269. With UTF-8, clients can request and receive data that is tagged with language information.
