ldap

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


Tabla de contenidos

1. Conceptos b�sicos de LDAP
2. Ejemplo de configuraci�n de OpenLDAP
2.1. Configurando el back-end
2.2. Configurando las listas de control de acceso
2.3. Migraci�n del los datos al servidor LDAP
2.4. Configurando el usuario proxy
2.5. Configuraci�n de los clientes LDAP
2.6. Configurando NSS para que use LDAP
3. El formato LDIF
4. Introducci�n a LDAP

1. Conceptos b�sicos de LDAP

A continuaci�n 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 denominaci�n, o DN(Distinguished Name, nombre distinguido), que se forma de la concatenaci�n de los DNs relativos (o RDNs) de las entradas “padre” hasta llegar a la entrada “ra�z” 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.

Como se construyen los DNs de las entradas.

Este m�todo permite que cada entrada posea un identificador �nico, evitando la duplicaci�n 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 informaci�n a consultar. Cada atributo tiene un tipo de datos y acepta uno o mas valores. Adem�s, 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 implementaci�n OpenLDAP). La clase de datos que LDAP puede almacenar se puede extender agregando nuevos esquemas en este directorio.

2. Ejemplo de configuraci�n de OpenLDAP

Una buena manera de explicar el funcionamiento y configuraci�n de un servidor LDAP es mediante un ejemplo com�n de la vida real. A continuaci�n se explicar� como migrar la base de datos de usuarios y grupos para poder realizar la autenticaci�n a trav�s 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    eq
index       cn,mail,surname,givenname              eq,subinitial

La primer l�nea especifica el back-end de base de datos a utilizar, “ldbm” es la opci�n mas frecuentemente utilizada. La segunda l�nea declara el DN de la entrada ra�z del �rbol LDAP. La tercer y cuarta entrada definen los datos del usuario administrador (algo as� como su nombre de usuario y contrase�a), 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 almacenar�n 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 b�squedas.

La contrase�a 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 definir�n la clase de acceso que los distintos tipos de usuarios tendr�n en el �rbol LDAP.

En el archivo /etc/openldap/slapd.conf o en /etc/openldap/slapd.access.conf se agrega lo siguiente:

access to dn=".*,dc=ejemplo,dc=net" attr=userPassword
       by dn="cn=root,dc=ejemplo,dc=net" write
       by self write
       by * 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 operaci�n de autenticaci�n.

Pero, �d�nde est�n 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 enlaz�ndose (bind) a �ste en una determinada entrada de la jerarqu�a 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 contrase�a 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 direcci�n de correo electr�nico) a cualquiera, mientras que se permite su modificaci�n a la cuenta administrativa y al due�o del atributo.

