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
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
Otra cuestión es el mantenimiento de las referencias. El proyecto OpenLDAP lo soluciona generando las referencias a partir de registros SRV. Para
_ldap._tcp.tia.es
IN SRV 0
0 1389 ldap.tia.es. Por supuesto esta vía obliga a las organizaciones a:
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
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:
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.
-
Rose, M.; D. Cass, "ISO Transport Services on top of the TCP". Internet RFC 1006. Mayo 1987
W. Yeong; T. Howes; S. Kille. "Lightweigth Directory Access Protocol". Internet RFC 1777. Marzo 1995
- M. Wahl; T. Howes; S. Kille. "Lightweigth Directory Access Protocol (v3)". Internet RFC 2251. Diciembre 1997
- Messaging Direct Limited. "Administrator's Guide: MessagingDirect M-Vault Server". 1999.
López Murcia, Alfonso. "Encadenar peticiones a servidores LDAP". http://www.um.es/~linux/x500/referrals. Julio 2000
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
ISO/IEC. "X.521: Selected Object Classes". http://www.dante.net/np/ds/osi/9594-7.X.521.A4.ps. Mayo 1994
A. Grimstad; R. Huber; S. Sataluri; M. Wahl. "Naming Plan for Internet Directory-Enabled Applications". Internet RFC 2377. Septiembre 1998
López Murcia, Alfonso. "Configuración del acceso móvil (roaming) con OpenLDAP".http://www.um.es/~linux/ldap/roaming. Mayo 2000
V. Samar; R. Schemers. "Unified login with Pluggable Authentication Modules (PAM)". OSF-RFC 86.0. Octubre 1985
L. Howard. "An Approach for Using LDAP as a Network Information Service". Internet RFC 2307. Marzo 1998
López Murcia, Alfonso. "Configuración de autentificación mediante LDAP".http://www.um.es/~linux/ldap/pam_ldap>. Agosto 2000
Coupeau, Ignacio. "Samba-PDC LDAP howto".http://www.unav.es/cti/ldap-smb/ldap-smb-HEAD-howto.html. Octubre 2000
Alfonso López Murcia
alfonso [at] dif [dot] um.esFacultad de Informática
Universidad de Murcia