Servicios de directorio

  • Ángel Elbaz Sanz

  • Antoni Martínez-Ballesté

  • Jordi Castellà-Roca

PID_00287479
Primera edición: febrero 2022
© de esta edición, Fundació Universitat Oberta de Catalunya (FUOC)
Av. Tibidabo, 39-43, 08035 Barcelona
Autoría: Ángel Elbaz Sanz, Antoni Martínez-Ballesté, Jordi Castellà-Roca
Producción: FUOC
Todos los derechos reservados
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea este eléctrico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita del titular de los derechos.

Introducción

Uno de los propósitos de los sistemas informáticos es el de guardar información. Los sistemas gestores de bases de datos ofrecen herramientas para guardar ingentes cantidades de información. Esta información puede llegar a tener estructuras realmente complejas, con multitud de entidades y relaciones.
Durante la implantación de los sistemas informáticos, ha sido necesario desarrollar herramientas centradas en gestionar un tipo muy concreto de información. Un ejemplo clásico es la información referente al sistema de ficheros de una unidad de almacenamiento. Se trata de un concepto muy específico con la información que hay que guardar claramente definida. Ahora bien, es preciso que la implementación sea robusta y escalable, puesto que un sistema de ficheros puede fácilmente llegar a albergar millones.
Los directorios son un tipo específico de bases de datos con un propósito también específico: almacenar la información sobre un objeto (individuo, recurso de red, documento). Su papel es clave en cualquier organización que quiera tener la información sobre sus empleados, usuarios de red, etc., catalogada y accesible desde multitud de aplicaciones. Además, el uso de un servicio de directorio facilita la gestión de la identidad de los usuarios de los sistemas de información en una organización.
En este módulo estudiaremos los conceptos básicos de los directorios, su diseño y su implantación. Nos centramos en LDAP (lightweight directory access protocol), dado que es el estándar más usado desde hace ya algunos años. Estudiaremos su concepto, utilidad, diseño e implantación.

Objetivos

Los objetivos que el estudiante habrá alcanzado al finalizar este módulo son los siguientes:

  1. Comprender el concepto y utilidad de un servicio de directorio.

  2. Comprender el concepto de espacio de nombres.

  3. Conocer las operaciones que ofrece un servicio de directorio como LDAP.

  4. Diseñar un espacio de nombres para un servicio de directorio.

  5. Diseñar el esquema de un servicio de directorio, manejando los conceptos de atributo y clase.

  6. Comprender qué aspectos inciden en la seguridad, la eficiencia y la disponibilidad en un servicio de directorio.

  7. Conocer implantaciones de servicios de directorio.

1.Concepto y uso de los directorios

La idea de directorio está relacionada con la información. Desde los inicios de los sistemas de ficheros, hasta llegar a los primeros sistemas operativos para ordenadores PC, la palabra directorio se ha asociado al esquema con el que los distintos archivos están organizados en las unidades de almacenamiento. En inglés, telephone directory es el nombre con el que se conoce a la guía telefónica: la relación de abonados al servicio telefónico, sus números de abonado y opcionalmente la dirección física de su domicilio. Sea como fuere, el concepto de directorio está estrechamente ligado a la organización de datos.
Un directorio es una estructura jerárquica que organiza y almacena datos acerca de elementos. Es un tipo concreto de base de datos.
Así pues, los ficheros, pese a estar realmente guardados en el soporte sin organización aparente, se organizan de forma lógica en directorios y subdirectorios. En un directorio de sistema informático en red, la información que se guarda tiene que ver con los recursos del sistema (servidores, impresoras, etc.) y con sus usuarios. Además, es preciso que el sistema cuente con un servidor para poder consultar la información, almacenarla o simplemente diseñarla. Esta información, como veremos más adelante, puede estar almacenada de forma distribuida o replicada. En consecuencia, es necesario contar con un servicio de directorio.
Un servicio de directorio es una plataforma que proporciona métodos para gestionar y almacenar los datos que contiene el directorio.
Un servicio de directorio permite la búsqueda de valores a partir de un determinado nombre (o identificador) de forma similar a lo que hace un diccionario. Así como un vocablo tiene distintas acepciones, hay distintos vocablos apuntando a un mismo significado, hay palabras derivadas, familias de palabras, etc., es decir, los objetos que almacena un directorio pueden estar relacionados de múltiples formas.
Ejemplo de un servicio de directorio
Supongamos un servicio que, dentro de un entorno de red local, devuelve una dirección IP y una serie de características a partir de un nombre de equipo. También podemos considerar que hay nombres que definen a grupos de equipos sobre los cuales aplicar determinados permisos. Pues bien, una aplicación que guarde y permita manejar esta información sería un servicio de directorio. Cualquier aplicación podría obtener información sobre los equipos y grupos, solo sería necesario acceder al servicio de directorio.
En la figura siguiente, hay un servicio de directorio que controla los equipos y recursos de una red. Cuando Servidor1 recibe una petición desde equipodepepe, el recurso solicita al servicio de directorio si este equipo tiene permiso para acceder al recurso. Dentro del servicio de directorio, se ha creado un espacio de nombres, es decir, una concreción de cuál es el identificador de cada recurso de la red. Más adelante estudiaremos a fondo este concepto.
Figura 1. Ejemplo de consulta a un servicio de directorio para acceso a recursos
Figura 1. Ejemplo de consulta a un servicio de directorio para acceso a recursos
La idea de un servicio de directorio es tan reciente (o tan antiguo, según como se mire) como el inicio de los sistemas basados en red. En 1988, la ITU (1) y la ISO (2) se unieron para llevar a cabo el desarrollo de una serie de estándares sobre servicios de directorio, conocido como X.500, o DAP (directory access protocol). Este sistema era complejo y además implementaba múltiples herramientas que muchos clientes acabaron no usando nunca. Esto no propiciaba un amplio uso de X.500, con lo que se empezó a trabajar en una versión «ligera»: el LDAP (lightweigth directory access protocol), cuyo primer esbozo se publicó en el RFC 1487. Esta primera versión, diseñada por personal de la Universidad de Michigan, se utilizaba como pasarela. LDAP conectaba clientes de directorio con servicios X.500. Dada la aceptación de LDAP, se trabajó en que este sistema fuera realmente el servicio de directorio y no una mera pasarela. Así pues, LDAP se convirtió en un estándar de facto, sobre todo porque supuso la base para distintos productos de servicio de directorio que gozan de gran popularidad. En el decurso de este módulo, haremos referencia en general a LDAP. La versión actual del protocolo se encuentra recogida en el RFC 4511.
Aunque el concepto de directorio se relacione con datos, bien cierto es que hay varias diferencias entre un servicio de directorio y una base de datos:

  • En los directorios se realizan muchas más lecturas de datos que escrituras.

  • Los directorios pueden modificar más fácilmente el diseño de las «entidades» que albergan. En cambio, en una base de datos cambiar el diseño de esta a posteriori puede ser más complejo.

  • Los datos de los directorios suelen estar distribuidos y replicados con mayor frecuencia que en bases de datos.

  • Los directorios permiten, en general, consultas simples, y no consultas que requieran la fusión de datos provenientes de varias tablas (consultas join de las bases de datos).

1.1.Ejemplos y tipos de directorios

