ldap

Author: Proyecto Cursos http://es.tldp.org/htmls/cursos.html

Tabla de contenidos 1. Conceptos bsicos de LDAP 2. Ejemplo de configuracin de OpenLDAP 2.1. Configurando el back-end 2.2. Configurando las listas de control de acceso 2.3. Migracin del los datos al servidor LDAP 2.4. Configurando el usuario proxy 2.5. Configuracin de los clientes LDAP 2.6. Configurando NSS para que use LDAP 3. El formato LDIF 4. Introduccin a LDAP

1. Conceptos bsicos de LDAP

A continuacin detallaremos los conceptos y vocabulario que se debe manejar para poder entender temas mas avanzados de LDAP. Cada nodo del rbol de datos se lo denomina entrada. Cada entrada tiene una denominacin, o DN(Distinguished Name, nombre distinguido), que se forma de la concatenacin de los DNs relativos (o RDNs) de las entradas padre hasta llegar a la entrada raz del rbol, como se puede ver en Figura 1. Como se construyen los DNs de las entradas.. Figura 1. Como se construyen los DNs de las entradas.

Este mtodo permite que cada entrada posea un identificador nico, evitando la duplicacin de entradas de esta manera, tal como sucede en el servicio de nombres de dominio en Internet. Cada entrada posee atributos donde se almacenar la informacin a consultar. Cada atributo tiene un tipo de datos y acepta uno o mas valores. Adems, cada entrada posee una o mas entradas objectClass, las cuales definen los atributos que la entrada tendr disponibles, detallando cuales atributos son obligatorios y cuales son opcionales. Por ejemplo una entrada para describir una cuenta de usuario en el servidor puede derivar del objectclass posixAccount, cuyos atributos obligatorios son cn, uid, uidNumber, gidNumber y homeDirectory y sus atributos opcionales: userPassword, loginShell, gecos y description. Cada uno de estos objectClass se define en un archivo, normalmente localizado en el directorio /etc/openldap/schema (en la implementacin OpenLDAP). La clase de datos que LDAP puede almacenar se puede extender agregando nuevos esquemas en este directorio.

2. Ejemplo de configuracin de OpenLDAP

Una buena manera de explicar el funcionamiento y configuracin de un servidor LDAP es mediante un ejemplo comn de la vida real. A continuacin se explicar como migrar la base de datos de usuarios y grupos para poder realizar la autenticacin a travs del protocolo LDAP.

2.1. Configurando el back-end

Editando el archivo /etc/openldap/slapd.conf, se agrega una base de datos de la siguiente manera:

database ldbm suffix "dc=ejemplo,dc=net" rootdn "cn=root,dc=ejemplo,dc=net" rootpw {MD5}kuJhGtfsDfglwjhHUTQNmd== directory /var/lib/ldap index objectClass,uid,uidNumber,gidNumber index cn,mail,surname,givenname eq,subinitial

eq

La primer lnea especifica el back-end de base de datos a utilizar, ldbm es la opcin mas frecuentemente utilizada. La segunda lnea declara el DN de la entrada raz del rbol LDAP. La tercer y cuarta entrada definen los datos del usuario administrador (algo as como su nombre de usuario y contrasea), ya que esta cuenta no puede estar incluida en la base de datos LDAP antes que se haya configurado. La quinta entrada sirve para definir el directorio donde se almacenarn los archivos correspondientes a esta base de datos y las ltimas dos entradas establecen los tipos de ndice que se van a utilizar en las distintas entradas, para bsquedas. La contrasea rootpw est cifrada con el algoritmo MD5, esto se puede generar con el comando slappasswd de la siguiente manera:
# slappasswd -h {MD5}

2.2. Configurando las listas de control de acceso

El siguiente paso es configurar las listas de control de acceso, que definirn la clase de acceso que los distintos tipos de usuarios tendrn en el rbol LDAP. En el archivo /etc/openldap/slapd.conf o en /etc/openldap/slapd.access.conf se agrega lo siguiente:
access to by by by dn=".*,dc=ejemplo,dc=net" attr=userPassword dn="cn=root,dc=ejemplo,dc=net" write self write * auth

