Tuesday, April 25, 2006

List of LDAP vendors

Supporting vendors

LDAP has gained wide support from vendors such as:

* Apache (through Apache Directory Server)
* Apple (through Open Directory/OpenLDAP)
* AT&T
* Avaya (through Directory Enabled Management)
* Banyan
* Critical Path
* eB2Bcom (through View500)
* Fedora Directory Server
* Hewlett-Packard
* Identyx
* IBM/Lotus
* ISODE (through M-Vault server)
* Microsoft (through Active Directory)
* Netscape (now in Sun Microsystems and Red Hat products)
* Novell (through eDirectory)
* OctetString (through VDE server)
* Oracle (through Oracle Internet Directory)
* Radiant Logic (through RadiantOne Virtual Directory Server)
* Red Hat Directory Server
* Siemens AG (through DirX server)
* SGI and
* Sun (through the iPlanet and Sun ONE directory servers)
* Symlabs (through Directory Extender)

What is LDAP

Lightweight Directory Access Protocol

In computer networking, the Lightweight Directory Access Protocol, or LDAP, is a networking protocol for querying and modifying directory services running over TCP/IP. An LDAP directory usually follows the X.500 model: It is a tree of entries, each of which consists of a set of named attributes with values. While some services use a more complicated "forest" model, the vast majority use a simple starting point for their database organization.
Read More

An LDAP directory often reflects various political, geographic, and/or organizational boundaries, depending on the model chosen. LDAP deployments today tend to use Domain Name System (DNS) names for structuring the most simple levels of the hierarchy. Further into the directory might appear entries representing people, organizational units, printers, documents, groups of people or anything else which represents a given tree entry, or multiple entries.

Its current version is LDAPv3, as defined in RFC 3377.

* 1 Origin and influences
* 2 Protocol overview
* 3 Directory structure
* 4 Operations
o 4.1 Bind (authenticate)
o 4.2 Start TLS
o 4.3 Search and Compare
o 4.4 Update operations
o 4.5 Extended operations
o 4.6 Abandon
o 4.7 Unbind
* 6 Schema
* 7 Variations
* 8 Other data models
* 9 Terminology
* 10 Supporting vendors
o 10.1 LDAP implementations
* 11 References
* 12 See also
* 13 External links
o 13.1 LDAP fora
o 13.2 RFCs


Origin and influences

LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services. X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol, or DAP, which required the cumbersome Open Systems Interconnection (OSI) protocol stack. With LDAP, a client could access these directory services through a LDAP-to-DAP gateway. The gateway would translate LDAP requests to DAP requests and DAP responses to LDAP. This model of directory access was borrowed from DIXIE and the Directory Assistance Service.

Standalone LDAP directory servers soon followed, as did directory servers supporting both DAP and LDAP. The former has become popular in enterprises as they removed any need to deploy an OSI network. Today, X.500 directory protocols including DAP can be also used directly over TCP/IP.

The protocol was originally created by Tim Howes of the University of Michigan, Steve Kille of ISODE and Wengyik Yeong of Performance Systems International, circa 1993. Further development has been done via the Internet Engineering Task Force (IETF). It is noted that in the early engineering stages of LDAP, it was known as Lightweight Directory Browsing Protocol or LDBP. It was renamed as the scope of the protocol was expanded to not only include directory browsing functions (e.g., search) but also directory update functions (e.g., modify).

LDAP has influenced subsequent Internet protocols, including later versions of X.500, XML Enabled Directory (XED), Directory Services Markup Language (DSML), Service Provisioning Markup Language (SPML), and the Service Location Protocol (SLP).

Protocol overview

A client starts an LDAP session by connecting to an LDAP server, by default on TCP port 389. The client then sends operation requests to the server, and the server sends responses in return. With some exceptions the client need not wait for a response before sending the next request, and the server may then send the responses in any order.

The basic operations are, in order:

* Bind - authenticate, and specify LDAP protocol version,
* Start TLS - protect the connection with Transport Layer Security (TLS), to have a more secure connection,
o Search - search for and/or retrieve directory entries,
o Compare - test if a named entry contains a given attribute value,
o Add a new entry,
o Delete an entry,
o Modify an entry,
o Modify DN - move or rename an entry,
o Abandon - abort a previous request,
o Extended Operation - generic operation used to define other operations,
* Unbind - close the connection, not the inverse of Bind.

In addition the server may send "Unsolicited Notifications" that are not responses to any request, e.g. before it times out a connection.

LDAP is defined in terms of ASN.1, and protocol messages are encoded in the binary format BER. It uses textual representations for a number of ASN.1 fields/types, however.

Directory structure

The protocol accesses LDAP directories, which follow the X.500 model:

A directory is a tree of directory entries.
An entry consists of a set of attributes.
An attribute has a name (an attribute type or attribute description) and one or more values.
The attributes are defined in a schema (see below).

Each entry has an unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN) constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as a full filename and the RDN as a relative filename in a folder.

Be aware that a DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, an UUID is provided in the set of the entry's operational attributes.

An entry can look like this when represented in LDIF format (LDAP itself is a binary protocol):

dn: cn=John Doe,dc=example,dc=com
cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 555 6789
telephoneNumber: +1 555 1234
mail: john@example.com
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

dn is the name of the entry; it's not an attribute nor part of the entry. "cn=John Doe" is the entry's RDN, and "dc=example,dc=com" is the DN of the parent entry. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, and "mail" for e-mail address.

A server holds a subtree starting from a specific entry, e.g. "dc=example,dc=com" and its children. Servers may also hold references to other servers, so an attempt to access "ou=Some department,dc=example,dc=com" could return a referral or continuation reference to a server which holds that part of the directory tree. The client can then contact the other server. Some servers also support chaining, which means the server contacts the other server and returns the results to the client.

LDAP rarely defines any ordering: The server may return the values in an attribute, the attributes in an entry, and the entries found by a search operation in any order.


The client gives each request a positive Message ID, and the server response has the same Message ID. The response includes a numeric result code indicating success, some error condition or some other special cases. Before the response, the server may send other messages with other result data - for example each entry found by the Search operation is returned in such a message.

Bind (authenticate)

The Bind operation authenticates the client to the server. Simple Bind sends the user's DN and password - in cleartext, so the connection should be protected using Transport Layer Security (TLS). The server typically checks the password against the userPassword attribute in the named entry. Anonymous Bind (with empty DN and password) resets the connection to anonymous state.. SASL (Simple Authentication and Security Layer) Bind provides authentication services through a wide-range of mechanisms, e.g. Kerberos or the client certificate sent with TLS.

Bind also sets the LDAP protocol version. Normally clients should use LDAPv3, which is the default in the protocol but not always in LDAP libraries.

Start TLS

The Start TLS operation establishes Transport Layer Security (the descendant of SSL) on the connection. That can provide data confidentiality protection (hide the data) and/or data integrity protection (protect from tampering). During TLS negotiation the server sends its X.509 certificate to prove its identity. The client may also send a certificate to prove its identity. After doing so, the client may then use SASL/EXTERNAL to have this identity used in determining the identity used in making LDAP authorization decisions.

Servers also often support the non-standard "LDAPS" ("Secure LDAP", commonly known as "LDAP over SSL") protocol on a separate port, by default 636. The LDAPS differs from LDAP in two ways: 1) upon connect, the client and server establish TLS before any LDAP messages are transferred (without a Start TLS operation) and 2) the LDAPS connection must be closed upon TLS closure.

Search and Compare

The Search operation is used to both search for and read entries. Its parameters are:

* baseObject - the DN (Distinguished Name) of the entry at which to start the search,
* scope - baseObject (search just the named entry, typically used to read one entry), singleLevel (entries immediately below the base DN), or wholeSubtree (the entire subtree starting at the base DN).
* filter - how to examine each entry in the scope. E.g. (&(objectClass=person)(|(givenName=John)(mail=john*))) - search for persons who either have given name John or an e-mail address starting with john.
* derefAliases - whether and how to follow alias entries (entries which refer to other entries),
* attributes - which attributes to return in result entries.
* sizeLimit, timeLimit - max number of entries, and max search time.
* typesOnly - return attribute types only, not attribute values.

The server returns the matching entries and maybe continuation references (in any order), followed by the final result with the result code.

The Compare operation takes a DN, an attribute name and an attribute value, and checks if the named entry contains that attribute with that value.

Update operations

Add, Delete, Modify and Modify DN all require the DN of the entry to change.

Modify takes a list of attributes to modify and the modifications to each: Delete the attribute or some values, add new values, or replace the current values with the new ones.

Add operations also can have additional attributes and values for those values.

Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name), optionally the new parent's DN, and a flag which says whether to delete the value(s) in the entry which match the old RDN. The server may support renaming of entire directory subtrees.

An update operation is atomic: Other operations will see either the new entry or the old one. On the other hand, LDAP does not define transactions of multiple operations: If you read an entry and then modify it, another client may have updated the entry in the mean time. Servers may implement extensions which support this, however.

Extended operations

The Extended Operation is a generic LDAP operation which can be used to define new operations. Examples include the Cancel, Password Modify and Start TLS operations.


The Abandon operation requests that the server aborts an operation named by a message ID. The server need not honor the request. Unfortunately neither Abandon nor a successfully abandoned operation send a response. A similar Cancel extended operation has therefore been defined which does send responses, but not all implementations support this.


The Unbind operation abandons any outstanding operations and closes the connection. It has no response. The name is of historical origin: It is not the opposite of the Bind operation.

Clients can abort a session by simply closing the connection, but they should use Unbind. Otherwise the server cannot tell the difference between a failed network connection (or a truncation attack) and a discourteous client.


An LDAP URL format exists which clients support in varying degree, and which servers return in referrals and continuation references:
where most components after "ldap://" can be omitted.

scope can be "base" (the default), "one" or "sub".
attributes is a comma-separated list of attributes to retrieve.
extensions are extensions to the LDAP URL format.
As in other URLs, special characters must be escaped with %hex format.

There is a similar non-standard "ldaps:" URL scheme for LDAP over SSL.

For example, "ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com" refers to all user attributes in John Doe's entry in ldap.example.com. "ldap:///dc=example,dc=com??sub?(givenName=John)" searches for him in the default server.


The contents of the entries in a subtree is governed by a schema.

The schema defines the attribute types that directory entries can contain.
An attribute definition includes a syntax, and most non-binary values in LDAPv3 use UTF-8 string syntax. For example, a "mail" attribute might contain the value "user@example.com". A "jpegPhoto" attribute would contain photograph(s) in binary JPEG/JFIF format. A "member" attribute contains the DNs of other directory entries.
Attribute definitions also include whether the attribute is single-valued or multi-valued, how to search/compare the attribute (e.g. case-sensitive vs. case-insensitive and whether substring matching is supported), etc.

The schema defines object classes. Each entry must have an objectClass attribute, containing named classes defined in the schema. They describe what kind of object an entry represents - e.g. a person, organization or domain. They also say which attributes the entry may contain, and which ones it must contain.

The schema also includes various other information controlling directory entries.

Most schema elements have a name and a globally unique Object identifier (OID).

Server administrators can define their own schemas in addition to the standard ones. Schemas for representing individual people within organizations are termed white pages schema.


A lot of the server operation is left to the implementor or administrator to decide. Accordingly, servers may be set up to support a wide variety of scenarios.