Antes de pasar a estudiar conceptos concretos sobre los servicios de directorio, veremos una panorámica de distintos tipos de directorios en función de su propósito o implantación.
Un tipo sencillo de directorios es el que está incluido en aplicaciones de software, como por ejemplo las libretas de direcciones. Una aplicación informática de correo electrónico puede incluir un directorio donde cada entrada es un «contacto», y entre la información almacenada se encuentra, claro está, la dirección de correo electrónico del contacto.
Un paso más allá sería que esta aplicación de libreta de direcciones funcionara como una aplicación informática independiente o que quizás fuera un elemento más del sistema operativo. En este caso, sería preciso establecer un estándar de intercambio de información para que los demás programas pudieran hacer uso de esta libreta de direcciones.
Esta aplicación podría ser una aplicación de red ejecutándose en un servidor. De este modo, la información de los contactos estaría disponible para todos los equipos clientes que consultan al servidor. En este caso, sería necesario establecer un protocolo de comunicaciones a nivel de aplicación para poder realizar distintas operaciones:

  • Consultas sobre la información de un contacto

  • Mensaje de error en caso de que no se encontrara el contacto

  • Opcionalmente, un protocolo de identificación del usuario

  • Operaciones de alta, baja y modificación de contactos solo ejecutables por un usuario con permisos de administrador, etc.

Los directorios de sistemas operativos en red almacenan datos de recursos de una red. Algunos ejemplos son el Active Directory, de Microsoft, o el eDirectory, de NetIQ (antiguamente propiedad de Novell). Así como una libreta de direcciones puede estar integrada en una aplicación, ejecutándose en un sistema, o funcionando en un servidor, está claro que será una aplicación concreta: guardar información acerca de contactos. En el caso de los directorios de sistemas operativos en red, su uso es más amplio.
Ejemplo: sistema de nombres para internet
Otro ejemplo de directorio de propósito específico es el sistema de nombres para internet, DNS. (3) El acceso a servicios basados en internet se realiza mediante conexiones o envío de datagramas hacia una determinada dirección IP. El sistema DNS resuelve, a partir de un nombre, cuál es la dirección IP del recurso. La particularidad de este sistema es que la información se encuentra distribuida por toda la red internet. Por ejemplo, en función del TLD (4) (es decir, si el nombre de dominio se corresponde a un .com, a un .es, etc.) los datos estarán en uno u otro servidor. Los datos correspondientes a los nombres locales, en general nombres que identifican servicios o máquinas dentro de un determinado dominio, se hallan en servidores de nombres autorizados. Finalmente, existe la replicación de datos, y uno de los ejemplos son los servidores de nombre raíz, aquellos que contienen información acerca de dónde se hallan los servidores de TLD. Estos, a su vez, también están replicados por temas de eficiencia.
Así como DNS se puede ver como un servicio de directorio un tanto específico, los hay de propósito general. Este es el caso del servicio LDAP. Aunque en ciertos casos su uso se remite a tener información sobre los usuarios de una serie de servicios en red (permitiendo, por ejemplo, el acceso a múltiples servicios mediante un único usuario y contraseña), LDAP permite definir soluciones para un amplio espectro de escenarios.
1.1.1.Directorios y su uso en seguridad y autenticación
Una aplicación interesante de los servicios de directorio es la seguridad. Por una parte, un servicio de directorio puede utilizarse, como se ha apuntado anteriormente, para gestionar la información de los usuarios de varios servicios de red. En concreto, se podría pensar en un servicio de directorio para una organización que albergue, para cada usuario de un sistema, la siguiente información:

  • nombre y apellidos

  • departamento de la organización

  • identificador de usuario

  • contraseña

  • fecha del último cambio de contraseña

En la organización se dispondría de varios servicios en red: un correo electrónico, un calendario, un sistema de compartición de documentos y una aplicación web de gestión de nóminas. Mediante un único identificador de usuario y su correspondiente contraseña, los usuarios de la organización podrían autenticarse ante cualquiera de los servicios. En realidad, el servidor de correo electrónico hace una consulta al servicio de directorio para comprobar que exista el identificador de usuario y que, evidentemente, la contraseña introducida sea la correcta.
Si en cualquier momento el usuario desea cambiar su contraseña, debería realizar esta operación mediante el servicio de directorio. A su vez, este servicio podría avisar, por ejemplo, mediante un correo electrónico, de la próxima caducidad de la contraseña de un usuario. O bien, si un usuario tiene la contraseña caducada, el propio servidor de correo electrónico mostraría un aviso de imposibilidad de autenticar al usuario debido a la caducidad de la contraseña.
Finalmente, en lo referente a la aplicación web de gestión de nóminas, cuando un usuario acceda, se consultará al servicio de directorio del departamento al cual pertenece. Si el usuario no pertenece al departamento, por ejemplo, de «gestión», solo podrá consultar sus nóminas. En caso contrario, podrá realizar consultas sobre sus nóminas y las de los otros trabajadores, así como crear y calcular nuevas nóminas.
En la figura siguiente se muestra este ejemplo de uso del servicio de directorio, en concreto, la autenticación al servidor de correo de la organización.
Figura 2. Uso del servicio de directorio como apoyo en la autenticación de un usuario ante un servicio de correo electrónico
Figura 2. Uso del servicio de directorio como apoyo en la autenticación de un usuario ante un servicio de correo electrónico
Otro de los sistemas que se basan en un directorio es la infraestructura de clave pública (public key infrastructure, PKI). Estas plataformas realizan no solo la distribución de certificados y claves a clientes y servidores, sino que además se encargan de otras funciones, y la revocación de claves y certificados es una de las más importantes.
Los directorios ayudan a resolver dos de los problemas que suele acarrear la implantación de una PKI:
1) El primero de ellos es la gestión de ciclo de vida de un certificado, es decir, cómo se crean, mantienen y destruyen los certificados.
2) El segundo problema hace referencia a la localización de certificados. Es decir, cómo hallar confiablemente las claves públicas y certificados necesarios para comunicarse con servicios e individuos.
Usar un directorio puede claramente dar solución a estos problemas. El servicio de directorio actúa de punto central de administración durante el ciclo de vida de la PKI. La creación de certificados y claves se realiza mediante el mismo servicio de directorio. Cuando es preciso revocar un certificado, el directorio proporciona la herramienta adecuada: el directorio ofrece información sobre la lista de certificados revocados (y que ya no son válidos). Las propiedades de redundancia y distribución de la información son igualmente necesarias en entornos de PKI, y son claramente proporcionadas por los servicios de directorio.
Una vez vistos distintos ejemplos de servicios de directorio y algunas de sus características, nos centraremos en la identificación de objetos y las operaciones básicas que utilizan los clientes del servicio de directorios.

1.2.Espacio de nombres

En los servicios de directorio, cada objeto está identificado mediante un nombre. Podríamos definir el espacio de nombres de un directorio como el conjunto de aquellos identificadores que se utilizan, o se pueden utilizar potencialmente, para identificar de forma unívoca los objetos del directorio.
El identificador de objeto debe ser un nombre único dentro del servicio de directorio.
Además de identificar objetos, los identificadores también pueden identificar grupos de objetos, con lo cual se puede diseñar una estructura jerárquica.
El sistema LDAP, con sus distintas versiones, se ha convertido en un estándar genérico de servicio de directorio. Tanto es así que muchos de los productos ampliamente usados para implantar servicios de directorio se basan en LDAP. Por este motivo, ahora nos centraremos en cómo es el espacio de nombres que se define en LDAP. Este sistema hereda muchas características de los sistemas X.500.
El sistema de nombres que usa LDAP permite la organización de los objetos de forma jerárquica. A continuación, presentaremos el espacio de nombres de LDAP.
Ejemplo de directorio LDAP
En la figura siguiente se puede observar un ejemplo de directorio LDAP.
Figura 3. Ejemplo de espacio de nombres de un directorio basado en LDAP
Figura 3. Ejemplo de espacio de nombres de un directorio basado en LDAP
En esta organización (empresa.com) hay definidos dos grupos de objetos: los usuarios y los servidores. Los usuarios se dividen en departamentos. Como veremos más adelante, LDAP y otras implementaciones derivadas permiten la agrupación de elementos y crear una jerarquía. LDAP no fija ninguna jerarquía ni ningún número determinado de niveles: el espacio de nombres permite dar flexibilidad para adaptarse a multitud de usuarios.
Cada objeto se plasma como una entrada de directorio. En el ejemplo hay un total de ocho entradas. Cada entrada tiene un nombre distinguished name (DN). Por ejemplo, la organización tiene como DN dc=empresa, dc=com.
Cada entrada de directorio está compuesta por una serie de atributos, cada uno de ellos describe varios aspectos del objeto que la entrada identifica. En el ejemplo se define un usuario. Este objeto podría tener los atributos descritos en la tabla siguiente.
Tabla 1. Ejemplo de una entrada LDAP

