OpenLDAP - Autenticación passthrough usando SASL

Hoy vamos con una entrada rápida sobre OpenLDAP en la cual vamos a revisar como podemos configurar la autenticación passthrough de OpenLDAP.

Y ¿que es exactamente la autenticación passthrough? De forma muy resumida es la capacidad de la que dispone OpenLDAP para, utilizando la biblioteca SASL, delegar el proceso de autenticación a un servicio de autenticación externo.

Este tipo de configuración puede ser útil en determinados casos, como por ejemplo, si la organización de nuestro servidor de directorio divide las entradas de usuarios por secciones o unidades organizativas y cada una de ellas debe usar diferentes tipos de servicios de autenticación o para validar usuarios desde aplicaciones web.

Esta característica de delegación del proceso de autenticación se basa en el uso del servicio saslauthd. Este servicio puede configurarse para recibir peticiones de autenticación de otros procesos que soporten SASL, realizando la autenticación al servicio externo que hayamos configurado y devolviendo el resultado del proceso de autenticación.

Partiendo de un sistema donde ya se encuentra instalado un servidor OpenLDAP, el cual debe tener compilado el soporte de la biblioteca SASL, usaremos un servicio Kerberos 5 para validar a los usuarios mediante saslauthd. En el caso de CentOS 7.8.2003, se incluye OpenLDAP versión 2.4.44 con soporte SASL.

Por tanto, a partir del sistema anterior y de forma muy resumida, el proceso se basa los siguientes pasos:

1. Primero necesitamos instalar el servicio saslauthd con las bibliotecas necesarias. Es importante tener en cuenta que vamos a instalar el paquete básico de la biblioteca SASL sin ningún mecanismo de autenticación adicional. Por tanto solo tenemos que buscar el paquete que proporciona el servicio saslauthd:



Servicio saslauthd.







2. Como queremos usar Kerberos 5 como servicio de autenticación, tenemos que instalar los paquetes que proporcionan los servidores de Kerberos. Es recomendable instalar también los paquetes que incluyan las herramientas como kinit para poder hacer pruebas y administrar correctamente el servicio:



Instalación de Kerberos 5.

3. Una vez instalado Kerberos 5 es necesario crear lo que, en terminología de Kerberos, se denomina un reino de autenticación. De forma muy resumida podemos entender un reino de autenticación de Kerberos como el dominio sobre el cual un servidor de Kerberos tiene la autoridad para autenticar a un usuario, host o servicio. De momento, y para resumir, la forma más rápida de crear un reino Kerberos es mediante la configuración del fichero /var/kerberos/krb5kdc/kdc.conf que contiene la configuración del servidor kdc que implementa y proprociona el servicio Kerberos. Una configuración básica es más o menos la siguiente:



Configuración básica servidor kdc.

4. Una vez realizada la configuración del servidor kdc, ya podemos inicializar el reino Kerberos. Este proceso crea la base de datos de Kerberos y el denominado fichero stash. El fichero stash contiene la contraseña maestra usada para encriptar la base de datos de Kerberos. Sin este fichero, el proceso krb5kdc del servidor no será capaz de arrancar de forma automática solicitando la password maestra en el arranque, con lo que es muy importante que creemos dicho fichero. Para inicializar el reino y crear el fichero solo necesitamos ejecutar un comando como el siguiente:



Inicialización del reino Kerberos LAB.INT.

5. En este punto ya está inicializado el reino Kerberos pero no hay ningún usuario o cuenta creada en la base de datos. Cada una de las entradas de una base de datos de Kerberos se denomina principal, independientemente de si corresponde a un usuario, host o servicio. Por tanto el primer paso consiste en crear el principal del administrador, que tendrá permisos sobre todos los principales del reino Kerberos. Para esto solo necesitamos hacer algo como lo siguiente:



Creación del principal administrador.