Si bajo la entrada con DN “ou=People,dc=ejemplo,dc=net” se almacenan las cuentas de usuario del sistema, entonces deber�amos permitir s�lo la lectura de estos datos a todo el mundo (sin permitir la modificaci�n 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 modificaci�n por el usuario due�o. 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 declaraci�n de la pen�ltima ACL sobre la �ltima. A primera vista, podr�a parecer que esa pen�ltima ACL se encuentra inclu�da en la �ltima y que por lo tanto podr�a ser obviada, pero observando detenidamente se puede uno dar cuenta que la pen�ltima 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 configuraci�n 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. Migraci�n del los datos al servidor LDAP

Una vez configurada la base de datos y las listas de control de acceso, se procede a la migraci�n de los datos preexistentes. En la distribuci�n Mandrake, el paquete openldap-migration 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 creaci�n 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 informaci�n 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 autenticaci�n y por lo tanto no usan la operaci�n 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 contrase�a 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 contrase�a que se estableci� como rootpw en el archivo de configuraci�n, y si todo est� correcto, agregar� la entrada donde corresponde en la jerarqu�a 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 autenticaci�n que a continuaci�n 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 dn="cn=root,dc=ejemplo,dc=net" write
       by dn="cn=proxyuser,dc=ejemplo,dc=net" read
       by self write
       by * auth

Una vez hecho este cambio, se debe reiniciar el servicio LDAP para que tome la nueva configuraci�n. A continuaci�n 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, despu�s de ingresar la clave correspondiente al usuario proxy, muestra en formato LDIF el resultado de la b�squeda 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 mostrar�n todos sus datos, incluyendose el atributo userPassword como se muestra a continuaci�n:

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. Configuraci�n de los clientes LDAP

Lo que queda pendiente es configurar aquellas m�quinas que vayan a funcionar como clientes del servidor LDAP reci�n configurado.

Lo primero que se debe hacer es editar el archivo /etc/openldap/ldap.conf y agregarle la siguiente informaci�n:

host         <IP_del_servidor_LDAP>
base         dc=ejemplo,dc=net     # Esta entrada es igual al suffix
rootbinddn   cn=proxyuser,dc=ejemplo,dc=net
scope        one

pam_filter                      objectclass=posixaccount
pam_login_attribute             uid
pam_member_attribute            gid
pam_template_login_attribute    uid
pam_password                    md5

nss_base_passwd     ou=People,dc=ejemplo,dc=net?one
nss_base_shadow     ou=People,dc=ejemplo,dc=net?one
nss_base_group      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 m�quina cliente, y la contrase�a la va a leer desde el archivo /etc/openldap/ldap.secret, que debe tener modo 600 y contener la contrase�a del proxyuser, finalizando con una l�nea en blanco.

Esto va a permitir que los clientes LDAP para autenticaci�n 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 contrase�a no funcionar�a porque el usuario proxy s�lo tiene acceso de lectura sobre ese campo, pero cada usuario podr�a modificar su contrase�a utilizando el comando ldapmodify.

Si quisi�ramos hacer que el comando passwd funcione para cambiar las contrase�as de usuario, deber�amos cambiar el ACL del servidor para que el usuario proxy tenga acceso de escritura al campo userPassword, pero esto podr�a ser un problema de seguridad en aquellos casos que las m�quinas cliente sean controladas por otras personas no confiables, porque el archivo /etc/openldap/ldap.secret de cada m�quina cliente ser�a legible por el root local de cada estaci�n.

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 configuraci�n es /etc/nsswitch.conf:

passwd:    files ldap
shadow:    files ldap
group:     files ldap
hosts:     files ldap dns

Esto har� que los sistemas clientes consulten primero sus archivos locales, luego hagan b�squedas en LDAP y en el caso de los hosts, hagan consultas por DNS como �ltimo recurso.

En el /etc/hosts de los clientes s�lo se deber�a 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 importaci�n y exportaci�n de datos independientemente del servidor LDAP que se est� utilizando.

Cada servidor LDAP tiene una o varias maneras de almacenar f�sicamente sus datos en el disco r�gido, 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 implementaci�n 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 dem�s por una l�nea 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 peque�os cambios que se necesiten realizar manualmente en los datos, siempre manteniendo la independencia de la implementaci�n LDAP y de la plataforma donde est� instalada.

A continuaci�n 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. Introducci�n a LDAP

LDAP significa Lightweight Directory Access Protocol (Protocolo Liviano de Acceso a Directorio), es un protocolo que provee servicios de directorio, organizando la informaci�n 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. Jerarqu�as en �rbol de varios servicios.

Figura 2. Jerarqu�as en �rbol de varios servicios

Jerarqu�as en �rbol de varios servicios

LDAP funciona como una base de datos, optimizada para las operaciones de lectura y b�squeda. 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 informaci�n, tiene algunas ventajas muy interesantes, como ser:

  • Evita la duplicaci�n de datos, la estructura de datos obliga a que no exista el mismo dato en dos lugares diferentes del esquema.

  • Permite la distribuci�n de la administraci�n, al igual que el servicio de DNS, la responsabilidad en la administraci�n de los datos de un �rbol se puede separar entre distintos equipos si es necesario.

  • Acepta niveles de acceso bien detallados, pudiendo definir pol�ticas de seguridad por cada nodo.

Figura 3. Delegaci�n del �rbol LDAP

Delegaci�n del �rbol LDAP

Adem�s de esto, LDAP provee capacidades de r�plica, de modo tal que se aumenta la confiabilidad y disponibilidad de la informaci�n, aumentando tambi�n la eficiencia del servicio ya que la carga se puede repartir entre las r�plicas. Las r�plicas autom�ticamente ir�n sincroniz�ndose con su servidor central cada cierto tiempo, hasta cierto punto se acepta cierta inconsistencia en las r�plicas, ya que como se ha comentado al comienzo, normalmente no se realizan muchas actualizaciones a los datos.

�Qu� clase de informaci�n puede contener y cual es el uso que se le puede dar? eso es a discreci�n del administrador. Algunos ejemplos comunes son:

  • Libretas de direcciones compartidas.

  • Autenticaci�n 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.