Servicios basados en LDAP: Migración desde X.500

Services based on LDAP: Migration from X.500

Alfonso López Murcia

Resumen

El auge de servicios basados en LDAP cambiará el Servicio de Directorio: paso de servidores X.500 a servidores LDAP, eliminación del sistema de nombres basado en criterios geopolíticos por otro basado en dominios Internet e integración del Directorio en los servicios tradicionales. En los párrafos siguientes analizaremos estos aspectos.

Palabras clave: LDAP, Directorio, roaming, X.500


Summary

The international boom of LDAP based services will introduce changes in the Directory Service. Some of these changes will be the shift from X.500 to LDAP servers, the replacement of name system based on geopolitical criteria for one based on Internet domains and the integration of Directory in the traditional services.

These aspects will be analized in the following article. Keywords: LDAP, Directory, roaming, X.500


1.- El Directorio, su problemática

El servicio de Directorio es una base de datos distribuida cuyas entradas representan objetos del mundo real. El conjunto de recomendaciones X.500 especifica de forma compleja todo lo necesario para la instalación del Directorio en distintos sistemas OSI (más información en el artículo del Boletín de RedIRIS: "El Servicio de Directorio en la Universidad de Murcia" [1].

Con la expansión de los protocolos TCP/IP se hizo posible la presencia de servidores de Directorio sobre equipos no OSI [2] como de clientes accediendo mediante el protocolo Lightweight Directory Access Protocol (LDAP) [3]. Como sabemos, los protocolos OSI son complejos y no tan eficientes como los basados en TCP/IP. En consecuencia, el futuro es una colección de servidores LDAP comunicados con este protocolo. Pero la transición es lenta debido a un problema: las referencias.

Cuando un cliente realiza una consulta a un servidor LDAPv2 [3] sobre entidades no presentes en su base de datos, la consulta falla al no disponer de la información necesaria para enlazar con otros servidores. El comportamiento es distinto si es un servidor LDAPv3 [4]. Entonces puede devolver una referencia (referral) al cliente en forma de URL indicando otro servidor. Una posible referencia es:

ldap://ldap.tia.es:1389

Surge la duda del mantenimiento de las referencias. Además, otra característica intrínseca de Internet, los dominios, nos hace replantearnos el esquema de nombres tradicional: ¿En qué parte del Directory Information Tree (DIT) se ubica una empresa ".com"? Por último, los usuarios conciben el Directorio como una enorme guía de teléfonos donde localizar información únicamente de personas. Pues bien, es posible incluir cualquier tipo de información cuya finalidad vendrá determinada por el tipo de servicio.

Los retos planteados en los párrafos anteriores se intentarán pormenorizar y aportar distintas soluciones.

2.- La interconexión entre servidores LDAP

El funcionamiento de un servidor LDAPv3 es sencillo: si tiene en su base de datos la información solicitada la devuelve, en caso contrario puede devolver una referencia (referral) de otro servidor al cliente, correspondiendo al mismo la continuación o anulación de la operación de consulta con el servidor propuesto.

La estrategia con respecto a las referencias puede ser o bien tener una única a la cual remitir siempre al cliente o bien disponer de una serie de referencias a los servidores que nos interese (por supuesto siempre es posible un sistema mixto). En ambos casos surge el problema del mantenimiento de las referencias.

En el Grupo de Trabajo IRIS-SEARCH estamos analizando la disponibilidad de un servidor LDAPv3 para gestionar tanto como bajo la cual se tiene una estructura mixta de servidores X.500 y LDAP. Una alternativa es emplear el servidor X.500/LDAPv3 Isode IC-R6 (gratuito para las organizaciones afiliadas a RedIRIS) por su dualidad. De este modo se continuaría la conexión nacional e internacional de servidores X.500 como el acceso a servidores LDAP mediante referencias cruzadas a los mismos [5]. Aspectos negativos: más de lo mismo (X.500), una gestión compleja y escasa de documentación. Todo lo anterior decanta a las organizaciones por servidores LDAP. Las experiencias con Isode IC-R6 se detallan en [6] y [7].

Con la solución anterior todos los servidores X.500 (en extinción) y LDAPv3 de las instituciones nacionales tendrían una sola referencia al DSA nacional. Por tanto el mantenimiento es sencillo. Sin embargo el servidor X.500/LDAPv3 Isode IC-R6 central debe mantener tantas referencias como servidores nacionales subordinados existan. Este proceso no sería automático, requiriendo actualizaciones manuales.

Dentro de la gama de servidores LDAP se ha decidido analizar las características de OpenLDAP. Como elemento más destacable es la enorme cantidad de información disponible, algo vital tanto para administradores como para usuarios. Aparte su instalación y mantenimiento es muy sencillo.

En lo concerniente a referencias, el proyecto OpenLDAP dispone de un servidor LDAP raíz que devuelve referencias basado en un esquema de dominios. Cualquier servidor LDAP puede incluirlo en su fichero slapd.conf y redirigir al cliente a dicho servidor raíz.

Obviamente interesaría disponer de un servidor OpenLDAP raíz en el dominio para agilizar las consultas. Y mientras exista la doble estructura basada en el esquema y debe mantenerse la posibilidad de acceder a todos los servidores de Directorio mientras se migra al esquema de dominios.

Otra cuestión es el mantenimiento de las referencias. El proyecto OpenLDAP lo soluciona generando las referencias a partir de registros SRV. Para alojado en "ldap://ldap.tia.es:1389" la entrada en el DNS sería:

_ldap._tcp.tia.es  IN  SRV  0  0  1389  ldap.tia.es.

Por supuesto esta vía obliga a las organizaciones a:

  • tener una estructura basada en dominios

  • mantener un inventario de servidores LDAP en el DNS.

3.- Los dominios Internet en el Directorio

En la parte izquierda de la figura vemos un resumen del esquema propuesto en la Recomendación X.521 [8].

Sin embargo el proceso de globalización está rompiendo las fronteras, como también lo hace Internet. En consecuencia, debemos pasar a un esquema como en la imagen derecha de la figura, descrito en el RFC 2377[9]. Observamos la eliminación del país y estado por un dominio de primer nivel, después vienen las organizaciones y unidades organizativas con su correspondientes dominios. Por ejemplo pasaría a ser .

En este punto nos planteamos la posibilidad de disponer de la misma entrada repetida en las dos bases de datos, por ejemplo "cn=Mortadelo, o=tia, c=es" y "cn=Mortadelo, dc=tia, dc=es" cuyo coste de mantenimiento se duplica como también el espacio de almacenamiento. Otra alternativa es tener una sola entrada y que la segunda sea un alias a la primera. Esta segunda solución se ha probado en Isode y OpenLDAP con un resultado desalentador, pues el paso de alias a la entrada referenciada se deja en manos del cliente y no todos pueden dar esta facilidad (como sucede en Netscape). En principio, parece más viable la primera estrategia.

Otro circunstancia importante es el nuevo Relative Distinguished Name (RDN) de las entradas. En base al RFC 2377 si el objeto tiene dirección de correo aconseja utilizar uid=dirección y sino tuviese propone continuar con el sistema tradicional cn=nombre. Un ejemplo puede ser:

dn: uid="bacterio@tia.es", dc=tia, dc=es
uid: bacterio
cn: Profesor Bacterio
sn: Bacterio
ou: Inventos
...

Otra reflexión es la asociación de unidades organizativas a dominios. Obviamente habrá una por subdominio dentro de la organización y si no es vital tener una estructura funcional podemos incluir la sección o departamento que no tiene dominio en la entrada. En el ejemplo anterior, si buscamos en la sección inventos aparece Profesor Bacterio.

4.- Nuevos servicios basados en LDAP: oaming y atuenticación

El acceso móvil de Netscape (roaming) permite guardar, entre otras cosas, nuestras preferencias de usuario, historial, marcadores (bookmarks) y cookies en un servidor LDAP. Nos podemos desplazar a cualquier lugar donde exista un ordenador con Netscape y tras identificarnos adecuadamente en el servidor LDAP donde se tienen todos los datos del acceso móvil se recupera el entorno habitual de trabajo. Cualquier cambio en nuestras preferencias se guardará de forma automática al finalizar nuestra sesión, apareciendo en la siguiente.

Los detalles sobre el proceso de configuración del servidor LDAP para disponer de este servicio se detallan en una página web [10]. Después en los clientes debemos activar el acceso móvil y aportar elusuario, por ejemplo:

Nombre de usuario: Mortadelo
Servidor de Directorio LDAP
Dirección: ldap://ldap.tia.es/nsLIProfileName=$USERID,ou=Roaming,dc=tia,dc=es
DN del usuario: $USERID,ou=People,dc=tia,dc=es

Finalmente resta seleccionar los elementos que se guardarán en el servidor LDAP. Desde este instante el usuario Mortadelo puede desplazarse por cualquier lugar y sus preferencias estarán siempre disponibles tras la correspondiente identicación. Pero esta autenticación sólo sirve para Netscape, no tiene nada que ver con el usuario y contraseña requeridos en el acceso a una sesión Unix.

Afortunadamente también es posible autentificar una cuenta Unix empleando el protocolo LDAP. Gracias a los Pluggable Authentication Modules (PAM)[11]son posibles otros mecanismos de autenticación de usuarios aparte de la tradicional cuenta en el fichero passwd. Dada la flexibilidad de estos módulos existe uno para consultar en un servidor LDAP por el login y password previos a una sesión. Por supuesto también se han definido los atributos necesarios de las cuentas en el Directorio, los detalles están en el RFC 2307 [12].

Nuevamente se remite al lector a una página web [13]donde se detallan los pasos precisos tanto en el servidor LDAP como en un cliente Linux. Para dar de alta al usuario Mortadelo podemos utilizar esta estructura:

dn: uid=mortadelo, dc=tia, dc=es
cn: Mortadelo
objectClass: top
objectClass: account
objectClass: posixAccount
userPassword: {crypt}QLYgF4k3EDxHG
uidNumber: 725
gidNumber: 654
gecos: Mortadelo
loginShell:/bin/bash

Cuando el usuario Mortadelo teclea su login y password en la máquina Linux se realiza una consulta LDAP al servidor correspondiente y el sistema tras validarlo establece los atributos uid, uidNumber, gidNumber y loginShell en el entorno de la sesión. Obviamente el cambio de clave implica un acceso LDAP y la consiguiente modificación del atributo userPassword. Los administradores encontrarán cierta semejanza con Network Information Service (NIS).

El paso siguiente dentro de una infraestructura de autenticación basada en LDAP sería incluir los clientes Windows. Para ello se amplía el esquema con las clases necesarias para cuentas Samba y se introduce un servidor Samba como Primary Domain Controller (PDC) siguiendo el documento "Samba-PDC LDAP HOWTO". Desafortunadamente no se ha podido probar, pero en un futuro esperamos disponer de un login y clave único para los usuarios.

5.- Conclusiones vías futuras

Al estar en pleno proceso de transición en la infraestructura del Directorio es aventurado proponer soluciones estables. Se han comentado las posibilidades de Isode IC-R6 y OpenLDAP, pero hay otros productos. De todos modos, debido a las facilidades de OpenLDAP esta solución parece más viable.

En la parte de servicios, al ser el Directorio un elemento importante en una Public Key Infrastructure (PKI) aumentará su importancia dentro de las organizaciones. Lo anterior añadido a nuevos servicios (roaming, autenticación) como a futuros desarrollos de empresas privadas ampliarán las funcionalidades basadas en LDAP.

En un futuro sería aconsejable implantar un sistema de autenticación único para Linux y Windows. Además, debido a la naturaleza confidencial de algunos datos deberemos cifrar los accesos LDAP tanto en consultas como en la gestión del servidor.

6.- Agradecimientos

Gracias al convenio colectivo pues quizá permita mi asistencia a las Jornadas y Grupos de Trabajo de RedIRIS 2000.

Referencias:

  1. López Murcia, Alfonso. "El Servicio de Directorio en la Universidad de Murcia". Boletín de RedIRIS nº 49 (http://www.rediris.es/rediris/boletin/49/enfoque1.html), octubre 1999.

  2. Rose, M.; D. Cass, "ISO Transport Services on top of the TCP". Internet RFC 1006. Mayo 1987

  3. W. Yeong; T. Howes; S. Kille. "Lightweigth Directory Access Protocol". Internet RFC 1777. Marzo 1995

  4. M. Wahl; T. Howes; S. Kille. "Lightweigth Directory Access Protocol (v3)". Internet RFC 2251. Diciembre 1997

  5. Messaging Direct Limited. "Administrator's Guide: MessagingDirect M-Vault Server". 1999.

  6. López Murcia, Alfonso. "Encadenar peticiones a servidores LDAP". http://www.um.es/~linux/x500/referrals. Julio 2000

  7. López Murcia, Alfonso. "Uso de un servidor Isode X.500/LDAP como referral de un servidor OpenLDAP". http://www.um.es/~linux/ldap/referrals. Septiembre 2000

  8. ISO/IEC. "X.521: Selected Object Classes". http://www.dante.net/np/ds/osi/9594-7.X.521.A4.ps. Mayo 1994

  9. A. Grimstad; R. Huber; S. Sataluri; M. Wahl. "Naming Plan for Internet Directory-Enabled Applications". Internet RFC 2377. Septiembre 1998

  10. López Murcia, Alfonso. "Configuración del acceso móvil (roaming) con OpenLDAP".http://www.um.es/~linux/ldap/roaming. Mayo 2000

  11. V. Samar; R. Schemers. "Unified login with Pluggable Authentication Modules (PAM)". OSF-RFC 86.0. Octubre 1985

  12. L. Howard. "An Approach for Using LDAP as a Network Information Service". Internet RFC 2307. Marzo 1998

  13. López Murcia, Alfonso. "Configuración de autentificación mediante LDAP".http://www.um.es/~linux/ldap/pam_ldap>. Agosto 2000

  14. Coupeau, Ignacio. "Samba-PDC LDAP howto".http://www.unav.es/cti/ldap-smb/ldap-smb-HEAD-howto.html. Octubre 2000


Alfonso López Murcia
dirección de correo alfonso [at] dif [dot] um.es
Facultad de Informática
Universidad de Murcia