Light Weight Directory Access Protocol (LDAP) is an open network protocol standard designed to provide access to distributed directories. LDAP provides a mechanism for querying and modifying information that resides in a directory information tree (DIT). A directory information tree typically contains a broad range of information about different types of network objects including users, printers, applications, and other network resources. LDAP is described through four basic models: Information, Naming, Functional, and Security. The combination of these models introduces a nomenclature that describes entries and their attributes, and provides methods to query and manipulate their values.
This section discusses the origins of LDAP and the basic models used to describe LDAP. It also highlights additional LDAP topics that are necessary to be successful in an LDAP environment.
In today’s distributed computing environment, directories are required to locate resources. Directories typically consist of databases and protocols. A directory database must have a schema that acts as the blue print for the various objects that exist in the directory, and it must be capable of being distributed across the network. Because a directory database is distributed across the network, specialized directory access protocols are required to query and manipulate the directory remotely. Directories and databases have many things in common such as the same central theme of allowing access to stored data. However, directories have special requirements that differentiate them from relational databases. Directories are designed to be ‘read-mostly.’ The distributed nature of directories makes them inherently better at read requests as opposed to frequent updates. Because the directory is distributed, there may exist entries or attributes that have values in different states due to the delayed replication propagation. Finally, directories lack the transactional semantics that are found in modern relational databases.
The need to query directories may be traced back to the days of X.500 and Directory Access Protocol (DAP). X.500 is an International Standards Organization (ISO) standard that defines directory entries in a hierarchical namespace of information. The namespace could be arranged into a Directory Information Tree that is composed of Directory Server Agents. A Directory Server Agent is a computer that actually hosts a network directory and functions as an LDAP server. The Directory Information Tree can be searched from client computers by using the Directory Access Protocol (DAP), which was built on top of the Open Systems Interconnection (OSI) protocol stack.
Light Weight Directory Access Protocol was designed to provide access to distributed directories. The objective of the LDAP designers was to provide a highly functional directory access and manipulation protocol that remained relatively simple. LDAP allows one to query and manipulate information that exists in the DIT The DIT might include information about users (e-mail or phone numbers) or resources. The term resources broadly describes printers, Distributed File System shares, or SQL Server databases.
The key aspects of LDAP are the following:
· Protocol elements are carried directly over Internet Protocol (IP), as either Transmission Control Protocol (TCP) or User Datagram Protocol (UDP).
· Many protocol data elements are encoded as ordinary strings.
· A lightweight Basic Encoding Rules (BER) encoding method is used to encode all protocol elements.
The popularity of LDAP may be attributed to the fact that it has excelled in four different areas: features, standards, implementation, and APIs. The ability to authenticate, query, and manipulate directories are the features required of a directory access protocol. The LDAP protocol is an IETF (Internet Engineering Task Force) standard. The IETF has also developed standards for well-known protocols like Domain Name System (DNS), Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), and Hypertext Transfer Protocol (HTTP). Several parties including the University of Michigan, Netscape, and Microsoft have implemented the LDAP protocol. Finally, the APIs were defined via the information RFC 1823. It is important to note the distinction between the APIs and the protocol.
LDAP is described by a combination of the following models:
· An Informational model that describes the structure of information in a directory information tree.
· A Naming model that describes how information is organized and referenced.
· A Functional model that describes what can be done with the information.
· A Security model that describes how information is protected in the directory information tree.
The informational model was derived from the ISO X.500 standard for creating enterprise-level directories. The informational model as defined in RFC 1777 “Lightweight Directory Access Protocol” and RFC 2251 “Lightweight Directory Access Protocol (v3)” describes entries and attributes. Information about what a schema is has been included for the completeness of this discussion.
A schema acts as a blue print or a template for the directory. The schema provides a listing of classes and attributes from which all entries are derived. For an entry or attribute to exist in the directory information tree, it must adhere to the definitions that are described in the schema. The schema defines the available classes, attribute type definitions, and the syntax from which an entry can be derived.
A class is a category of objects that share a set of common characteristics. Each object in the directory is an instance of one or more classes in the schema. RFC 2252, section 4.4, states that object classes are defined in X.501. In general, every entry contains an abstract class ("top" or "alias"), at least one structural object class, and zero or more auxiliary object classes. Microsoft chose not to implement the abstract class “alias,” which is used in some directory information trees as a pointer when objects have been moved. The alias class is not necessary within the Microsoft directory information tree because Microsoft made objects rename-safe by attaching an attribute called a Globally Unique IDentifier (GUID) to each object. A GUID is a 128-bit (16-byte) number generated by an algorithm designed to ensure its uniqueness. This algorithm is part of the Open Software Foundation (OSF) Distributed Computing Environment (DCE), which provides a set of standards for distributed computing.
Abstract classes serve as templates for structural classes. Abstract classes must not exist in the DSA as an entry.
Structural classes are derived from abstract classes; they may exist in the DSA as an entry. Structural classes inherit all the attributes that are associated with parent abstract classes.
Auxiliary classes allow an entry to inherit a specific set of attributes. Auxiliary classes work like include files. The ‘88’ classes were defined before the 1993 X.500 standard and may be considered a legacy. If you look at the attribute ObjectClass for an entry, you can determine which classes were used to derive that entry. For example, the ObjectClass attribute of a user entry enumerates the following classes: top, person, organizationalPerson, and user. Top, person, and organizationalPerson are all abstract classes. User is the structural class from which the entry was actually created.
Attributes are data items used to describe the classes defined in the schema. They are defined in the schema separately from the classes, which allows a single attribute definition to be applied to many classes. The attribute type is identified by a short descriptive name and an OID (object identifier). Attributes are defined in RFC 2252 “Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions.” Examples of attributes that are defined in RFC 2256 LDAPv3 Schema include:
· Common Name – CN (2.5.4.3)
· Organizational Unit – OU (2.5.4.11)
· ObjectClass (2.5.4.0)
The syntax for an attribute defines the storage representation, byte ordering, and the matching rules for comparisons of property types. The syntax specifies whether the attribute value must be a string, a number, a unit of time, and so forth. Every attribute of every object is associated with exactly one syntax. RFC 2252 defines the syntax requirements. The syntaxes for use with LDAP are named by OIDs. Examples of syntaxes include:
· Distinguished Name (1.3.6.1.4.1.1466.115.121.1.12)
· UTC time (1.3.6.1.4.1.1466.115.121.1.53)
· Object Class Description (1.3.6.1.4.1.1466.115.121.1.37)
An entry is either a container or a leaf object of a specific structural class. Microsoft often refers to directory entries as ‘objects’. An entry is composed of various attributes that are defined in the schema for the class from which it was derived. Entries must have a Relative Distinguished Name (RDN) that is unique among its siblings, and the concatenation of the RDNs or Distinguished Name (DN) must be unique in the directory information tree.
Both container and leaf entries may have attributes. Attributes are defined in the schema and must obey the schema’s definition. Microsoft often refers to attributes as properties. Attributes are composed of a name, an OID, and a value. The syntax for the attribute is defined in the schema. Attributes are classified as ‘must’ or ‘may’. Attributes that classified as ‘must’ are mandatory attributes, and an entry must have the attribute to exist. ‘May’ attributes are optional for the entry. Finally, attributes may be either single or multiple value in nature.
The OSI directory model used distinguished name as the primary key for entries in the directory. The naming model is outlined briefly in RFCs 1777 and 2251. The LDAP naming model was further enumerated in RFC 1779 “A String Representation of Distinguished Names” and RFC 2253 “Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names.”
Entries are arranged in the directory information tree based on their Distinguished Name. The Distinguished Name consists of a series of Relative Distinguished Names and serves as a primary key for an object in the directory information tree. Each naming component represents a branch in the directory information tree. A Distinguished Name is analogous to the absolute path name to a file in the Windows file system.
Following are examples of Distinguished Names. In these examples, cn means CommonName and dc means DomainComponent.
· cn=Dan,dc=Microsoft,dc=com
· cn=tim,cn=mydomain,dc=com
Each component of the Distinguished Name is a Relative Distinguished Name. The Relative Distinguished Name is unique within its container, and is analogous to a file name or directory in a file system. The RDN consists of an attribute type and a value, and is formatted as: <rdncomp> :== <attr> ‘=’ <value>.
Examples of RDNs are listed below, where OU stands for organizational unit:
· cn=Dan
· ou= Sales
· dc= Microsoft
The functional model consists of nine operations in three areas:
· Authentication allows the client to prove its identity to the DSA.
]· Interrogation provides a method for the client to interrogate the directory information tree.
· Update defines a mechanism for the client to add or modify information in the directory information tree.
The authentication model includes the following operations:
· Open. This command creates and initializes a connection block, then opens the connection to the DSA.
· Bind. This command initiates a protocol session to the DSA. After a session is established, a method of authentication is negotiated between the DSA and the client. When the client is authenticated by the DSA, the DSA returns a Bind response to the client.
· Unbind. This command terminates an LDAP session between the client and the DSA.
The interrogation model includes the following operations:
· Search. This operation is used to select entries from a specific region of the directory information tree based on customized criteria called a search filter. The following arguments are used to perform the search:
· Compare. This operation returns a Boolean response based upon a comparison of an entry’s attribute value.
The update model consists of the following operations:
· Add. This command creates an object in the directory information tree based on information provided by the client to the DSA. The information that is passed to the DSA must meet the conditions that are imposed on entry creation through the classes that are defined in the schema.
· Modify. This command allows the client to modify an entry’s attributes. Modification of attributes includes creating, modifying, and deleting the attributes.
· Modify RDN. This command provides a mechanism for an entry to be moved in the directory information tree. By modifying the RDN components of an entry, the entry is effectively moved to a new container with in the DIT.
· Delete. This command provides a method for a client to remove an entry from the directory information tree. The success of an entry modification is dependent on the schema’s constraints and the access permission of the client.