Centralized authentication using OpenLDAP/es

Esta guía presenta las cuestiones básicas de LDAP y le muestra cómo configurar OpenLDAP para realizar tareas de autenticación entre un grupo de computadoras.

¿Qué es LDAP?
LDAP significa Lightweight Directory Access Protocol (Protocolo Ligero de Acceso a Directorio). Está basado en X.500 el cual define la mayoría de sus funciones y carece de algunas funciones esotéricas que tiene X.500. Ahora bien, ¿Qué es X.500 y porqué existe LDAP?

X.500 es un modelo de Servicio de Directorio basado en el concepto OSI (Interconexión de sistemas Abiertos). Contiene definiciones de espacios de nombres y protocolos para consultar y actualizar el directorio. Sin embargo, se ha encontrado en muchos casos que X.500 es demasiado estricto. Mejor entrar en LDAP. Al igual que X.500, proporciona un modelo de datos y espacio de nombres para el directorio y el protocolo. No obstante, LDAP está diseñado para correr directamente sobre la pila TCP/IP. Podemos considerar a LDAP como una versión ligera de X.500.

No lo pillo. ¿Qué es un directorio?
Un directorio es una base de datos especializada diseñada para consultas frecuentes y actualizaciones no tan frecuentes. Al contrario que las bases de datos generalistas, no ofrecen soporte para transacciones o funcionalidad de vuelta atrás (roll-back). Los directorios se replican fácilmente para incrementar disponibilidad y fiabilidad. Cuando se replican los directorios, se permiten inconsistencias temporales siempre que acaben sincronizándose.

¿Cómo se estructura la información?
Toda la información dentro de un directorio está estructurada jerárquicamente. Aún más, si intenta introducir datos en un directorio, éste debe conocer la forma de almacenar estos datos en un árbol. Eche un vistazo a una compañía ficticia y a su organigrama:

Puesto que no puede alimentar la base de datos con este tipo de arte ascii, se debe definir cada nodo de este árbol. Para nombrar estos nodos, LDAP usa un sistema de definición de nombres. La mayor parte de distribuciones de LDAP (incluyendo OpenLDAP) ya contienen un buen número de esquemas predefinidos (y normalmente aprobados), como el inetOrgPerson o un esquema llamado posixAccount utilizado frecuentemente para definir usuarios que los equipos Unix o Linux pueden utilizar. Observe que existen herramientas basadas en GUI para que facilitar la gestión de LDAP. Eche un vistazo a Trabajar con OpenLDAP para una lista exhaustiva.

Se recomienda a los usuarios interesado leer la Guía de Administración de OpenLDAP.

Y bien.. ¿Para qué se utiliza?
Se puede usar LDAP para diferentes propósitos. En este documento se trata la administración centralizada de usuarios, manteniendo todas las cuentas de usuario en una única ubicación LDAP (lo que no significa que esté albergada en un único servidor, puesto que LDAP ofrece soporte a alta disponibilidad y redundancia). Sin embargo, se puede utilizar LDAP para otros fines.


 * Infraestructura de Clave Pública (PKI)


 * Calendario compartido


 * Libreta de direcciones compartida


 * Almacenamiento para DHCP, DNS, ...


 * Directivas de configuración de clases del sistema (manteniendo el seguimiento de varias configuraciones del servidor)


 * Autenticación centralizada (PosixAccount)



Common notes
The domain genfic.org is an example in this guide. You will of course want to change this. However, make sure that the top node is an official top level domain (net, com, cc, be, ...).

En primer lugar haga emerge de OpenLDAP. Asegúrese que se usan los ajustes USE berkdb, crypt, gnutls, ipv6, sasl, ssl, syslog, -minimal' y tcpd.

OpenLDAP tiene un usuario principal llamado "rootdn" (Root Distinguished Name o Nombre Distinguido de Root) el cual está definido dentro de la aplicación. Al contrario que el usuario root clásico de Unix, al usuario rootdn se le deben asignar los permisos adecuados. El usuario rootdn solo se puede utilizar en el contexto de la configuración y también en la definición del directorio. En este caso un usuario puede autenticarse a si mismo como rootdn con la contraseña usada en la configuración y la contraseña (basada en el directorio) del árbol.