For example, data storage in the server is not specified - the server may use flat files, databases, or just be a gateway to some other server. Access control is not standardized, though there has been work on it and there are commonly used models. Users' passwords may be stored in their entries or elsewhere. The server may refuse to perform operations when it wishes, and impose various limits.

Most parts of LDAP are extensible. Examples: One can define new operations. Controls may modify requests and responses, e.g. to request sorted search results. New search scopes and Bind methods can be defined. Attributes can have options that may modify their semantics.

Extensions should be defined so that implementations which do not recognize them can handle them gracefully, but this is not always done. Still, a lot of work has been done since LDAP was invented to improve interoperability between different implementations.

Other data models

As LDAP has gained momentum, vendors have provided it as an access protocol to other services. The implementation then recasts the data to mimic the LDAP/X.500 model, but how closely this model is followed varies. For example, there is software to access SQL databases through LDAP, even though LDAP does not readily lend itself to this. X.500 servers may support LDAP as well.

Similarly, data which were previously held in other types of data stores are sometimes moved to LDAP directories. For example, Unix user and group information can be stored in LDAP and accessed via PAM and NSS modules. LDAP is often used by other services for authentication.


Beware: The LDAP terminology one can encounter is quite a mess. Some of this is due to misunderstandings, other examples are due to its historical origins, others arise when used with non-X.500 services that use different terminology.

For example, "LDAP" is sometimes used to refer to the protocol, other times to the protocol and the data. A "LDAP directory" may be the data or also the access point. An "attribute" may be the attribute type, or the contents of an attribute in a directory, or an attribute description (an attribute type with options). An "anonymous" and an "unauthenticated" Bind are different Bind methods that both produce anonymous authentication state, so both terms are being used for both variants. The "uid" attribute should hold user names rather than numeric user IDs.

Sunday, April 23, 2006

Life Keeper

What is fault resilience?
SteelEye uses the term fault-resilient to describe a computing environment where servers can failover to other servers. Specifically, the term identifies environments where other servers take over for failed servers or failed applications providing up to 99.99% availability for systems and applications. Fault Resilience differs from Fault Tolerance in that Fault Resilience provides for a certain amount of accepted downtime during the failover process - generally an average of no more than 53 minutes a year. LifeKeeper provides fault resilience for Linux environments by enabling other servers in a cluster to take over for failed servers or failed applications.

Does LifeKeeper require dedicated hot back-up servers?
No. LifeKeeper supports an active-active server configuration. This configuration eliminates the need for extra servers dedicated for hot backup and allows clients and applications to failover to other production servers in the cluster.

What kinds of applications can LifeKeeper support?
LifeKeeper is an ideal fit for mission-critical applications. LifeKeeper can support most applications running in the Linux environment, including e-mail, databases, printers, application servers and Web servers.

Do applications need to be modified for use with LifeKeeper?
No. Depending on the type of application, the location of certain data that needs to be protected, will be denoted in LifeKeeper configuration guidelines. For example, if LifeKeeper protects the Sendmail application, the e-mail accounts database and mail spool directories would be stored on a shared device.

Can LifeKeeper protect applications from a single point of failure?
Yes. LifeKeeper eliminates a single point of failure for applications by enabling applications to failover to other servers in the cluster. This functionality not only minimizes the risk of a single point of failure, but also allows Linux systems to meet the stringent availability requirements of mission-critical operations by creating a fault resilient environment.

What is the impact on users when an application fails over to another server in the cluster?
The switchover that occurs, if an event creates an interruption in a server or application's availability, is transparent to end-users. LifeKeeper migrates all applications and transfers connectivity in such a way that clients have continuous access to applications and data. However, in configurations where a very large database application fails over, users may notice a few seconds of non-connectivity.

How many systems are required in a basic LifeKeeper configuration?
The minimum number of systems in a LifeKeeper configuration is two.

How much memory is required for each system in a LifeKeeper configuration?
The minimum amount of memory required for a LifeKeeper configuration is 32 MB, but 48 MB is recommended.