LDAP

Version History

LDAP is a standard for directory services with additional features that enhance its capabilities being added. LDAP may allow for consolodation of directory lists to be consolidated. An LDAP server provides the directory services and other LDAP functions. To avoid confusion about LDAP, it should be known that LDAP is an evolving service with additional capabilities being added over time. The original version was developed at the University of Michigan. The IETF has added updates since then which are in part fueled by various organizations. The main versions of LDAP are version 2 and version 3. Version 3 added additional capabilities such as directory replication and support for access control lists. With support for access control lists, LDAP may be able be used to control user access thrughout an organization such as is currently done using the Windows NT domain, single user logon for access to all computers in the organization or domain.

LDAP RFCs

There are several RFCs associated with LDAP and the various versions. They are listed below. Use the links in the Networking section to access web sites with RFCs.

• RFC1777 - Lightweight Directory Access Protocol. (Obsoletes RFC1487)
• RFC1778 - The String Representation of Standard Attribute Syntaxes
• RFC1779 - A String Representation of Distinguished Names.(Obsoletes RFC1485)
• RFC1823 - The LDAP Application Program Interface
• RFC1960 - A String Representation of LDAP Search Filters (Obsoletes RFC1558)
• RFC 2251 - Lightweight Directory Access Protocol (v3)
• RFC 2252 - LDAPv3 Attribute Syntax Definitions
• RFC 2253 - UTF-8 String Representation of Distinguished Names
• RFC 2254 - The String Representation of LDAP Search Filters
• RFC 2255 - The LDAP URL Format
• RFC 2256 - A Summary of the X.500(96) User Schema for use with LDAPv3
• RFC2829 - Authentication Methods for LDAP.
• RFC2830 - Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security.

Associated RFCs

• RFC1274 - The COSINE and Internet X.500 Schema
• RFC1279 - X.500 and Domains
• RFC1308 - Executive Introduction to Directory Services Using the X.500 Protocol
• RFC1309 - Technical Overview of Directory Services Using the X.500 Protocol
• RFC1617 - Naming and Structuring Guidelines for X.500 Directory Pilots (Obsoletes RFC1384)
• RFC1684 - Introduction to White Pages services based on X.500
• RFC2079 - Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)

LDAP Organization

LDAP servers contain entries which are defined uniquely with a distinguished name (DN). Required and optional attributes for the netries are defined by object classes which are defined in X.500. LDAP is hierarchial with a distinguished name with additional names that can be traced up the hierarchy to the root of the hierarchial tree.

LDAP and X.500

Since LDAP is based on X.500, it uses the X.500 object classes. These classes have a base class which is called "top".

X.500 Object Classes

The following object classes are defined by RFC1274. Each object have certain attributes which they must contain or may contain. Some, but not all of these attributes are listed here.

• alias - Must contain aliasedObjectName
• country - Must contain countryName. May contain description, searchGuide.
• friendlyCountry
• locality - May contain description, localityName, stateOrProvinceName, searchGuide, seeAlso, streetAddress.
• organization - Must contain organizationName. May contain organizationalAttributeSet.
• organizationalUnit - Must contain organizationalUnitName. May contain organizationalAttributeSet.
• person - Must contain commonName, surname. May contain description, seeAlso, telephoneNumber, userPassword. Subclasses:
• organizationalPerson - May contain localeAttributeSet, organizationalUnitName, postalAttributeSet, telecommunicationAttributeSet, title.
• mhsOrganizationalUser
• residentialPerson - Must contain localityName. May contain localeAttributeSet. postalAttributeSet, preferredDeliveryMethod, telecommunicationAttributeSet, usinessCategory.
• mhsResidentialUser
• pilotPerson
• organizationalRole - Must contain commonName. May contain description, localeAttributeSet, organizationalUnitName, postalAttributeSet, preferredDeliveryMethod, roleOccupant, seeAlso, telecommunicationAttributeSet.
• groupOfNames - Must contain commonName, member. May contain description, organizationName, organizationalUnitName, owner, seeAlso, businessCategory.
• applicationProcess - Must contain commonName. May contain description, localityName, organizationalUnitName, seeAlso,
• applicationEntity - Must contain commonName, presentationAddress. May contain description, localityName. Subclasses:
• dSA
• pilotDSA
• mhsMessageStore
• mhsMessageTransferAgent
• mhsUserAgent
• device
• strongAuthenticationUser
• certificationAuthority
• mhsDistributionList
• pilotObject
• account
• document
• room
• documentSeries
• domain
• localPort
• dnsDomain
• domainRelatedObject
• simpleSecurityObject
• qualityLabelledData

LDAP Distinguished Names

This section shows the LDAP information model. RFC 1779 states "Many OSI Applications make use of Distinguished Names (DN) as defined in the OSI Directory, commonly known as X.500." If you look at the listed distinguished names and their meanings below, you may notice that the names match the required attributes of some of the X.500 objects such as "countryName" for "country". LDAP grammer for distinguished names are listed below according to RFC 1779:

• CN - CommonName
• L - LocalityName
• ST - StateOrProvinceName
• O - OrganizationName
• OU - OrganizationalUnitName
• C - CountryName
• STREET - StreetAddress

The names are separated by commas or semicolons (as an alternate separator) and are listed as name/value pairs. An example is:

CN=Mark Allen, O=Computer Technology Documentation Project, ST=Michigan, C=US

LDAP Applications

With version 3 of LDAP, application functions have the below general categories:

• Locating network resources and users.
• Authenticating network users and servers along with confidentiality and integrity.
• Managing resources.

LDAP Provisions

• LDAP has an application Programming Interface (API) which is a set of functions that application programmmers use to allow their programs to access the LDAP directory and perform other functions supported by LDAP.
• The LDAP protocol which is used to communicate over the network or internet. This defines how TCP is used for transport.
• LDAP functional operations for client access and updating of information:
• add - Directory entry change
• delete - Directory entry change
• modify - Directory entry change
• bind - Start authentification information exchange between client and server.
• unbind - Stop authentification information exchange between client and server
• search - Locate services or users.
• compare - Test the information in the directory.
• modify distinguished name (DN) - Modify an entry name.
• abandon - discontinue a started LDAP operation.
• Naming model - This is a hierarchial model specifying the organization of the names from top to bottom. The top name is normally the OrganizationName then the OrganizationalUnitName, then the commonName of the person.
• Information model - Defined above.
• Security model - Defines how information is protected against unauthorized access.
• LDAP data interchange format (LDIF) is used to transfer data between LDAP servers.

LDAP is not a database, filesystem, or replacement for DNS. LDAP requires a connection oreinted form of network communication.

The LDAP Tree

• Root
• Country1
• Organization1
• Organizational Unit 1 (Engineering)
• Common name 1 (Mark)
• Common name 2
• Common name 3
• Organizational Unit 2 (IS)
• Common name 1 (Mark)
• Common name 2
• Common name 3
• Organizational Unit 3 (Sales)
• Common name 1 (Mark)
• Common name 2
• Common name 3
• Organization2
• Organization3
• Country2
• Country3