El proyecto OpenLDAP se inició en 1998 por Kurt Zeilenga. El proyecto comenzó como un clon de la implementación LDAP de la Universidad de Míchigan, entidad donde se desarrolló originalmente el protocolo LDAP y que también actualmente trabaja en la evolución del mismo.

En abril de 2006, el proyecto OpenLDAP incorpora tres miembros principales: Howard Chu (Arquitecto jefe), Pierangelo Masarati, y Kurt Zeilenga. Hay otros importantes y activos contribuyentes incluyendo Luke Howard, Hallvard Furuseth, Quanah Gibson-Mount, y Gavin Henry.

Históricamente la arquitectura del servidor OpenLDAP (slapd, Standalone LDAP Daemon) fue dividida entre una sección frontal que maneja las conexiones de redes y el procesamiento del protocolo, y una base de datos dorsal o de segundo plano (backend) que trata únicamente con el almacenamiento de datos. La arquitectura es modular y una variedad de backends está disponible para interactuar con otras tecnologías, no solo bases de datos tradicionales.

Nota: En versiones antiguas (1.x), los términos "backend" y "database (base de datos)" podían intercambiarse. Para ser precisos, un "backend" es una clase de interfaz de almacenamiento, y una base de datos es una instancia de un backend. El servidor slapd puede utilizar arbitrariamente varios backends en una sola vez, y puede tener arbitrariamente muchas instancias de cada backend (por ejemplo varias bases de datos) activas por vez.

Actualmente 16 diferentes backends son proporcionados en la distribución de OpenLDAP, y varios proporcionados por terceros son conocidos para mantener otros backends de manera independiente. Los backends estándar están organizados de manera imprecisa en tres categorías:

• Backends de almacenamiento de datos (Data Storage backends) - estos realmente almacenan información
  • back-bdb: el primer backend transaccional para OpenLDAP, construido para BerkeleyDB
  • back-hdb: una variante de back-bdb que es totalmente jerárquica y soporta renombrado de subárboles
  • back-ldif: construido en archivos LDIF de texto plano
  • back-ndb: un backend transaccional construido para el motor de clúster NDB de MySQL
• Proxy backends - actúan como puertas de enlace a otros sistemas de almacenamiento de datos
  • back-ldap: proxy simple a otros servidores LDAP
  • back-meta: proxy con características de meta-directorio
  • back-passwd: usa un sistema basado en Unix de datos passwd y group
  • back-relay: internamente redirige a otros backends de servidores slapd
  • back-sql: establece conexiones a bases de datos SQL
• Backends dinámicos - estos generan datos sobre la marcha
  • back-config: configuración del servidor slapd vía LDAP
  • back-dnssrv: localiza servidores LDAP vía DNS
  • back-monitor: estadísticas de slapd vía LDAP
  • back-null: un backend nulo, análogo a /dev/null en Unix
  • back-perl: invoca arbitrariamente módulos de perl en respuesta a peticiones LDAP
  • back-shell: invoca scripts de shell para peticiones LDAP
  • back-sock: redirige peticiones LDAP sobre IPC a demonios de manera arbitraria

Algunos backends disponibles en lanzamientos antiguos de OpenLDAP han sido retirados, los más notorios fueron el back-ldbm que fue heredado del código original de UMich, y back-tcl que era similar a back-perl y back-shell.

En la práctica, los backends como -perl, -shell, and -sock permiten interconexión con cualquier lenguaje de programación, por lo cual proveen ilimitadas capacidades para personalización y expansión. En efecto el servidor slapd se convierte en un motor RPC con una interfaz de programación de aplicaciones (API) compacta, bien definida y ubícua.

Generalmente una petición LDAP es recibida por el frontend, decodificada y luego transferida a un backend para procesamiento. Cuando el backend completa la petición, devuelve un resultado al frontend, quien luego envía el resultado al cliente LDAP. Un overlay es una pieza de código que puede ser insertada entre el frontend y el backend. Es entonces capaz de interceptar peticiones y lanzar otras acciones en ellas antes de que el backend las reciba, y puede también actuar sobre los resultados del backend antes de que estos alcancen el frontend. Overlays tiene acceso completo a las interfaces de programación (APIs) internas del servidor slapd, y por tanto pueden invocar cualquier llamada que podrían realizar el frontend u otros backends. Múltiples overlays pueden ser usados a la vez, formando una pila de módulos entre el frontend y el backend.

Los overlays proveen un medio simple para incrementar las funcionalidades de una base de datos sin requerir que un completo backend nuevo puede ser escrito, y permite añadir nuevas funcionalidades de manera compacta, fácilmente depurable y módulos mantenibles. Desde la introducción de la característica de overlay en OpenLDAP 2.2 muchos nuevos overlays han sido contribuidos por la comunidad OpenLDAP.

Actualmente existen 20 overlays en el núcleo de la distribución OpenLDAP, con otros 10 overlays en la sección de contribuciones de los usuarios, y más aún esperan aprobación para ser añadidos.