La contraseñas de usuario (independientemente si son para usuarios rootdn u otros) para propósitos de verificación se pueden almacenar como testo en claro o aplicando un hash. Se dispone de varios algoritmos hash, sin embargo no se recomienda el uso de algoritmos débiles (hasta MD5). Actualmente en criptografía se considera que SHA es suficientemente seguro.

En la orden de abajo, se crea un valor hash para una contraseña dada, el resultado de esta orden se puede utilizar en el fichero de configuración o bien en la definición del directorio interno de un usuario:

Legacy configuration (flat config slapd.conf)
Ahora edite la configuración LDAP del servidor en. El fichero que se muestra es de los fuentes originales de openLDAP. Abajo se muestra un fichero ejemplo de configuración que se puede utilizar para reemplazarlo de modo que las cosas comiencen a funcionar.

Para un análisis más detallado del fichero de configuración, le sugerimos que acceda a la guía del administrador de OpenLDAP.

Después de configurar el fichero, puede comprobarlo con la siguiente orden.

Cambie el nivel de depuración (El "-d 1" de arriba) para obtener más información. Si todo va bien se mostrará config file testing succeeded. Si hay un error,  mostrará el número de línea en la cual está el problema (dentro del fichero ).

By default writes the log events to the local4 syslog facility.

Observe que a partir de la versión 2.4.23, OpenLDAP cambió sus ficheros de configuración planos a la configuración en línea OLC (OnLineConfiguration también conocida por su estructura  ) como su método de configuración por defecto. Una de las ventajas de usar OLC es que el back-end dinámico (cn=config) no necesita reiniciar el servidor después de cambiar la configuración. Los usuarios que utilicen el método anterior pueden migrar al nuevo método de configuración mediante  indicando las opciones -f y -F. Tradicionalmente OLC se almacena en un back-end con formato ldif (que mantiene las ventajas de la legibilidad por parte de los humanos) en el directorio. En Gentoo todavía no es necesario convertir la configuración, sin embargo, en el futuro se eliminará el enfoque de documentación actual en este documento.

Migration from slapd.conf to OLC
Si desea poder cambiar la configuración del servidor OpenLDAP necesita definir al menos el acceso de escritura (o normalmente de gestión) a.

El ejemplo de abajo muestra como conceder acceso de gestión a OLC (base de datos cn=config) al administrador del sistema (usuario root) añadiendo las líneas adecuadas al final del fichero :

Then, we invoke the utility with the   and   options to convert the  file into a configuration directory.

Al lanzar esta orden se transferirá y traducirá la configuración. Después de esto, deberá actualizar la configuración utilizando ficheros ldif especialmente preparados. Si no está familiarizado con el formato de estos ficheros puede editar en primero y después traducir  a. No olvide comprobar los permisos sobre los directorios.

Para más indicaciones lea los comentarios en línea dentro de los ficheros generados.

La línea de abajo habilitará el método de configuración.

Para terminar, cree la estructura :

Arranque slapd:

Initial setup with OLC
An initial configuration is shipped as a standard LDAP database dump, available as or.

It can be loaded (and only loaded, unlike ordinary LDAP databases) by the  utility:

If you need the right to change the configuration database, you must provide the proper permissions. The next example shows how these privileges are granted to the system user:

See for more details.

When using OLC, never manually edit the configuration files. The directory files can be used to check the consistency of the configuration through:

Server management with OLC
Se muestran abajo algunos ejemplos de actualizaciones a la configuración con el estilo OLC.

Por ejemplo, para cambiar la localización del directorio de configuración de OLC:

Para cambiar el nivel del registro usado por la instancia OpenLDAP:

Para añadir el overlay syncprov:

Para aplicar los cambios, lance la siguiente orden:

OpenLDAP logging
OpenLDAP produces numerous log events, which might not be obvious to interpret, but are necessary for debugging purposes.

As OpenLDAP by default writes the log events into the system log, it is advisable to reconfigure the system logger to direct OpenLDAP log events into a dedicated log file.

Access management (ACLs)
The authorizations and access control mechanism used in OpenLDAP is described in the manual page. Its base syntax is as follows:

The following table shows the access levels available in OpenLDAP:

For details about the exact privilege settings, see the manual pages and official OpenLDAP documentation.

Config file
ACLs are parsed in the order they are set in the configuration, and are applied based on the specificity (meaning that, when an ACL rule is considered, the remainder of ACL rules is no longer checked). As such, more specific definitions should go first, before more generic ones are listed. For more information, see Access Control Evaluation.

For example:

Remember that the rootdn user can read and write everything.

Config directory
ACLs are parsed in the order they are set in the configuration, and are applied based on the specificity (meaning that, when an ACL rule is considered, the remainder of ACL rules is no longer checked). As such, more specific definitions should go first, before more generic ones are listed. This order, when using OLC, is handled through the  directives.

For example:

To insert a new ACL, the following example will add one on top, making the existing  entries to shift by one:

To delete an ACL:

Configurar las herramientas cliente de OpenLDAP
Edite el fichero de configuración del cliente LDAP. Este fichero lo lee ldapsearch y otras herramientas de línea de órdenes ldap.

Puede comprobar si el servidor está corriendo con la siguiente orden:

Si obtiene un error, intente añadir  para incrementar el nivel de información mostrada y solucionar el problema que tenga.

Configuración del cliente para autenticación centralizada
Existen varios métodos y herramientas que se pueden utilizar para realizar una autenticación remota. Algunas distribuciones incluso disponen de su propia herramienta de configuración de fácil uso. Abajo se muestran algunas (el orden no es importante). Es posible combinar a la vez usuarios locales y cuentas autorizadas centralmente. Estos es importante ya que, por ejemplo, si el servidor LDAP no es accesible, todavía se podrá acceder como root.


 * SSSD (Single Sign-on Services Daemon o Demonio para Servicios de Acceso Sencillo). Su principal función es ofrecer acceso a recursos remotos de identidad y autenticación a través de un marco de trabajo común que puede ofrecer caché y soporte fuera de línea al sistema. Ofrece módulos PAM y NSS. Además, en el futuro, ofrecerá soporte para interfaces D-Bus para información extendida de usuario. También ofrece una base de datos mejorada para almacenar usuarios locales así como datos de usuario extendidos.


 * Utilizar  para acceder al servidor LDAP y autenticarse. Las contraseñas no se envían por la red en texto claro.


 * NSLCD (Name Service Look up Daemon o Demonio de Consulta al Servicio de Nombres). Similar a SSSD pero más antiguo.


 * NSS (Name Service Switch o Conmutador de Nombres de Servicio) usando el módulo tradicional  para obtener los hash de las contraseñas a través de la red. Para permitir que los usuarios actualicen sus contraseñas, este servicio se debe combinar con el método.

Los dos primeros métodos se muestran abajo con las opciones de configuración mínimas para que funcionen.

El método de configuración del cliente PAM con SSSD
Este es el método más directo. Los tres ficheros que se necesitan editar se muestran abajo.

Añada sss al final tal y como se muestra abajo para permitir que la búsqueda la gestione el servicio de sistema sssd. Una vez haya terminado de editar, arranque el demonio sssd.

El último fichero es el más crítico. Abra otro terminal de root como respaldo antes de editarlo. Se han añadido las líneas que acaban en code># para permitir la autenticación remota. Observe el uso de para poder crear los directorios de inicio de los usuarios.

Ahora intente acceder desde otro equipo.

El método de configuración del cliente PAM con el módulo pam_ldap
En primer lugar configuraremos PAM para permitir la autorización LDAP. Instale de modo que PAM ofrezca soporte para la autorización LDAP y  de modo que su sistema pueda trabajar con servidores LDAP para información adicional (usado por ).

El último fichero es el más crítico. Abra algunos terminales de root como respaldo antes de editarlo. Se han añadido las líneas que terminan en  para permitir la autenticación remota.

Ahora cambie para que contenga:

A continuación, copie el fichero (OpenLDAP) desde el servidor al cliente de modo que lo clientes conozcan el entorno LDAP:

Por último configure sus cliente de modo que puedan comprobar el LDAP para las cuentas del sistema:

Si ha observado que alguna de las líneas que pegó en su se ha comentado (la línea  ), no se preocupe, no la necesita a no ser que quiera cambiar la contraseña de un usuario como superusuario. En este caso necesita volcar la contraseña de root a en texto claro. Esto es PELIGROSO y se debe usar chmod para cambiar el acceso a 600. Lo que debería hacer es dejar ese fichero vacía y cuando necesite cambiar la contraseña de algún usuario que está en el LDAP y en, escriba la clave allí y déjela unos diez segundos mientras cambia la contraseña del usuario y elimínela una vez haya terminado.

Migrar datos existentes a LDAP
Configurar OpenLDAP para su administración centralizada y la gestión de elementos Linux/Unix comunes, no es fácil. Gracias a algunas herramientas y guiones disponibles en Internet, la migración desde un punto de vista de un sistema de administración simple a un sistema centralizado y gestionado basado en OpenLDAP no es muy complicado.

Vaya a http://www.padl.com/OSS/MigrationTools.html y obtenga los guiones. Necesitará las herramientas de migración y el guión.

Ahora extraiga y copie el guión dentro de la la localización extraída:

El siguiente paso es migrar la información de su sistema a OpenLDAP. Esto se realiza con el guión una vez le haya proporcionado la información referente a la relacionada con su estructura y entorno LDAP.

En el momento de escribir este documento, las herramientas necesarias requieren las siguientes entradas:

La herramienta también le preguntará qué cuentas y ajustes desea migrar.

Alta disponibilidad
Para configurar la replicación de los cambios a través de múltiples sistemas LDAP. La replicación dentro de OpenLDAP, en esta guía, se configura utilizando una cuenta especial de replicación la cual posee privilegios de lectura en el servidor LDAP primario y que toma los cambios realizados en este servidor LDAP primario al secundario.

Esta configuración entonces se replica permitiendo al servidor LDAP secundario actuar igual que el primario. Gracias a la estructura interna de OpenLDAP, los cambios no se aplican de nuevo si ya están en la estructura LDAP.

Configurar la replicación
Para configurar la replicación, en primer lugar realice la configuración de un segundo servidor OpenLDAP, del mismo modo que se ha descrito arriba. Sin embargo, tenga cuidado de que, en el fichero de configuración:


 * El proveedor de la sincronización de la replicación apunta al otro sistema


 * El serverID de cada sistema OpenLDAP es diferente

A continuación, cree la cuenta de sincronización. Crearemos un fichero LDIF (el formato utilizado como entrada de datos para los servidores LDAP) y lo añadiremos a cada servidor LDAP:

Permisos OpenLDAP
Se echa un vistazo a verá que puede especificar las ACL (permisos si lo prefiere) de qué datos los usuarios pueden leer o escribir:

Esto le da acceso a todo lo que un usuario puede cambiar. Si es su información, entonces obtendrá acceso de escritura a ella, si es otro usuario, entonces podrá leer su información. Los usuarios anónimos puede enviar una petición de acceso y contraseña para entrar. Hay cuatro niveles de menor a mayor::.

La siguiente ACL es un poco más segura ya que bloquea a los usuarios normales para que no puedan leer las contraseñas ocultas de otras personas:

Este ejemplo le da a root y a Juan acceso para leer, escribir o buscar cualquier cosa en el árbol bajo. Esto también permite que los usuarios cambien su propia. En cuanto a la última sentencia todo el mundo posee la capacidad de buscar indicando que puede escribir en el filtro de búsqueda pero no pueden leer el resultado de la búsqueda. Ahora puede tener múltiples ACLs pero la regla nemotécnica es que se procesa de abajo hacia arriba por lo que su nivel tope debería ser el más restrictivo.

Mantener el directorio
Puede empezar utilizando el directorio para autenticar usuarios en apache/proftpd/qmail/samba. Puede administrarlo con LAM (Ldap Account Manager), phpldapadmin, diradm, jxplorer, o lat, que proporcionan interfaces de administración sencillos.

Agradecimientos
Nos gustaría dar las gracias a Matt Heler por dejarnos su máquina para realizar esta guía. También queremos agradecer a los tíos simpáticos en #ldap @ irc.freenode.net