Atributo

Valor

objectclass

person

cn

José María López García

Pepe López García

sn

López García

telephoneNumber

1789

mail

josem.lopez@empresa.com

jpegPhoto

nU6KNyVIYS817zVdf5YKF1FrNb...
La definición de qué atributos forman parte del directorio se conoce como el esquema del directorio. A continuación, se explica el significado de los anteriores atributos:

  • objectclass. Especifica a qué clase pertenece el objeto.

  • Common name (cn). Nombre del usuario, puede tener más de un valor. En este caso, se considera nombre del usuario tanto José María como Pepe.

  • Surname (sn). Es el apellido del usuario. Puede ser útil para poder ordenar alfabéticamente por apellido.

  • telephoneNumber. Como su nombre indica, sirve para almacenar el número de teléfono del usuario. En este caso, se trata de una extensión de centralita.

  • mail. Almacena la dirección de correo electrónico.

  • jpegPhoto. Contiene una pequeña imagen del usuario.

En el ejemplo de la figura anterior, se utilizan además los atributos domain component (dc) y organization unit (ou).
En LDAP cada objeto se identifica mediante un nombre, el DN (distinguished name), formado por varios atributos y sus valores.
En el ejemplo de la figura anterior, podríamos decir que hay un usuario con DN uid=7781287-G, ou=Direccion, ou=Usuarios, dc=empresa, dc=com. Un atributo concreto, por ejemplo, uid=77781287-G, se conoce como RDN (relative distinguished name).
Por norma, el valor de RDN para cada nivel debe ser único. Por lo tanto, no podría haber dos usuarios con RDN uid=7781287-G situados en el grupo Direccion. Lo que sí estaría permitido es la existencia de un usuario, también con RDN uid=7781287-G, pero que perteneciera al grupo de Ventas.
Para construir el DN se usa toda la cadena de RDN desde la hoja del árbol hasta la raíz. Una variante del RDN se da cuando, en lugar de usar un único atributo como RDN, se usan varios atributos de la entrada. Así pues, es posible tener dos entradas con el RDN cn=Servidor web, siempre y cuando se use otro atributo, por ejemplo, description, para diferenciar entre las dos entradas. En este caso, se trata de un RDN multivalor (en inglés, multivalued), de modo que el objeto DN cn=Servidor web+description=Web tienda, ou=Servidores, dc=empresa, dc=com es distinto al objeto DN cn=Servidor web+description=Web nominas, ou=Servidores, dc=empresa, dc=com. Aunque sea posible el uso de varios atributos de una entrada de directorio a fin de identificar una entrada, se recomienda que solo se use un atributo de cada entrada por motivos básicamente de eficiencia.

1.3.Operaciones de cliente

Los directorios no tendrían sentido sin herramientas que permitieran su consulta. Por una parte, existen herramientas que pueden conectar con el servicio de directorio para poder hacer consultas sobre los usuarios y recursos. Por otra parte, hay servicios que consultan al directorio con distintos fines, como, por ejemplo, validar un usuario o comprobar los permisos de acceso a un servicio. Además, es necesario disponer de herramientas para modificar la información que contiene el directorio. En este subapartado definimos las operaciones más frecuentes a nivel de interacción de un cliente con un servicio de directorio.
1.3.1.Operaciones de interrogación
Tal y como su nombre indica, este tipo de operaciones permiten al cliente buscar información. En concreto, se definen dos operaciones básicas: la comparación y la búsqueda. La comparación se usa para comprobar si una entrada en particular contiene un valor concreto para un atributo. El servidor responderá cierto o falso en función del resultado de esta comparación. La comparación tiene un uso en casos muy limitados. En cambio, la operación de búsqueda es mucho más potente y permite, en el fondo, realizar también tareas de comparación. La operación de búsqueda es una herramienta potente de interrogación a servidores de directorio.
La operación de búsqueda (search) permite buscar en el directorio y obtener información de las entradas.
Esta operación dispone de hasta ocho parámetros, que se describen a continuación:
1) Base. A partir de qué entrada u objeto se quiere empezar a hacer la búsqueda.
2) Scope. Permite definir el ámbito de la búsqueda, los valores posibles son los siguientes:

  • Onelevel: permite buscar solo en el nivel siguiente al definido en el parámetro base;

  • Sub: se utiliza para buscar en todo el subárbol, es decir, desde la base hasta las hojas;

  • Base: se usa para buscar solo en la propia base, con el objetivo de obtener información de esta.

3) Alias deferencing options. LDAP permite la definición de alias, mediante los cuales se pueden enlazar entradas del directorio (una es el alias y la otra el objeto original).
4) Size limit. Este parámetro indica al servidor el número máximo de entradas halladas con éxito que se quiere obtener.
5) Time limit. Especifica el tiempo máximo en segundos durante el cual se puede ejecutar la búsqueda. Si el valor es cero, significa que no hay tiempo límite establecido.
6) Attributes-only. Permite especificar al servidor de directorio que devuelva únicamente cuáles son los atributos que contienen las entradas encontradas, y no sus valores.
7) List of attributes to return. Es la lista de los atributos que se quiere obtener. Si no se especifican, se entiende que se quieren obtener todos los atributos.
8) Search filter. El último de los parámetros que se definen para la operación de búsqueda de LDAP es el search filter. Es una expresión que describe el tipo de entradas que se quiere obtener. Sin pretender ser exhaustivos, a continuación, mostramos algunos ejemplos de filtros de búsqueda, juntamente con su significado:

  • (sn=prados). Este criterio de búsqueda significa que devuelva las entradas con el atributo sn (apellido) con el valor prados.

  • (sn=mar*). En este ejemplo el asterisco indica que el criterio es que el apellido empiece por mar, es decir: Márquez, Martín, Martínez, etc. El asterisco permitiría buscar los apellidos que terminen con ez, (sn=*ez).

  • (sn~=fernandez). En este caso, se retornarían apellidos parecidos a Fernández (Hernández, Ferrandiz, etc.).

  • (age>=18). Este filtro retornaría los usuarios mayores de edad. Se debe tener en cuenta que (age<18) no es posible. Siempre debe haber un igual en la comparación para los filtros LDAP. En este caso, podríamos usar una negación. Los operadores >= y <= se pueden usar también en cadenas de caracteres (por ejemplo, apellidos), en cuyo caso se usará un orden lexicográfico.

  • (jpegPhoto=*). Devuelve todas las entradas que incluyen una imagen JPEG.