Esta primer lista de control de acceso se puede interpretar como: Para los atributos userPassword de todas las entradas bajo "dc=ejemplo,dc=net", se dar permiso de escritura al usuario administrador, al usuario propietario, y al resto se les permitir la operacin de autenticacin. Pero, dnde estn los usuarios?. El concepto de usuario tal como se lo conoce normalmente aqu no se aplica, sino que se habla de Bind DN, cada cliente LDAP debe autenticarse con el servidor enlazndose (bind) a ste en una determinada entrada de la jerarqua de la base de datos (DN), que necesariamente deber poseer un atributo userPassword. Con esta ACL lo que se hace es proteger el atributo de contrasea para que no cualquier pueda siquiera inspeccionarlo. Luego siguen otras ACLs:
access to dn=".*,dc=ejemplo,dc=net" attr=mail

by dn="cn=root,dc=ejemplo,dc=net" write by self write by * read

Este es un ejemplo similar al anterior, pero se permite la lectura del atributo mail (es decir, la direccin de correo electrnico) a cualquiera, mientras que se permite su modificacin a la cuenta administrativa y al dueo del atributo. Si bajo la entrada con DN ou=People,dc=ejemplo,dc=net se almacenan las cuentas de usuario del sistema, entonces deberamos permitir slo la lectura de estos datos a todo el mundo (sin permitir la modificacin de por ejemplo, el nombre de usuario, ni siquiera al propio usuario) de esta manera:
access to dn=".*,ou=People,dc=ejemplo,dc=net" by * read

Finalmente se agrega el ACL por defecto, que permite la lectura de todos los atributos por cualquiera, y su modificacin por el usuario dueo. Se hace esto de la siguiente forma:
access to dn=".*,dc=ejemplo,dc=net" by self write by * read

Cada ACL se chequear en el orden en que fueron declaradas, es por eso que la ACL que se agreg ltima, no debe declararse antes de otras, porque puede llegar a anular su funcionalidad. Un ejemplo claro es la declaracin de la penltima ACL sobre la ltima. A primera vista, podra parecer que esa penltima ACL se encuentra includa en la ltima y que por lo tanto podra ser obviada, pero observando detenidamente se puede uno dar cuenta que la penltima ACL no permite escritura a nadie, bajo la entrada ou=People,dc=ejemplo,dc=net, y que por mas que la ltima entrada si lo permita, la anterior tiene precedencia. Si estas ACLs se agregaron en su propio archivo /etc/openldap/slapd.access.conf, entonces habr que cerciorarse que se incluya este archivo en el archivo de configuracin principal /etc/openldap/slapd.conf con la siguiente sintaxis:
include /etc/openldap/slapd.access.conf

Para que se tomen los cambios, recordar de reiniciar el servicio LDAP en el sistema.

2.3. Migracin del los datos al servidor LDAP

Una vez configurada la base de datos y las listas de control de acceso, se procede a la migracin de los datos preexistentes. En la distribucin Mandrake, el paquete openldapmigration instala una serie de herramientas para facilitar enormemente esta tarea. Dentro del directorio /usr/share/openldap/migration/ se deber editar el archivo migrate_common.ph cambiando las siguientes declaraciones de variable:

$DEFAULT_MAIL_DOMAIN = "ejemplo.net"; $DEFAULT_BASE = "dc=ejemplo,dc=net"; $DEFAULT_MAIL_HOST = "mail.ejemplo.net"; $EXTENDED_SCHEMA = 1;

Lo siguiente es editar el archivo migrate_all_online.sh y comentar aquellos servicios que no queremos migrar, como por ejemplo:
#$PERL -I${INSTDIR} ${INSTDIR}migrate_protocols.pl $ETC_PROTOCOLS >> $DB

Finalmente se ejecuta dicho script ingresando los datos que va pidiendo.

2.4. Configurando el usuario proxy

La siguiente etapa, consiste en la creacin de una entrada especial en el servidor LDAP, que servir como usuario proxy. Este usuario se utilizar para leer las entradas userPassword de las otras entradas, de tal manera de proveer esa informacin a los clientes que necesiten autenticarse. Con esto, permitiremos autenticar a aquellos servicios que poseen una interfaz con el servidor LDAP, pero que mantienen su propio esquema de autenticacin y por lo tanto no usan la operacin auth provista por el servidor LDAP. El primer paso entonces es crear un archivo LDIF, por ejemplo en /tmp/proxy.ldif cuyo contenido sea el siguiente:
dn: cn=proxyuser,dc=ejemplo,dc=net cn: proxyuser sn: proxyuser objectclass: top objectclass: person userPassword: {MD5}kihwqmIGdaIhnqLjashOKJ==