• Entre los overlays incluidos en el núcleo se incluyen:
  • accesslog: servidor de registro de actividades en otra base de datos LDAP, para registro de actividades accesible por LDAP
  • auditlog: servidor de registro de actividades en un archivo de texto plano
  • chain: intercepta referencias y las encadena; el código es parte de back-ldap
  • collect: implementa atributos de estilo X.500 (también conocido Netscape Class Of Service)
  • constraint: restringe los valores aceptables para atributos particulares
  • dds: dynamic data service - entradas de corto tiempo de vida, auto expirables
  • deref: devuelve información acerca de entradas referenciadas en resultados de búsqueda dados
  • dyngroup: soporte simple de grupos dinámicos
  • dynlist: soporte de grupos dinámicos más sofisticado y otras características
  • memberof: soporte de memberOf y atributos similares
  • pcache: almacenamiento en caché de resultados de búsqueda, principalmente para mejorar desempeño para servidor que actúan como proxyes.
  • ppolicy: política de claves LDAP - calidad de claves, expiración, etc.
  • refint: integridad referencial
  • retcode: establece códigos de retorno predefinidos para varios operadores, usado para depuración de clientes
  • rwm: módulo de reescritura para varias alteraciones de datos LDAP
  • seqmod: serializa escritura para entradas individuales
  • syncprov: Proveedor para un consumidor syncrepl, implementa el lado maestro en un esquema de replicación
  • translucent: paso semi-transparente, para aumentar datos lógicamente en un servidor utilizado como proxy
  • unique: para forzar unicidad de valores de atributos en un árbol
  • valsort: mantiene varios ordenamientos para valores de un atributo

• Los overlays contribuidos incluyen:
  • addpartial: reciben peticiones de adición (Add) y los convierte en modificaciones (Modifies) si la entrada objetivo ya existe.
  • allop: devuelve todos los atributos operacionales, para clientes que no conocen cómo efectuar las peticiones
  • autogroup: grupos estáticos manejados dinámicamente
  • denyop: rechaza de manera arbitraria peticiones configuradas
  • lastmod: mantiene la marca de tiempo del último cambio en un árbol
  • nops: filtra modificaciones redundantes
  • nssov: responde peticiones NSS directamente en slapd, reemplaza a nss-ldap
  • proxyOld: soporta una codificación obsoleta de ProxyAuthz usada por Sun y otros
  • smbk5pwd: mantiene claves en Samba y Kerberos
  • trace: lleva un registro de peticiones y respuestas LDAP

OpenLDAP también soporta SLAPI, la arquitectura de extensión usada por Sun y Netscape/Fedora/RedHat. En versiones actuales, el framework SLAPI es implementada dentro del overlay de slapd. Mientras varias extensiones escritos por Sun/Netscape/Fedora/RedHat son compatibles con OpenLDAP, muy pocos miembros de la comunidad OpenLDAP usan SLAPI.

Algunos desarrollos son creados específicamente para facilitar la gestión de sistemas de directorio como OpenLDAP para usuarios que buscan una interfaz intuitiva, además de añadir otras herramientas y características.

Los principales lanzamientos funcionales de OpenLDAP incluyen:

• OpenLDAP versión 1 fue una limpieza general de la última versión del proyecto de la Universidad de Míchigan (lanzamiento 3.3), y consolidación de cambios adicionales.
• OpenLDAP versión 2.0, lanzada en agosto de 2000, incluyó mejoras importantes incluyendo soporte para LDAP versión 3 (LDAPv3),soporte para Internet Protocol versión 6 (IPv6), y numerosas otras mejoras.
• OpenLDAP versión 2.1, lanzada en junio de 2002, incluyó en backend la base de datos transaccional basada en Berkeley Database o BDB, soporte para Simple Authentication and Security Layer (SASL), y backends experimentales Meta, Monitor, and Virtual.
• OpenLDAP versión 2.2, lanzada en diciembre de 2003, incluyó el motor de "sincronización" LDAP "sync" con soporte de replicación (syncrepl), la interfaz de presentación, y numerosas mejoras funcionales a nivel de base de datos y relacionadas con RFC.
• OpenLDAP versión 2.3, lanzada en junio de 2005, incluyó Configuration Backend (para configuración dinámica), interfaces adicionales incluyendo y numerosas mejoras adicionales..
• OpenLDAP versión 2.4, lanzada en octubre de 2007, introdujo la replicación en N-vías MultiMaster, Stand-by master, y la posibilidad de eliminar y modificar elementos del esquema en tiempo de ejecución, además de más modificaciones.

• OpenLDAP Website
• The OpenLDAP Project
• The OpenLDAP Foundation
• OpenLDAP Software
• OpenLDAP Public License
• Using libldap, tutorial en inglés de la API cliente de OpenLDAP
• An OpenLDAP Update Archivado el 10 de agosto de 2009 en Wayback Machine. artículo en inglés de Marty Heyman de septiembre de 2007
• Ldap linux manual para configurar y utilizar un Servidor de directorio LDAP (Protocolo Ligero de Acceso a Directorios) en Linux