También pueden construirse filtros compuestos mediante los operadores lógicos & (and) y | (or).
Ejemplo
Con la expresión (&(objectClass=person)(|(givenName=Pedro)((age<=50)))) se obtienen las entradas de clase persona cuyo nombre de pila sea Pedro y sea mayor de cincuenta años.
Las implementaciones de cliente LDAP nos ofrecen una herramienta de búsqueda. La herramienta puede tener una interfaz gráfica de usuario, en cuyo caso dispondremos de cuadros de diálogo para introducir los anteriores parámetros de búsqueda, o bien dispondremos de asistentes que nos ayudarán a su creación. La herramienta puede ser mediante la línea de comandos, como ldapsearch.
Ejemplo: uso de ldapsearch
ldapsearch –h ldap.ejemplo.com –s sub –b «ou=ingenieros» «(cn~=Juan Prados)»
En este caso se busca en el servidor <ldap.ejemplo.com>, dentro del apartado de ingenieros, la entrada correspondiente a un tal Juan Prados. La herramienta ldapsearch ha realizado una consulta al servicio de directorio que no ha precisado de una conexión autenticada o, lo que es lo mismo, ha usado una conexión anónima.
1.3.2.Operaciones de actualización
LDAP dispone de cuatro operaciones de actualización de datos: añadir, borrar, modificar y renombrar o mover.
1) La operación de añadir (add) permite crear una nueva entrada e introducir sus datos. Como parámetros de la operación, está el DN para la nueva entrada (que servirá, evidentemente, para situar la entrada dentro del árbol) y la lista de tributos con sus valores. Esta lista de valores debe coincidir con el esquema del directorio, es decir, con el modelo de datos en cuanto a atributos se refiere, que estudiaremos más adelante.
2) La operación de borrar (delete) elimina una entrada del directorio. Solamente precisa del DN de la entrada que se quiere eliminar. Es importante que la entrada no tenga hijos en el árbol para poder eliminarla.
3) La operación de modificar (modify) permite cambiar valores de atributos de una entrada, añadirlos o bien borrarlos.
4) Finalmente, una operación más compleja a la vez que potente es la de renombrar. Esta operación (rename) permite cambiar el DN de las entradas. Así pues, en el fondo, permite también mover la entrada de una ubicación a otra del árbol. Tiene cuatro parámetros:

  • El DN de la entrada que se va a renombrar o mover.

  • El nuevo RDN que tendrá la entrada.

  • El DN del que será el nuevo padre de la entrada (el parámetro es opcional si se emplea usando un DN distinto al del padre actual de la entrada, se realizará un movimiento de la entrada).

  • Finalmente, un indicador para borrar el antiguo RDN. Si no se borra el antiguo RDN, el nuevo RDN de la entrada se añade como atributo de la entrada.

1.3.3.Operaciones de autenticación
La conexión a un directorio no está exenta de las implicaciones en la seguridad del propio servicio de directorio. Por ejemplo, puede ser que la consulta de información sea pública para cualquier usuario, mientras que la modificación sea solo posible para ciertos usuarios con rol de administradores del servicio de directorio. Por otra parte, si la implementación del directorio guarda datos sensibles, como por ejemplo contraseñas sin cifrar (nada recomendable), se deberán tomar precauciones especiales para garantizar la seguridad de los datos. Para realizar una conexión (operación bind), se especifica el DN de quien realiza la conexión. Se puede usar una contraseña para autenticación, así como distintos métodos de seguridad.
1.3.4.Acceso desde otras aplicaciones
Otra forma en la que se encuentra disponible LDAP es como interfaz para implementar programas (API). De este modo, por ejemplo, en lenguaje «C» es posible usar funciones contra un servicio de directorio LDAP, como ldap_search(), ldap_bind(), ldap_add(), etc.
También existen interfaces para poder acceder a servicios LDAP desde C#, C++ o PHP.
En lenguaje Java, el JNDI (Java naming and directory interface) proporciona herramientas para usar servicios de directorio.
El siguiente ejemplo muestra una conexión anónima a un servicio LDAP mediante C#.
LdapConnection ldapConn= new LdapConnection();


ldapConn.Connect ("ldap.example.com",389);


ldapConn.Bind (null, null);
Y este ejemplo hace lo mismo, pero esta vez en PHP.
<?php

 $ldapconn = ldap_connect("ldap.example.com") or die("Unable to connect.");

 if ($ldapconn) {
 $ldapbind = ldap_bind($ldapconn);
 }

?>
Finalmente, este ejemplo ilustra la conexión a un directorio LDAP mediante JNDI.
DirContext ctx = new InitialDirContext(env);


env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");


env.put(Context.PROVIDER_URL, "ldap://direction:389");


env.put(Context.SECURITY_AUTHENTICATION,"simple");


env.put(Context.SECURITY_PRINCIPAL,"cn=user");


env.put(Context.SECURITY_CREDENTIALS,"password");

2.Diseño del directorio

El espacio de nombres es un elemento estrechamente ligado con la organización de los objetos que incluye el directorio. Tal y como hemos visto, en LDAP los objetos se identifican mediante una serie de valores específicos de atributos, en principio uno para cada nivel del espacio de nombres.
Así pues, se puede pensar que debería haber cierta relación entre la organización de la institución y el diseño de su directorio. Asimismo, será necesario tener claro qué elementos conviene almacenar para cada entrada, es decir, cuáles serán los atributos que definirán los objetos del directorio. En este apartado, hacemos énfasis en los aspectos de diseño del directorio, tanto en el espacio de nombres como en el esquema. También realizamos algunas reflexiones en torno a la seguridad, robustez y eficiencia del sistema.

2.1.Diseño del espacio de nombres