6. Para restringir el acceso a los ficheros de base de datos de Kerberos al principal del administrador, es necesario que establezcamos una ACL que incluya únicamente a dicho principal. Es importante señalar que un servidor Kerberos está constituido por dos servicios diferentes, el krb5kdc que implementa el servicio Kerberos y el servicio kadmind para las tareas de administración de la base de datos. Por tanto necesitamos establecer una ACL para el servidor kadmind que restrinja las operaciones sobre la base de datos del reino que hemos creado para el principal que hemos denominado como administrador. Para esto solo es necesario que editemos el fichero /var/kerberos/krb5kdc/kadm5.acl del siguiente modo:  



ACL para el administrador.

Ya tenemos la configuración básica necesaria para crear un reino Kerberos. Ahora, para poder realizar pruebas, creamos unos cuantos principales que mapearemos a un objeto de usuario que luego crearemos en el servidor OpenLDAP. Para crear principales solo es necesario que ejecutemos un comando como el que utilizamos para crear el principal con el rol adminsitrador:

Creación de principales de usuarios.

Llegado este punto tenemos un servidor OpenLDAP recién instalado y un reino Kerberos creado, cuyos servicios podemos arrancar si no lo hemos hecho antes. Suponiendo que nuestra idea es crear un servidor de nombres para sistemas Unix/Linux basado en LDAP, usando como servicio de autenticación Kerberos 5, es necesario que extendamos el schema del servidor OpenLDAP. Esta extensión del schema es necesaria para incluir los atributos y clases de objeto necesarios para el uso de un LDAP como servicio de nombres según la RFC 2307. Esta RFC establece como debe ser la estructura, atributos y clases de objeto para poder usar un servidor LDAP como servicio de nombres.

Con la distribucion de OpenLDAP se incluyen varios schemas adicionales que se pueden cargar si es necesario con solo usar el comando ldapadd. En el caso del paquete OpenLDAP incluido con CentOS 7, estos ficheros de schema están en la ruta /etc/openldap/schema:

Schemas incluidos con OpenLDAP.

De esta manera podremos extender el schema básico del servidor OpenLDAP en caso de ser necesario con alguno de los incluidos en caso de ser necesario.

Un punto importante a tener en cuenta a la hora de extender el schema de cualquier servidor de directorio es que, en general, pueden existir dependencias entre diferentes schemas. Esto se debe a que un schema puede requerir un atributo que está definido por otro schema y, por tanto, será necesario cargar ambos schemas siguiendo el orden de dependencia entre ellos.

Teniendo en cuenta lo anterior, los siguientes pasos serían:

1. Extendemos el schema de OpenLDAP añadiendo el schema nis, que es el que cumple con la RFC 2307. Este schema depende de los schemas core y cosine, con lo que ambos deben ser añadidos previamente. Para extender el schema solo es necesario usar un comando como el siguiente:



Extensión del schema de OpenLDAP.

2. A continuación creamos cuentas de usuario y de grupo en el servidor OpenLDAP para poder usarlo como servicio de nombres. Para esto podemos usar cualquier editor LDAP o mediante el comando ldapadd y ficheros ldif. En definitiva, lo que es necesario hacer es crear objetos de los tipos posixAccount para las cuentas de usuario y posixGroup para las de grupo. Una vez creados, tendríamos algo como lo siguiente:



Cuentas de usuario y de grupo en el servidor OpenLDAP.

3.  A continuación configuramos los sistemas Unix/Linux de la infraestructura para que utilicen el servidor OpenLDAP como servicio de nombres y el servidor Kerberos 5 como servicio de autenticación. Este paso dependerá de la distribución Linux que estemos utilizando. En el caso de distribuciones basadas en Red Hat, como CentOS, es muy recomendable utilizar authconfig-tui. En resumen será necesario configurar el cliente LDAP así como el cliente Kerberos 5 del sistema operativo cliente. Una configuración muy básica, y muy mejorable, para ambos servicios es la siguiente:

Configuración básica cliente Kerberos 5.

Configuración básica cliente LDAP.

Con esta configuración podemos comprobar que el sistema está correctamente configurado con solo realizar búquedas de información de usuarios y grupos así como validaciones mediante el comando kinit:

Pruebas de validación de principales Kerberos.

Comprobación del servicio de nombres.

Por tanto, en este punto, el servicio de nombres y autenticación funciona correctamente y los sistemas desplegados pueden utilizarlo como servicio centralizado de nombres y autenticación.

A continuación nos falta configurar saslauthd y OpenLDAP para poder delegar la validación de usuarios al servicio Kerberos 5 mediante la característica de passthrough de la que he hablado al principio del artículo.

Para este caso, la configuración de saslauthd utilizará como mecanismo de validación de contraseñas el sistema PAM del propio servidor. Para establecer esta configuración solo tenemos que modificar el fichero de configuración /etc/sysconfig/saslauthd como se muestra en la siguiente imagen:

Configuración saslauthd.

Ahora es necesario establecer la configuración de OpenLDAP necesaria para que emplee SASL y más concretamente saslauthd, para realizar el passthrough del proceso de autenticación. Este proceso de configuración de OpenLDAP se resume en los siguientes pasos:

1. Creamos el fichero /etc/sasl2/slapd.conf que le indicará al servicio slapd de OpenLDAP que debe usar saslauthd para validar contraseñas:



Configuración fichero /etc/sasl2/slapd.conf.

2. Ahora es necesario modificar la configuración del propio servidor OpenLDAP para añadir una serie de atributos de configuración relacionados con SASL. Estos atributos establecen que host va a realizar el procesado SASL siendo en este caso el propio servidor, así como cual es el reino SASL por defecto y las características de seguridad. Utilizando la configuracióon dinámica de OpenLDAP, quedaría del siguiente modo:



Configuración SASL de OpenLDAP.

3. El último paso de configuración necesario en OpenLDAP debe realizarse en todas aquellas entradas que representen las cuentas de usuario cuya autenticación queramos delegar a saslauthd. Este punto se basa en establecer el atributo userPassword de cada entrada de usuario usando una cadena como {SASL}principal@REINO lo cual indica a OpenLDAP que, al recibir una petición de validación que incluya el DN correspondiente a dicha entrada de usuario, esta debe delegarse al host SASL configurado en el paso anterior. Esta validación se realizará mediante el uso de saslauthd el cual, al haberlo configurado para usar el mecanismo PAM del servidor, realizará la autenticación contra el servicio Kerberos 5. Una entrada de usuario quedaría, por tanto, del siguiente modo:

Cuenta de usuario.

Hagamos una prueba de validación del usuario operator1 mediante la ejecución de un comando ldapsearch:

Búsqueda en OpenLDAP.

Como vemos la autenticación ha fallado y, si revisamos los logs del sistema encontraremos que se debe a que, al intentar validar al usuario mediante PAM, saslauthd intenta usar el módulo PAM para el servicio ldap el cual no existe por defecto:

Error de validación saslauthd.

Una forma rápida de solucionarlo, pero no la mejor ni la más adecuada, es hacer un enlace simbólico en el servidor para crear el fichero del servicio ldap usando la configuración de autenticación general del sistema. En caso de un sistema CentOS, algo tan sencillo como lo siguiente:

Creación entrada servicio ldap para PAM.

Al hacer esto, si volvemos a realizar la búsqueda ahora el resultado será satisfactorio y podremos comprobar en el log del servidor kdc como llega la petición de autenticación del usuario:

Búsqueda realziada correctamente.

Petición de validación del usuario.

En resumen, podemos configurar un servidor OpenLDAP para delegar la autenticación de todas o de ciertas entradas que representen usuarios, utilizando así el mecanismo de autenticación del propio servidor OpenLDAP para determinados usuarios y mecanismos externos, como Kerberos 5, en el caso de otros.

Como puntos importantes a revisar para futuras entradas, es el funcionamiento de PAM y como crear una entrada correcta para el servicio LDAP que utiliza saslauthd en una configuración como esta así como establecer una configuración más segura del cliente LDAP del sistema operativo cliente.