La contrasea se debe crear con el comando slappasswd como se vi anteriormente. Una vez escrito correctamente el archivo LDIF, se lo agrega al servidor ejecutando el comando ldapadd de esta manera:
# ldapadd -x -D "cn=root,dc=ejemplo,dc=net" -W -f /tmp/proxy.ldif

Este comando pedir la contrasea que se estableci como rootpw en el archivo de configuracin, y si todo est correcto, agregar la entrada donde corresponde en la jerarqua de rbol del servidor LDAP. Una vez agregado el usuario proxy, habr que permitirle el acceso de lectura al atributo userPassword para que pueda ser utilizado por los mecanismos de autenticacin que a continuacin configuraremos. Para darle el permiso necesario al usuario proxy, deberemos modificar el primer ACL definido anteriormente, para que quede de esta forma:
access to dn=".*,dc=ejemplo,dc=net" attr=userPassword

by by by by

dn="cn=root,dc=ejemplo,dc=net" write dn="cn=proxyuser,dc=ejemplo,dc=net" read self write * auth

Una vez hecho este cambio, se debe reiniciar el servicio LDAP para que tome la nueva configuracin. A continuacin se puede realizar una consulta al servidor LDAP mediante el comando ldapsearch:
# ldapsearch -LL -H ldap://localhost -b"dc=ejemplo,dc=net" -W x -D "cn=proxyuser,dc=ejemplo,dc=net" "(uid=pedro)"

Este comando, despus de ingresar la clave correspondiente al usuario proxy, muestra en formato LDIF el resultado de la bsqueda de entradas que tengan el atributo uid con el nombre pedro, a partir de la entrada dc=ejemplo,dc=net en adelante (es decir, todo el rbol). Si todo estuvo correctamente configurado, y existe una entrada con tal atributo, entonces se mostrarn todos sus datos, incluyendose el atributo userPassword como se muestra a continuacin:
version: 1 dn: userid=pedro,ou=People,dc=ejemplo,dc=net objectClass: top objectClass: account objectClass: person objectClass: userSecurityInformation uid: pedro sn: Picapiedras cn: Pedro userPassword:: e01ENX1HcWFsOUpQQWowMHV5VkFVb1MyL3dnPT0= telephoneNumber: 431-2125

2.5. Configuracin de los clientes LDAP

Lo que queda pendiente es configurar aquellas mquinas que vayan a funcionar como clientes del servidor LDAP recin configurado. Lo primero que se debe hacer es editar el archivo /etc/openldap/ldap.conf y agregarle la siguiente informacin:
host base suffix rootbinddn scope <IP_del_servidor_LDAP> dc=ejemplo,dc=net # Esta entrada es igual al cn=proxyuser,dc=ejemplo,dc=net one objectclass=posixaccount uid gid uid md5

pam_filter pam_login_attribute pam_member_attribute pam_template_login_attribute pam_password nss_base_passwd nss_base_shadow nss_base_group

ou=People,dc=ejemplo,dc=net?one ou=People,dc=ejemplo,dc=net?one ou=Group,dc=ejemplo,dc=net?one

nss_base_hosts

ou=Hosts,dc=ejemplo,dc=net?one

El campo rootbinddn especifica a qu usuario el root se va a cambiar al intentar conectarse desde la mquina cliente, y la contrasea la va a leer desde el archivo /etc/openldap/ldap.secret, que debe tener modo 600 y contener la contrasea del proxyuser, finalizando con una lnea en blanco. Esto va a permitir que los clientes LDAP para autenticacin al querer acceder como root se cambien al usuario proxy y puedan leer los campos userPassword de cada usuario para lograr su finalidad. el inconveniente es que el comando passwd utilizado para que cada usuario se cambie su propia contrasea no funcionara porque el usuario proxy slo tiene acceso de lectura sobre ese campo, pero cada usuario podra modificar su contrasea utilizando el comando ldapmodify. Si quisiramos hacer que el comando passwd funcione para cambiar las contraseas de usuario, deberamos cambiar el ACL del servidor para que el usuario proxy tenga acceso de escritura al campo userPassword, pero esto podra ser un problema de seguridad en aquellos casos que las mquinas cliente sean controladas por otras personas no confiables, porque el archivo /etc/openldap/ldap.secret de cada mquina cliente sera legible por el root local de cada estacin.

2.6. Configurando NSS para que use LDAP