Para el diseño del espacio de nombres se pueden tener en cuenta tres elementos: la elección del sufijo, la estructura o complejidad del directorio y la identificación de objetos dentro del directorio.
2.1.1.Elección del sufijo
La organización para la cual se diseña el directorio puede tener un ámbito local, o bien puede formar parte de una organización mayor que también cuente con un directorio. Sea como fuere, lo importante es que el sufijo (el nombre de la parte «raíz» del árbol del directorio) identifique unívocamente la organización. Hay tres alternativas válidas para elegir el sufijo:
1) La primera de ellas consiste en cumplir la recomendación de la RFC 2247. En ella se especifica que es conveniente mapear el DN del directorio con el nombre DNS que la organización tenga asignado (o pretenda tener asignado algún día).
Ejemplo
Si la organización tiene por ejemplo una página web con el dominio <www.empresa-ejemplar.com>, sería conveniente que el DN del dominio, el sufijo, fuera DN dc=empresa-ejemplar, dc=com.
2) Una segunda alternativa, ligeramente distinta a la primera, consiste en usar todo el nombre de dominio, esta vez usando el atributo o (de organization). En este caso DN o=empresa-ejemplar.com.
3) Finalmente, la tercera alternativa tiene que ver con la localización geográfica de la empresa, tal y como se formulaba en las recomendaciones para X.500.
Estas nomenclaturas se usan, por ejemplo, para identificar organismos y entidades dentro de los certificados electrónicos. Para ello, se usa el atributo c (country). En el caso de que la empresa esté ubicada en España y se llame Empresa Ejemplar, S. A., tendríamos DN o=Empresa Ejemplar\, S. A., c=ES. Nótese el uso del carácter \ para denotar que la coma pertenece al valor del atributo y el intérprete no debe confundirlo con el inicio de un nuevo atributo.
Finalmente, es posible que un directorio tenga más de un sufijo. Esto será necesario en caso de fusionar directorios pertenecientes a organizaciones con sufijos distintos.
2.1.2.Estructura del directorio
Otro elemento para tener en cuenta al diseñar un espacio de nombres es la estructura del directorio, que en el fondo también tendrá implicaciones en la complejidad del directorio en cuanto a jerarquía se refiere.
El espacio de nombres más simple sería un espacio de nombres plano, por ejemplo, sin departamentos ni grupos de usuarios. La figura siguiente muestra un espacio de nombres plano.
Figura 4. Espacio de nombres plano
Figura 4. Espacio de nombres plano
Esto sería adecuado para organizaciones con pocos usuarios o recursos. Ahora bien, en grandes organizaciones es recomendable seguir una estructura jerárquica.
En organizaciones que contemplan departamentos o distintos perfiles de usuarios, se aconseja crear unidades organizacionales (identificadas con el atributo ou). Además, distribuir los recursos en grupos puede ser útil, por ejemplo, para temas de control de acceso a recursos.
Ejemplo
Supongamos la distribución de usuarios de una empresa como la que muestra la figura siguiente.
Figura 5. Ejemplo de estructura jerárquica
Figura 5. Ejemplo de estructura jerárquica
Usando una estructura como la anterior, sería fácil permitir el acceso a determinados recursos a los usuarios del grupo «Técnicos» o a los del grupo «Ventas».
2.1.3.Identificación de objetos en el directorio
El último elemento que analizaremos sobre el diseño del espacio de nombres tiene que ver con la identificación de los objetos dentro del directorio. Tal y como hemos visto, las restricciones que impone LDAP a la hora de identificar objetos son dos:
1) El RDN de una entrada se formará a partir de un atributo (o más de uno, aunque no es recomendable).
2) En RDN debe ser único entre las entradas «hermanas» (aquellas que penden del mismo padre en la estructura).
Aunque solamente haya establecidas estas dos restricciones, se aconseja en general que la identificación de los objetos (en especial cuando se trata de personas o usuarios) se haga mediante un identificador único.
Para hacer esto, se debe garantizar que el nombre de usuario sea único. Claramente, podría haber dos personas con el mismo nombre. Aunque una organización sea pequeña, resultaría poco práctico que hubiera un usuario identificado con un nombre muy común, como por ejemplo «pepe», porque fácilmente puede haber o habrá algún día otro usuario «pepe» que almacenar en el directorio (y no sería muy estético llamarlo «pepe2»). Por este motivo debe utilizarse un atributo que identifique unívocamente al usuario, por ejemplo, se puede usar su NIF.
Claramente, otra opción para gestionar la unicidad de los atributos de identificación es que el administrador cree los identificadores controlando que estos sean únicos. Podrían usarse las iniciales, y adicionalmente números, para evitar repeticiones. O bien, si el directorio se usa para acceder a servicios funcionando en sistemas operativos tipo Unix o Linux, estaría bien que el identificador de usuario coincidiera con el nombre de usuario que se defina para los servicios. En este caso se utilizaría el atributo uid, que significa user identifier.
Finalmente, otra opción, aunque no recomendable, sería asignar una cadena aleatoria como identificador del usuario, y decimos que no es recomendable porque recordar esta cadena aleatoria no sería fácil.
Pese a tener múltiples opciones para identificar a usuarios y recursos, la solución debe ser práctica y estética.

2.2.Esquema del directorio

Hasta ahora hemos hablado de objetos en el sentido amplio de la palabra. Hemos visto que un directorio contiene entradas con sus distintos atributos. Una entrada representa a un objeto cuya información es almacenada en el directorio. Y se puede entrever que las entradas pueden ser de varios tipos: individuos, recursos, grupos, etc. Anteriormente, ya hemos apuntado en qué consiste el esquema del directorio, ahora vamos a tratar varios aspectos relacionados con su diseño.
El esquema del directorio es la definición de qué tipos de objeto guarda un directorio y qué atributos se utilizan para su definición.
Las implementaciones de servicios de directorio ya suelen incluir sus propias definiciones de esquema, los cuales suelen poderse ampliar sin problemas para cubrir cualquier necesidad.
A lo largo de este subapartado vamos a tratar los conceptos de atributo y clase, esenciales en la definición del esquema del directorio.
2.2.1.Atributo
Los atributos sirven directamente para guardar información (nombre de persona, número de teléfono, fotografía, etc.). Para definir un atributo en LDAP, es preciso contar con una serie de información:
1) Un nombre que identifica al atributo que se define. En caso de LDAP, ya hay algunos nombres estándar definidos (common name, telephoneNumber, etc.), algunos de ellos con una abreviatura también conocida (por ejemplo, «cn» para common name). LDAP no distingue entre mayúsculas y minúsculas.
2) Un OID (identificador de objeto) que también identifique al atributo. Los OID son cadenas de números que permiten localizar de forma precisa un objeto de datos. Los OID también definen un espacio de nombres con una jerarquía. Por ejemplo, 2.5.4.16. es el OID de postalAddress y el valor «2» significa que el resto de estructura ha sido propuesto con la ITU en conjunción con la ISO. La notación que siguen los OID está definida en el ASN.1 (abstract syntax notation one). Dado que en el fondo usar el OID no es necesario, a no ser que se deba interactuar con sistemas X.500, el uso de OID no suele ser muy popular, ya que es más cómodo trabajar con nombres a la hora de identificar el atributo.
3) Una descripción textual del atributo para permitir anotaciones. Esta permite hasta 1.024 caracteres.
4) Una sintaxis del atributo, la cual define cómo se representan los datos. La sintaxis se identifica mediante un OID.
Ejemplo
Si se especifica 1.3.6.1.4.1.1466.115.121.1.15, nos estamos refiriendo a que la sintaxis del atributo es la cadena de texto. O bien, si se trata de un número de teléfono, empezando por «+», seguido del prefijo internacional y seguido del número de abonado, estamos refiriéndonos a la sintaxis 1.3.6.1.4.1.1466.115.121.1.50.
5) Unas reglas de coincidencia, que son utilizadas en las búsquedas de información en el directorio. Por ejemplo, si se especifica caseIgnoreMatch, se está indicando que las mayúsculas no se deben tener en cuenta a la hora de comparar cadenas de caracteres.
6) Otros valores, como por ejemplo la longitud máxima, etc.
Los atributos pueden derivar de otros atributos. Es decir, dada la definición general de un atributo como por ejemplo name, puede haber una serie de atributos que deriven de este y, en consecuencia, hereden sus características.
Ejemplo
El esquema de datos de LDAP, que especifica los atributos estándar que ya vienen definidos para un servicio de directorio, incluye la definición del atributo name: 
attributetype (2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768})
pero a la hora de definir el atributo cn o commonName, especifica que su superior es name: 
attributetype (2.5.4.3 NAME ('cn' 'commonName') SUP name)
En el ejemplo de la definición del atributo name se observa el uso de EQUALITY y SUBSRT para especificar reglas de coincidencia, mientras que la sintaxis se especifica mediante SYNTAX y su correspondiente OID. En la propia sintaxis se especifica una longitud máxima entre llaves.
Para finalizar con el subapartado sobre atributos, se presenta la siguiente tabla, que contiene algunos de los atributos estándar en LDAP.
Tabla 2. Descripción de algunos de los atributos más habituales en LDAP

Atributo

Descripción

cn, commonName

Nombre del objeto (si el objeto es una persona, sirve para especificar su nombre completo)

sn, surname

Apellido de una persona

serialNumber

Número de serie de un dispositivo o recurso

c, countryName

Nombre del país usando dos caracteres, tal y como especifica la ISO 3166

st, stateOrProvinceName

Nombre del estado, provincia, comunidad autónoma, etc.

street, streetAddress

Dirección postal (calle, número, etc.)

o, organizationName

Nombre de la organización

ou, organizationalUnitName

Nombre del departamento u otra unidad organizacional

title

Título de la persona dentro de una organización (presidente, director, etc.)

description

Descripción del objeto, de forma comprensible para los humanos

postalCode

Código postal

telephoneNumber

Número de teléfono

preferredDeliveryMethod

Descripción de cómo quiere una persona que se le entregue información (por ejemplo, por fax o correo electrónico)

member

Se trata de un DN que indica de quién es miembro el objeto en el árbol del directorio

uid, userid

Identificador de usuario, en general usado para autenticarse en un servicio o sistema

