OpenLDAP

OpenLDAP es una de las implementaciones de este servicio más populares en el mundo Linux.

Se trata de software libre y multiplataforma.

OpenLDAP tiene tres componentes principales:

• slapd - Es el demonio que espera peticiones.
• Bibliotecas para implementar el protocolo
• Programas clientes: ldapsearch, ldapadd, ldapdelete...

Opciones de configuración

La opción más simple es la de un servicio local, ya sea en una LAN o en un ordenador individual. Un servidor proporciona el servicio a uno o más clientes.

La siguiente opción, es la que se usa para añadir nuestro servidor a un servicio de directorio más amplio. Puede que administrado por otros.

Como se puede ver, si el servidor local no es capaz de resolver la petición, le indica al cliente que la pida a un servidor superior.

La tercera opción es la de crear duplicados del servicio de directorio.

En esta opción, el servidor maestro crea duplicados en otros servidores.

Referencia: http://www.openldap.org/doc/admin24/config.html

Backend

El servidor OpenLDAP tiene un sección frontal para controlar conexiones y el protocolo LDAP y una base de datos en segundo plano o backend que se dedica a guardar los datos.

Puesto que tiene una arquitectura modular, se pueden usar múltiples backends para ofrecer el servicio.

OpenLDAP permite por defecto 16 backends distintos. Estos se pueden clasificar en tres categorías:

• De almacenamiento de datos
• Proxy backends, que actuan como puertas de enlace con otros sistemas de almacenamiento.
• Dinámicos, los que generan los datos en el momento.

Un servidor LDAP puede dar, simultáneamente, acceso a múltiples bases de datos. En las nuevas versiones de LDAP hay como mínimo dos:

• config para la configuración
• /var/lib/ldap que es el backend de la base de datos. Suele estar en hdb

Configuración

A partir de OpenLDAP 2.3, la configuración se vuelve dinámica. Esto quiere decir que permite modificaciones con el servidor en marcha. Además, la propia configuración se almacena como un directorio LDAP y se puede administrar con las órdenes comunes del servidor.

Puesto que la configuración también es como un directorio LDAP, tiene su DIT. Es el siguiente:

El primer nodo es cn=config y tiene los ajustes de configuración global. En las otras entradas están los demás ajustes:

• cn=module Carga dinámica de módulos.
• cn=schema Contiene el schema del sistema.
• Los objetos hijos de cn=schema contienen los schemas del usuario añadidos más tarde.
• La configuración del Backend y de la base de datos, otras configuraciones de la base de datos se pueden colocar como hijos de esta. olcDatabase es el parámetro que se usa para configurar la base de datos.

Veamos el LDIF de una configuración estándar.

       # global configuration settings
       dn: cn=config
       objectClass: olcGlobal
       cn: config
       <global config settings>

       # schema definitions
       dn: cn=schema,cn=config
       objectClass: olcSchemaConfig
       cn: schema
       <system schema>

       dn: cn={X}core,cn=schema,cn=config
       objectClass: olcSchemaConfig
       cn: {X}core
       <core schema>

       # additional user-specified schema
       ...

       # backend definitions
       dn: olcBackend=<typeA>,cn=config
       objectClass: olcBackendConfig
       olcBackend: <typeA>
       <backend-specific settings>

       # database definitions
       dn: olcDatabase={X}<typeA>,cn=config
       objectClass: olcDatabaseConfig
       olcDatabase: {X}<typeA>
       <database-specific settings>

       # subsequent definitions and settings
       ...

la X indica un número. LDAP no mantiene un orden en sus entradas. Si es necesario este orden se puede forzar con esos números.

Las directivas de configuración en detalle se pueden ver en: http://www.openldap.org/doc/admin24/slapdconf2.html#Configuration%20Directives

Ejemplo de configuración

(Al final de cada fragmento de LDAIF hay una línea en blanco para indicar el final de una entrada)

dn: cn=config
objectClass: olcGlobal
cn: config
olcReferral: ldap://root.openldap.org

Este es el LDIF del nodo raíz. Las tres primeras líneas indican que es el nodo raíz. El atributo olcReferral indica dónde debe preguntar el cliente en caso de que el servidor no pueda responder su petición.

# internal schema
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema

Aquí está el schema interno del sistema. No es necesario indicar nada más porque los schemas principales están en el própio código de slapd

# include the core schema
include: file:///usr/local/etc/openldap/schema/core.ldif

Este include hace referencia al esquema core.

# global database parameters
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
olcDatabase: frontend
olcAccess: to * by * read

Aquí llega la configuración de la base de datos. La última línea es control de acceso global que permite a todos leer.

# set a rootpw for the config database so we can bind.
# deny access to everyone else.
dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
olcAccess: to * by * none

Se define con olcRootPW la contraseña del superusuario de la base de datos. La siguiente línea niega el acceso a todos menos al superusuario.

# BDB definition for example.com
dn: olcDatabase=bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: bdb
olcSuffix: "dc=example,dc=com"
olcDbDirectory: /usr/local/var/openldap-data
olcRootDN: "cn=Manager,dc=example,dc=com"
olcRootPW: secret
olcDbIndex: uid pres,eq
olcDbIndex: cn,sn,uid pres,eq,approx,sub
olcDbIndex: objectClass eq
olcAccess: to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=Admin,dc=example,dc=com" write
by * none
olcAccess: to *
by self write
by dn.base="cn=Admin,dc=example,dc=com" write
by * read

En esta parte se define un backend para example.com. Primero se especifica el sufijo para consultas y el directorio donde se guardará. A continuación se indica quien es el superusuario de esa base de datos. las siguientes líneas indican el control de acceso para esta base de datos. Para todas las entradas, el atributo userPassword puede ser escrito por la propia entrada o el administrador. Se puede usar para autentificar, pero de otra forma no es legible. Todos los demás atributos pueden ser leidos por todos y modificados por la entrada o el adminstrador.