blogger templates blogger widgets
This is part of a list of blog posts.
To browse the contents go to

Introduction to LDAP

LDAP is a advanced directory service provider (protocol NOT a product). It's more than just a service provider as you will see later.

LDAP originated from DAP(Directory Access Protocol) which was initially developed to maintain a network based directory for the email server.

LDAP protocol was later standardized in 1993 and LDAP specification came into being. The latest specification is Version 3, published as RFC 4511.

LDAP does not define how data is stored, only how it is accessed.

There are various implementations (products):

  • OpenLDAP
  • ApacheDS
  • ActiveDirectory
  • IBM Tivoli Directory Server

LDAP data model


  • Data is represented in an LDAP system as a hierarchy of objects, each of which is called an entry.
  • The resulting tree structure is called a Data Information Tree (DIT). The top of the tree is commonly called the root (a.k.a base or the suffix).
  • Each entry is an instance of one or more objectClasses.
  • ObjectClasses contain zero or more attributes.
  • All attributes are members of one, or more, objectClass(es).
  • Attributes can be optional (keyword is MAY) or mandatory (keyword is MUST) as described in the ASN.1 definitions for the objectclass of which they are a member. An attribute may be optional in one objectclass and mandatory in another. It is the objectclass which determines this property.
  • Attributes can have single or multi values.
  • Attributes have names and sometimes aliases or abbreviations for example, commonName (a member of the objectClass, person (and many others)) and has an abbreviated name of cn.
  • At each level in the hierarchy the data contained in an attribute can be used to uniquely identify the entry. It can be any attribute in the entry. It can even be a combination of two or more attributes.
  • ObjectClasses may be organised in a hierarchy in which case they inherit all the properties of their parents.
  • ObjectClasses may be STRUCTURAL, in which case they can be used to create entries (data objects), AUXILIARY in which case they may be added into any convenient entry, or ABSTRACT - a non-existent 'thingy'. The most common ABSTRACT objectclass is top, which forms the highest level of every objectClass hierarchy, and terminates any hierarchy.
  • Each entry in DIT has one parent entry (except for the DIT root) and zero or more child entries (objects). An entry must comprise one (and only one) STRUCTURAL objectClass but may contain any number of AUXILIARY objectClasses. The data content of an entry consist of one or more attributes one (or more) of which is (are) used as the naming attribute (more correctly the RDN) to uniquely identify this object in the DIT.
  • If an objectClass is part of a hierarchy it must be the same type (STRUCTURAL, AUXILIARY) as any parent objectClass.
  • To use an attribute in an entry, its objectClass must be included in the entry definition.
  • Each attribute defines the data type that it may contain. Here is a list of datatypes: ldap data types
  • An attribute definition may be part of a hierarchy, in which case it inherits all the properties of its parents. For example, commonName (cn), givenName (gn) and surname (sn) are all children of the name attribute. Unlike the objectClass, attribute hierarchies are not terminated with a top equivalent. In the attribute case it is the absence of a parent definition which indicates, surprisingly, that this is the end of the hierarchy.
  • LDAP schema is nothing more than a convenient packaging unit for containing broadly similar objectClasses and attributes.
There are a confusing number of pre-defined objectclasses, each of which contains bucket-loads of attributes suitable for almost all common LDAP implementations. It goes without saying, however, that in spite of all those pre-defined objectClasses, the one you really, really need is never there!

Some standard object classes used: ldap standard objects

Object IDentifier (OID) is a dot-separated valued e.g. (OID of country objectclass) that uniquely defines an object and who is responsible for its definition.

The Relative Distinguished Name (frequently but incorrectly written as Relatively Distinguished Name). The name given to an attribute(s) that is unique at its level in the hierarchy. RDNs may be single valued or multi-valued in which case two or more attributes are combined using '+' (plus) to create the RDN e.g. cn+uid.

If you are looking more about LDAP :

The examples that follows use ApacheDS.

Continue reading:Prerequisites

No comments:

Post a Comment