userPassword

Contraseña

dc, domainComponent

Especificación de un dominio DNS según RFC 1274 y 2247, por ejemplo, «es» o «uk»

buildingName

Nombre del edificio donde está ubicada una organización o una persona

preferredLanguage

Idioma preferido por la persona para comunicarse oralmente o por escrito

userSMIMECertificate

Certificado o cadena de certificados para autenticación y comprobación de firmas electrónicas
2.2.2.Clase de objeto
Hasta ahora hemos visto la definición de atributos. Mediante esta operación se pueden definir atributos específicos para nuestro servicio de directorio. Una vez los atributos han sido definidos, se pueden utilizar clases de objetos para definir cómo son las entradas del directorio. Cada entrada del directorio pertenece a un tipo de objeto determinado. Como en el caso de los atributos, ya hay algunas clases de objetos definidos como estándar.
Mediante las clases de objetos se especifica qué atributos debe contener la entrada de forma obligatoria y qué atributos puede contener definidos de manera opcional. También será posible usar la clase de objeto a la hora de buscar información en el directorio.
Ejemplo
Recordemos que en el ejemplo sobre operaciones de interrogación visto anteriormente especificábamos objectClass=person para buscar solo personas (en el fondo, entradas correspondientes a la clase «person»). Este es un ejemplo de definición de la clase «person»: 
objectClasses: (2.5.6.6 NAME 'person'

DESC 'RFC2256: a person' SUP top STRUCTURAL

MUST (sn $ cn)

MAY (userPassword $ telephoneNumber $ seeAlso $ description))
Nótese que, de un modo similar a la definición de atributos en el esquema, la definición de una clase precisa del uso de un OID (2.5.6.6). También hay un campo de descripción textual donde se informa que la definición de «person» se corresponde con lo establecido en el RFC 2256.
Se especifica que la clase es de tipo estructural. Esto significa que la clase describe propiedades básicas del objeto; en general, casi todas las clases definidas son de este tipo. La descripción de otros tipos se escapa de los objetivos de este módulo.
El apartado MUST indica que es necesario que un objeto del tipo «person» incluya el apellido (sn) y el nombre completo (cn). Los campos que puede contener, pero no son esenciales, están indicados en MAY. En la definición de algunas clases, no existe la entrada MUST. Esto significa que no se requiere ningún campo en concreto.
Finalmente, vemos que en las clases también existe la definición de «superiores», en este caso el superior de «person» es «top».
En la tabla siguiente se especifican algunas características para algunas de las clases típicamente definidas en un esquema.
Tabla 3. Características de algunas de las clases típicamente definidas en un esquema

Clase

MUST

MAY

alias (permite que la entrada de directorio apunte hacia otra entrada)

aliasedObjectName

  

organization

o

userPassword, seeAlso, businessCategory, preferredDeliveryMethod, telephoneNumber, facsimileTelephoneNumber, street, postOfficeBox, postalCode, postalAddress, physicalDeliveryOfficeName, description, etc.

organizationalUnit

ou

userPassword, seeAlso, businessCategory, preferredDeliveryMethod, telephoneNumber, internationaliSDNNumber, facsimileTelephoneNumber, street, postOfficeBox, postalCode, description, etc.

person

sn, cn

userPassword, telephoneNumber, seeAlso, description

device

cn

serialNumber, seeAlso, owner, ou, o, l (localización), description

account

userid

description, seeAlso, l, o, ou, host

document

documentIdentifier

commonName, description, seeAlso, l, o, ou, documentTitle, documentVersion, documentAuthor, documentLocation, documentPublisher

room

commonName

roomNumber, description, seeAlso, telephoneNumber
Nótese que clases como organizationUnit pueden tener contraseña o número de teléfono.

2.3.Seguridad, eficiencia y disponibilidad del directorio

Después de haber analizado los puntos clave del diseño del espacio de nombres y del esquema del directorio, veremos brevemente otros aspectos estrechamente relacionados con la implantación real del servicio de directorio.
2.3.1.Seguridad en el directorio
El objetivo de aplicar seguridad al directorio es proteger la información de accesos no autorizados. Este modelo va más allá de permitir el acceso al servicio de directorio, y puede incluso detallar qué operaciones se pueden llevar a cabo con qué atributos y por parte de quién se pueden realizar estas operaciones.
Una opción para proteger la información es usar protección en la capa de transporte de la información. Así, por ejemplo, puede usarse un canal de comunicación SSL/TLS (5) para proporcionar confidencialidad y autenticidad a la información que se transmite entre el servicio de directorio y la herramienta con quien interactúa.
Una de las informaciones que conviene proteger del acceso indebido es la contraseña. En los estándares no se especifica cómo debe hacerse esta protección, con lo cual se deja en manos del implementador. Lo que sí es habitual es que en lugar de guardar la contraseña en claro se guarde un resumen de la contraseña en lugar de la contraseña original.
En el caso de la contraseña, guardando su resumen no es computacionalmente posible saber cuál es el valor original de esta. Ahora bien, dado que la función de resumen que se utiliza para guardar la contraseña es conocida, sería relativamente fácil que un atacante crease una contraseña y guardase su resumen en la entrada de cualquier usuario. Mediante este ataque, el atacante podría suplantar la identidad del usuario ante cualquier servicio o sistema que use el directorio como herramienta de autenticación.
Con relación a este tema, puede ser necesaria la definición de listas de control de acceso. Mediante estas listas el servicio de directorio tiene claramente definidos varios parámetros sobre el acceso a los datos, cuyo seguimiento debe procurarse ante el acceso de consultas y modificaciones.
Ejemplo
Para cada atributo de cada tipo de entidad, pueden definirse permisos de lectura y escritura en función del perfil de quien ejecuta la petición, además de poder especificar métodos de validación específicos. Así pues, para ver la extensión telefónica de un trabajador de una organización, no haría falta autenticarse (bastaría con una conexión anónima). O bien, para modificar el valor de un atributo salario, debería ser necesario autenticarse como un usuario del grupo de administradores.
La mayoría de las implementaciones de servicio de directorio permiten la autenticación del cliente (recordemos que puede ser un usuario, o bien otra aplicación telemática) mediante un certificado electrónico. Otra forma de restringir los datos que contiene un servicio de directorio es haciendo que estos estén aislados de los usuarios o equipos que no pueden acceder al servicio.
Ejemplo
Si un servicio de directorio está pensado para realizar autenticaciones en servidores de correo o intranets, el servidor que controla el directorio puede estar en la red interna de la organización. El portal web de la intranet, que debe estar claramente accesible desde el exterior para poder ofrecer sus servicios, hará una consulta a una máquina (el servidor del directorio), que puede perfectamente estar ubicada en la red interna. Otra alternativa será proteger el servidor de directorio mediante un cortafuegos que permita el acceso a determinados perfiles de dirección de red.
En la figura siguiente, el cliente se conecta a un servidor webmail por internet, y para autenticarse manda la contraseña. La comprobación de la contraseña se hace a nivel interno mediante el servicio de directorios que se halla sin conexión a la red exterior.
Figura 6. Ubicación del servicio de directorio en una red interna
Figura 6. Ubicación del servicio de directorio en una red interna
2.3.2.Eficiencia y disponibilidad
Asimismo, tan importante como la seguridad es la eficiencia y la disponibilidad. Cierto es que un pequeño directorio para una organización pequeña podrá ejecutarse en una única máquina, de la cual se podría hacer una copia de seguridad diaria de los datos. Ahora bien, si el número potencial de peticiones de información al servicio de directorio es muy elevado, puede ser conveniente que, por motivos de eficiencia, los datos se encuentren distribuidos en más de una máquina.
La figura siguiente muestra dos disposiciones de los datos de un servicio de directorio. A la izquierda, un único servicio de directorio alberga toda la información de la organización. A la derecha están los dos servicios de directorio existentes: uno especializado en albergar la información sobre usuarios y el otro especializado en información sobre recursos.
Figura 7. Ejemplo de distribuciones única (izquierda) y distribuida (derecha)
Figura 7. Ejemplo de distribuciones única (izquierda) y distribuida (derecha)
La compartición de información debería hacerse de modo que el servidor correspondiente a usuarios y el servidor correspondiente a recursos reciban aproximadamente la misma carga de operaciones. Si no puede ser así, se debería apostar por la replicación de la información en más de una máquina.
La replicación de información, es decir, el proceso de mantener múltiples copias de datos del directorio en distintas ubicaciones propicia una serie de ventajas relacionadas con la eficiencia del sistema. En primer lugar, no se colapsará un único servicio con las peticiones de los clientes. La replicación de datos permite la existencia de un servidor que centralice las peticiones de los clientes y, en función de distintos parámetros, redirigir la petición. Por ejemplo, si se usa como parámetro la carga de trabajo de los servidores de réplica, se redirigirá la petición a la máquina que tenga menos trabajo en aquel momento. Además, si la red es relativamente grande (por ejemplo, red de campus o metropolitana) el acceso a datos será más rápido si estos se encuentran replicados cerca de la ubicación de red del cliente.
Adicionalmente, se resuelven temas de disponibilidad: si uno de los servidores que alberga la réplica cae, el cliente podrá hacer uso de alguno de los servidores de réplica que estén activos.
Para que el sistema de replicación funcione, tal como se muestra en la figura siguiente, es preciso que se contemple un protocolo de replicación de datos para dar consistencia a la información contenida en los distintos servidores.
Figura 8. Protocolo de replicación de datos
Figura 8. Protocolo de replicación de datos