NSS es el Name Service Switch que sirve para decirle al sistema cuales son las fuentes de datos para ciertas informaciones, el archivo de configuracin es /etc/nsswitch.conf:
passwd: shadow: group: hosts: files files files files ldap ldap ldap ldap dns

Esto har que los sistemas clientes consulten primero sus archivos locales, luego hagan bsquedas en LDAP y en el caso de los hosts, hagan consultas por DNS como ltimo recurso. En el /etc/hosts de los clientes slo se debera dejar con la entrada del host local, hostname y del servidor LDAP.

3. El formato LDIF
El LDAP Data Interchange Format (LDIF) es un formato que se utiliza para la importacin y exportacin de datos independientemente del servidor LDAP que se est utilizando. Cada servidor LDAP tiene una o varias maneras de almacenar fsicamente sus datos en el disco rgido, por esto que LDIF provee una manera de unificar la manera de tratar los datos y as poder migrar de un servidor a otro sin importar que clase de implementacin es.

El formato LDIF es simplemente un formato de texto ASCII para entradas LDAP, que tiene la siguiente forma:
dn: <nombre distinguido> <nombre_atributo>: <valor> <nombre_atributo>: <valor> <nombre_atributo>: <valor>

En un archivo LDIF puede haber mas de una entrada definida, cada entrada se separa de las dems por una lnea en blanco. A su vez, cada entrada puede tener una cantidad arbitraria de pares <nombre_atributo>: <valor>. Este formato es til tanto para realizar copias de seguridad de los datos de un servidor LDAP, como para importar pequeos cambios que se necesiten realizar manualmente en los datos, siempre manteniendo la independencia de la implementacin LDAP y de la plataforma donde est instalada. A continuacin podemos observar un ejemplo de una entrada para describir una cuenta de usuario en un servidor: Ejemplo 1. Formato LDIF para cuenta de usuario.
dn: uid=jperez,ou=People,dc=ejemplo,dc=com uid: jperez cn: Juan Perez objectclass: account objectclass: posixAccount objectclass: top loginshell: /bin/bash uidnumber: 512 gidnumber: 300 homedirectory: /home/jperez gecos: Juan Perez,,,, userpassword: {crypt}LPnaOoUYN57Netaac

4. Introduccin a LDAP
LDAP significa Lightweight Directory Access Protocol (Protocolo Liviano de Acceso a Directorio), es un protocolo que provee servicios de directorio, organizando la informacin de forma muy similar a como lo hace un sistema de archivos, o el servicio de nombres de dominio (DNS) en Internet tal como podemos ver en Figura 2. Jerarquas en rbol de varios servicios. Figura 2. Jerarquas en rbol de varios servicios

LDAP funciona como una base de datos, optimizada para las operaciones de lectura y bsqueda. Por otro lado, no posee soporte para ingreso de datos por transacciones ni rollback, que se encuentran en los motores de base de datos relacionales. Normalmente en LDAP las operaciones de ingreso de datos son a todo o nada. La arquitectura cliente-servidor y estructura en forma de rbol que utiliza LDAP para almacenar su informacin, tiene algunas ventajas muy interesantes, como ser:
y y

Evita la duplicacin de datos, la estructura de datos obliga a que no exista el mismo dato en dos lugares diferentes del esquema. Permite la distribucin de la administracin, al igual que el servicio de DNS, la responsabilidad en la administracin de los datos de un rbol se puede separar entre distintos equipos si es necesario. Acepta niveles de acceso bien detallados, pudiendo definir polticas de seguridad por cada nodo.

Figura 3. Delegacin del rbol LDAP

Adems de esto, LDAP provee capacidades de rplica, de modo tal que se aumenta la confiabilidad y disponibilidad de la informacin, aumentando tambin la eficiencia del servicio ya que la carga se puede repartir entre las rplicas. Las rplicas automticamente irn sincronizndose con su servidor central cada cierto tiempo, hasta cierto punto se acepta cierta inconsistencia en las rplicas, ya que como se ha comentado al comienzo, normalmente no se realizan muchas actualizaciones a los datos. Qu clase de informacin puede contener y cual es el uso que se le puede dar? eso es a discrecin del administrador. Algunos ejemplos comunes son:
y y y

Libretas de direcciones compartidas. Autenticacin de usuarios centralizada. Perfiles de usuarios centralizados, para permitir Roaming

En resumen, LDAP es un servicio muy flexible que permite a un administrador centralizar variados servicios, y de esta manera facilitar la tarea de mantenimiento sin que disminuya la confiabilidad del sistema.