3.Implementaciones de servicio de directorio

Después de realizar una aproximación teórica al concepto, diseño y usos de los servicios de directorio, y de haber estudiado el sistema LDAP, vamos a estudiar tres casos concretos de implementación:
1) OpenLDAP
2) Apache Directory Server
3) Active Directory
Todos ellos están inspirados por LDAP.

3.1.OpenLDAP

OpenLDAP es una implementación de un servicio de directorio basado en LDAP bajo la filosofía de software libre y código abierto. El proyecto OpenLDAP es quien se encarga de su desarrollo y sus productos se hallan disponibles en multitud de distribuciones GNU/Linux. Además, existen versiones para otras plataformas de sistemas operativos, como el Mac OS X o MS Windows.
OpenLDAP y sus proyectos derivados proporcionan distintos componentes, y la versión disponible en septiembre de 2021 es la 2.5.7.
El software está dividido en un conjunto de componentes diferenciados, lo que nos permite personalizar la instalación que necesitemos e instalar aquellos que se ajusten a nuestras necesidades. Los componentes principales son los siguientes:

  • Slpad: stand-alone LDAP daemon (servidor). Es el proceso del sistema que ejecuta un servidor LDAP.

  • Librerías: que implementan el protocolo LDAP.

  • Utilidades, herramientas y clientes de ejemplo: complementa el paquete de software con diferentes programas que nos pueden ayudar, por ejemplo, en tareas de configuración o distribución de clientes a los usuarios.

3.1.1.Slpad
Tal como hemos comentado anteriormente, Slapd es el proceso que ejecutándose como daemon implementa las funcionalidades de servidor LDAP.
Una vez que hemos obtenido e instalado el software el siguiente paso es configurar Slapd para utilizarlo en nuestra instalación. Desde la versión de OpenLDAP 2.3, se permite también la configuración dinámica del daemon slapd, lo que nos permite realizar cambios «en caliente», sin reiniciar el proceso.
Slpad almacena la configuración del servidor LDAP con un esquema y un DIT predefinidos, con clases de objetos específicos que nos permite realizar las operaciones de configuración global, definiciones de esquemas, definiciones de bases de datos, etc. En la siguiente figura vemos un árbol de configuración de muestra:
Figura 9. Árbol de configuración
Figura 9. Árbol de configuración
Este árbol de configuración presenta una estructura definida y muy específica. La raíz del árbol se denomina cn = config y almacena los ajustes de la configuración global. El resto de las configuraciones adicionales se almacenan en entradas secundarias y separadas.
Por ejemplo, la entrada cn = schema, cn = config contiene el esquema del sistema, es decir, todo aquello que está configurado en Slapd.
Uno de los aspectos que debemos tener en cuenta a la hora de realizar la configuración de OpenLDAP es si queremos que sea un servidor independiente o si, por el contrario, será un servidor que tendrá que comunicarse con otros servidores LDAP.
En el primero de los casos tendremos un servidor que dará soporte a nuestro dominio local:
Figura 10. Servidor LDAP independiente
Figura 10. Servidor LDAP independiente
Mientras que en el resto de las configuraciones tendremos relaciones entre diferentes servidores LDAP, como por ejemplo esta, que nos muestra una jerarquía de servidores:
Figura 11. Diferentes servidores LDAP
Figura 11. Diferentes servidores LDAP
Otro aspecto importante a la hora de realizar la configuración de nuestro servidor Slapd es la elección del backend. Los backends se encargan de las operaciones necesarias para almacenar o recuperar datos en respuestas a solicitudes LDAP. Existen diferentes backends que, o bien se pueden cargar estáticamente con el servidor, o bien pueden cargar dinámicamente.
Estos son algunos de los backends que podemos elegir con Slapd:
1) LDIF: este es un backend de almacenamiento básico que guarda entradas en archivos de texto en formato LDIF y utiliza el sistema de archivos para crear la estructura de árbol de la base de datos. Es un backend fácil de configurar y usar, pero por el contrario no es el de los que presenta mejor rendimiento.
Como otros muchos backends se puede instanciar con muy pocas opciones de configuración: 
include./schema/core.schema

 database ldif
 directory./ldif
 suffix "dc=uoc,dc=edu"
 rootdn "cn=LDIF,dc=uoc,dc=edu"
 rootpw LDIF
2) LMDB: el backend mdb es el recomendado por los desarrolladores de OpenLDAP para una base de datos Slpad normal. Utiliza una base de datos en memoria, llamada LMDB (Lightning OpenLDAP), para almacenar los datos. Es el reemplazo del antiguo backend de Berkeley DB.
Es un backend completamente jerárquico y no utiliza almacenamiento de caché. Además, no requiere ajustes para ofrecer el máximo rendimiento de búsqueda. 
incluir./schema/core.schema 

 database 
 directorio mdb./mdb 
 sufijo "dc = uoc, dc = edu" 
 rootdn "cn = mdb, dc = uoc, dc = edu" 
 rootpw mdb 
 maxsize 1073741824
3) LDAP: este backend no es una base de datos real. Su función es actuar como un proxy para realizar un reenvío de las peticiones entrantes a otro servidor LDAP. Hay que recalcar que las sesiones que se vinculan de forma explícita a este backend siempre crean su propia conexión privada al servidor LDAP remoto. 
base de datos ldap 
 sufijo "dc = suretecsystems, dc = com" 
 rootdn "cn = slapd-ldap" 
 uri ldap: // localhost / ldap: // remotehost ldap: // remotehost2
Además de estos backends que hemos presentado existen otros que se pueden configurar y cuya documentación tenemos disponible en la web del proyecto OpenLDAP.
OpenLDAP es un software complejo que implementa muchas más funcionalidades para proporcionar seguridad, balanceo de carga, replicación, etc.

3.2.Apache Directory Server

Además de OpenLDAP, que es uno de los servicios de directorios más utilizados en la actualidad, existen otras alternativas de software libre, como por ejemplo el creado por la Fundación Apache.
El Apache Directory Server (ApacheDS) es un servicio de directorio extensible y empotrable en otros proyectos basados en componentes Java que ha sido desarrollado totalmente con el lenguaje de programación Java y que está certificado como compatible con LDAPv3 por Open Group.
Otra de las características principales es el soporte del protocolo Kerberos 5. Se ha diseñado para permitir triggers, procedimientos almacenados, colas y vistas, tradicionalmente asociados a las bases de datos y que están menos disponibles en servidores LDAP. La versión actual, en septiembre de 2021, es la 2.0.0 y está disponible para Sistemas Operativos Windows, Linux y Mac OS X.
Apache DS es uno de los proyectos específicos de LDAP que forman parte del Apache Directory Project, y su función principal es la de servidor LDAP. El otro proyecto relacionado es el Apache Directory Studio, cuyo objetivo es proporcionar herramientas LDAP y utilidades de administración específicas para el ApacheDS.
La arquitectura del servidor ApacheDS está formada por muchas capas diferentes. En la siguiente figura se muestran las cuatro capas principales:
Figura 12. Capas del servidor ApacheDS
Figura 12. Capas del servidor ApacheDS
1) Network: su función principal es recibir las conexiones del usuario cuando quiere obtener algunos datos del servidor. Esta capa no es obligatoria cuando el servidor está embebido dentro del otro servidor que proporciona esta funcionalidad. Es en esta capa donde se implementa el protocolo Kerberos.
2) DirectoryService: es el núcleo del servidor, donde se procesan las solicitudes de los usuarios y realizamos la conexión al backend configurado para obtener los datos. Tiene un punto de entrada llamado OperationManager, que se encarga de enviar las solicitudes a la cadena de interceptores registrados para cada operación.
3) PartitionNexus: en esta capa están definidos los interceptores. Son capas funcionales dentro de ApacheDS, cada uno de los cuales es responsable de una tarea específica. Tienen un orden concreto y no debe cambiarse.
Cada una de las operaciones recibidas por Apache DS será procesada por uno o más interceptores, en el orden correspondiente hasta llegar al backend.
4) Backend: es la parte encargada de almacenar los datos de forma que podamos recuperarlos fácilmente ante una petición de usuario. Actualmente, tenemos tres tipos de backends disponibles: JDBM, In-Memory y LDIF.
Al igual que OpenLDAP, ApacheDS también implementa otras características relacionadas con la seguridad y la replicación del directorio.

3.3.Active Directory

En los años noventa, Microsoft implantó el concepto de sistema operativo de red en sus productos. En concreto, Windows NT 3.0 ya implementaba un entorno en red, con distintos recursos accesibles remotamente y usuarios, gestionados por un administrador. El concepto de dominio agrupaba distintos recursos y usuarios.
A finales de los noventa, apareció el Active Directory, una concreción del concepto de directorio adaptado mediante técnicas provenientes del LDAP para poder dar respuesta a propiedades de robustez y rendimiento. A diferencia de la implementación que había en Windows NT, que usaba el protocolo NetBIOS como mecanismo primario de comunicación de red, el Active Directory (‘directorio activo’) ya requería el uso de TCP o IP, así como del servicio DNS.
Al igual que otras implementaciones de LDAP, ofrece un sistema de administración centralizado y la organización de los datos en forma distribuida y replicada. A diferencia de otras implementaciones LDAP, es un servicio de directorio para uso en un entorno Windows Server.
La base de datos donde almacena la información AD es una base que tiene una estructura jerárquica y distribuida que comparte información de la infraestructura del dominio que administra y que le permite localizar, proteger y administrar los recursos del equipo y de la red, tales como archivos, usuarios y grupos de usuarios o dispositivos de red.
La unidad fundamental de organización del AD es el dominio. Un dominio en AD es un contenedor lógico utilizado para administrar un conjunto de usuarios, grupos y computadoras, entre otros. Todos estos objetos se almacenan en una partición específica dentro de la base de datos de AD.
Los dominios se pueden agrupar en un árbol de dominios, que es una colección de uno o más dominios que comparten un espacio de nombres contiguos. Por ejemplo, si tenemos un dominio llamado dominio.com, este podría tener un subdominio llamado subdominio.dominio.com.
También se pueden agrupar a nivel lógico uno o más dominios creando lo que en terminología de Microsoft se conoce como bosque. Los dominios de un bosque comparten estructura lógica, el catálogo global, el esquema del directorio y la configuración.
AD integra seguridad en todas sus operaciones mediante la autenticación de inicio de sesión, en la que soporta el protocolo Kerberos y el control del acceso a los objetos que forman el directorio. La gestión de todos los recursos de la red se facilita con la implementación de políticas que se aplican a objetos del directorio.
Además de lo anterior, AD incluye otras características, entre las que podemos destacar las siguientes:

  • Un catálogo global, que contiene información sobre cada objeto del directorio y que permite a los usuarios y administradores poder consultar información del directorio independientemente del dominio que realmente tenga los datos.

  • Un servicio de replicación que distribuye los datos del directorio por la red. Todos los controladores del dominio participan en los procesos de replicación. Cualquier cambio que se produzca en el directorio, se replica a todos los controladores del dominio.

  • Mecanismos para facilitar a los usuarios y a las aplicaciones de la red la publicación de sus propios objetos en el directorio.

Resumen

En este módulo hemos estudiado el concepto de servicio de directorio y hemos visto aspectos relacionados con su diseño e implantación.
En primer lugar, hemos estudiado el uso de los directorios. Se ha visto que son un tipo concreto de base de datos que nos devuelve información a partir de la identificación de una entrada (el DN), o bien a partir de búsquedas en el directorio. Hemos revisado distintos tipos de directorios, desde los integrados en una aplicación hasta los directorios de sistemas operativos de red. Hemos visto la relación de un servicio de directorio con la seguridad de la información y el acceso a aplicaciones. Hemos estudiado el concepto de distinguished name y hemos concluido esta parte del módulo describiendo cuáles son las operaciones que los clientes pueden realizar con un servicio de directorio. Hemos visto de forma detallada las operaciones de interrogación, en especial la búsqueda. Asimismo, se han indicado las herramientas que existen para que otras aplicaciones y programas puedan acceder a los datos que contiene un directorio.
El siguiente apartado lo hemos dedicado a aspectos de diseño del directorio. En referencia al diseño del espacio de nombres, hemos tratado la elección del sufijo del directorio (cómo empieza el espacio de nombres), cómo decidir la estructura (hemos visto que hay espacios de nombres planos y jerárquicos) y cómo identificar los objetos. También hemos profundizado en el concepto de esquema del directorio, mediante el cual describimos qué información se guarda en el directorio. Hemos expuesto cómo se define un atributo en LDAP y también cómo podemos definir una clase de objeto. Para finalizar este apartado, hemos discutido aspectos relacionados con la seguridad en el acceso al directorio, la eficiencia del servicio de directorio y la disponibilidad de los datos que este contiene.
Para finalizar el módulo, hemos descrito tres implementaciones de servicio de directorio basadas en LDAP y ampliamente utilizadas: el OpenLDAP, el Apache Directory Server y el Active Directory de Microsoft.

Bibliografía

Desmond, R. y otros (2008). Active Directory: Designing, Deploying and Running Active Directory. Sebastopol (California): O'Reilly.
Howes, T. A. y otros (2003). Understanding and Deploying LDAP Directory Services (2.ª ed.). Boston (Massachusetts): Addison-Wesley Longman.
Raya, J. L. y otros (2008). Aprenda Microsoft Windows Server 2008. Madrid: Ra-Ma.