República Bolivariana de Venezuela

Ministerio del Poder Popular para la Defensa

Universidad Nacional Experimental Politécnica de la Fuerza Armada

Núcleo Caracas

Cátedra: Defensa Integral

8vo Semestre Ing. Sistemas, Sección 02

Instructor: Tte. Crnel. (E) José Bermudez.

Alumnos C.I. Edwin Huggins 12.638.382 Miguel Díaz 15.586.326

Yanis Chacón 18.154.159 Jonathan Palacios 12.382.075

Mauricio Ramirez 16.004.032

Caracas, Diciembre de 2011

Taller sobre Migración

de Active Directory a LDAP

Introducción

La finalidad principal de este documento es demostrar configurar y utilizar un Servidor de

directorio LDAP (Protocolo Ligero de Acceso a Directorios) en su máquina Linux.

Aprenderá cómo instalar, configurar, ejecutar y mantener el servidor LDAP (en nuestro

caso, Debian 6). Después, se demostrará cómo almacenar, recuperar y actualizar

información en su Directorio, utilizando las utilidades y clientes LDAP. El demonio o

programa servidor para el directorio LDAP se llama slapd y puede ejecutarse sobre

muchas plataformas UNIX diferentes.

He aquí una configuración sencilla del servidor, válida para empezar, pero fácil también de

actualizar a una configuración distinta más adelante, si lo desea. La información que se

presenta en este documento representa una buena forma de iniciarse en el uso del

protocolo LDAP.

El protocolo DAP, X.500, es el protocolo de acceso a directorio de la pila OSI. El LDAP, del

inglés Lightweight Directory Access Protocol, es un protocolo que está implementado

sobre la pila TCP/IP y que surge como versión ligera al DAP, ya que este último requiere

bastantes más recursos que LDAP. Tenemos varias alternativas a la hora de elegir un

servidor LDAP, entre ellos los creados por la Universidad de Michigan y el servidor LDAP

de Netscape. OpenLDAP es la versión libre de este tipo de servidores.

Origen e influencias

Las compañías de telecomunicaciones introdujeron el concepto de servicios de directorio

a Tecnologías de Información y Redes de Computadoras, así su comprensión de los

requerimientos de directorios era bien desarrollado después de 70 años de producir y

manejar directorios de teléfonos. La culminación de este esfuerzo fue la

especificación X.500, un conjunto de protocolos producido por la Unión Internacional de

Telecomunicaciones (ITU por sus siglas en inglés) en la década de 1980.

Los servicios de directorio X.500 fueron accedidos tradicionalmente vía DAP (Directory

Access Protocol), que requería la pila de protocolos OSI (Open Systems Interconnection).

LDAP fue originalmente dirigido a ser un protocolo alternativo y ligero para acceder a

servicios de directorio X.500 a través de la pila de protocolos más simple (y ahora más

difundido) TCP/IP. Este modelo de acceso a directorio fue imitado de los

protocolos DIXIE Directory Assistance Service. Se usó inicialmente como un front-end o

interfaz final para X.500, pero también puede usarse con servidores de directorio únicos y

con otros tipos de servidores de directorio.

X.500 es un conjunto de estándares de redes de ordenadores de la ITU-T sobre servicios

de directorio, entendidos estos como bases de datos de direcciones electrónicas (o de

otros tipos). El estándar se desarrolló conjuntamente con la ISO como parte del Modelo

de interconexión de sistemas abiertos, para usarlo como soporte del correo electrónico

X.400.

Los protocolos definidos por X.500 incluyen, protocolo de acceso al directorio (DAP), el

protocolo de sistema de directorio, el protocolo de ocultación de información de

directorio, y el protocolo de gestión de enlaces operativos de directorio.

Dentro de la serie X.500, la especificación que ha resultado ser la más difundida no trata

de protocolos de directorio, sino de certificados de clave pública: X.509.

Servidores de directorio LDAP independientes pronto fueron implementados, así como los

servidores de directorio que soportaban DAP y LDAP. El último se hizo popular en

empresas debido a que eliminaba cualquier necesidad de desplegar una red OSI. Ahora,

los protocolos de directorio X.500 incluyendo DAP pueden ser usados directamente sobre

TCP/IP.

El protocolo fue creado originalmente por Tim Howes (University of Michigan), Steve

Kille (Isode Limited), y Wengyik Yeong (Performance Systems International) hacia 1993.

Un desarrollo más completo ha sido hecho por la Internet Engineering Task Force.

En las primeras etapas de ingeniería de LDAP, éste era conocido como Lightweight

Directory Browsing Protocol, o LDBP. Posteriormente fue renombrado dado que el ámbito

del protocolo había sido expandido para incluir no sólo navegación en el directorio y

funciones de búsqueda, sino también funciones de actualización de directorio.

LDAP ha influenciado protocolos posteriores de Internet, incluyendo versiones posteriores

de X.500, XML Enabled Directory (XED), Directory Service Markup

Language (DSML), Service Provisioning Markup Language (SPML), y Service Location

Protocol (SLP).

¿Qué es un servicio de directorio?

Un directorio es como una base de datos, pero en general contiene información más

descriptiva y más basada en atributos. La información contenida en un directorio

normalmente es lee mucho más de lo que se escribe. Como consecuencia los directorios

no implementan normalmente los complicados esquemas para transacciones o esquemas

de reducción (rollback) que las bases de datos utilizan para llevar a cabo actualizaciones

complejas de grandes volúmenes de datos. Por contra, las actualizaciones en un directorio

son usualmente cambios sencillos de “todo o nada”, si es que se permiten en algo.

Los directorios están afinados para proporcionar una repuesta rápida a operaciones de

búsqueda o consulta. Pueden tener la capacidad de replicar información de forma amplia,

con el fin de aumentar la disponibilidad y la fiabilidad, y a la vez reducir el tiempo de

respuesta. Cuando se duplica (o se replica) la información del directorio, pueden

aceptarse inconsistencias temporales entre la información que hay en las réplicas,

siempre que finalmente exista una sincronización.

Existen muchas maneras distintas de proporcionar un servicio de directorio. Los diferentes

métodos permiten almacenar en el directorio diferentes tipos de información, establecer

requisitos diferentes para hacer referencias a la información, consultarla y actualizarla, la

forma en que protege al directorio de accesos no autorizados, etc. Algunos servicios de

directorio son locales, proporcionando servicios a un contexto restringido (por ejemplo, el

servicio de finger en una única máquina). Otros servicios son globales, proporcionando

servicio en un contexto mucho más amplio.

¿Cómo funciona LDAP?

El servicio de directorio LDAP se basa en un modelo cliente-servidor. Uno o más servidores

LDAP contienen los datos que conforman el árbol del directorio LDAP o base de datos

troncal. El cliente LDAP se conecta con el servidor LDAP y le hace una consulta. El servidor

contesta con la respuesta correspondiente, o bien con una indicación de dónde puede el

cliente hallar más información (normalmente otro servidor LDAP). No importa con qué

servidor LDAP se conecte el cliente: siempre observará la misma vista del directorio; el

nombre que se le presenta a un servidor LDAP hace referencia a la misma entrada a la que

haría referencia en otro servidor LDAP. Es ésta una característica importante de un

servicio de directorios universal como LDAP.

Estructura de directorio

El protocolo accede a directorios LDAP, que siguen la edición de 1993 del modelo X.500:

Un directorio es un árbol de entradas de directorio.

Una entrada consta de un conjunto de atributos.

Un atributo tiene un nombre (un tipo de atributo o descripción de atributo) y uno o más

valores. Los atributos son definidos en un esquema (véase luego).

Cada entrada tiene un identificador único: su Nombre distinguido (Distinguished Name,

DN). Este consta de su Relative Distinguished Name (RDN) construido por algunos

atributos en la entrada, seguidos del DN de la entrada del padre. Pensar en el nombre

distinguido como un completo nombre de archivo y el nombre distinguido relativo como

el nombre de archivo relativo en un folder.

Se debe tener cuidado con el hecho de que un nombre distinguido puede cambiar en el

tiempo de vida de una entrada, por ejemplo, cuando las entradas son movidas en el árbol.

Para hacer más confiables e identificar de manera no ambigua las entradas

un UUID podría ser proporcionado en el conjunto de los atributos operacionales de la

entrada.

Una entrada puede lucirse como esta cuando es representada en el formato LDAP Data

Interchange Format (LDIF) (LDAP por sí mismo es un protocolo binario).

Backends, objetos y atributos en LDAP

slapd se suministra con tres diferentes bases de datos de backend (dorsal, o base de datos

de segundo plano) entre las que elegir. Se trata de LDBM, una base de datos de gran

rendimiento basada en disco: SHELL, una interfaz de base de datos para órdenes

arbitrarias de UNIX o guiones (scripts) del intérprete de órdenes (shell); y PASSWD, una

sencilla base de datos de contraseñas.

En el desarrollo de este documento, se da por supuesto que ha elegido la base de datos

LDBM.

La base de datos LDBM funciona asignando un identificador compacto de cuatro bytes,

único para cada entrada de la base de datos. La base de datos utiliza este identificador

para hacer referencia a entradas en los índices. La base de datos está compuesta de un

fichero índice principal, llamado id2entry, que mapea el identificador único de una

entrada en la representación en texto de esa misma entrada. También se da

mantenimiento a otros ficheros índice.

Para importar y exportar información de directorio entre servidores de directorios

basados en LDAP, o para describir una serie de cambios que han de aplicarse al directorio,

se usa en general del fichero de formato conocido como LDIF (siglas de "LDAP interchange

format", o formato de intercambio de LDAP). Un fichero LDIF almacena información en

jerarquías de entradas orientadas a objeto. El paquete de software LDAP que va a utilizar

incluye una utilidad para convertir ficheros LDIF a formato LDBM.

Un fichero LDIF corriente tiene este aspecto:

dn: o=Insflug, c=ES

o: Insflug

objectclass: organization

dn: cn=Luiz Malere, o=Insflug, c=ES

cn: Luiz Malere

sn: Malere

mail: malere@yahoo.com

objectclass: person

Como puede comprobar, cada entrada está identificada unívocamente por un nombre

distintivo (DN, "distinguished name"). El DN (nombre distintivo) está compuesto por el

nombre de la entrada en cuestión, más la ruta de nombres que permiten rastrear la

entrada hacia atrás hasta la parte superior de la jerarquía del directorio.

En LDAP, una clase de objetos define la colección de atributos que pueden usarse para

definir una entrada. El estándar LDAP proporciona estos tipos básicos para las clases de

objetos:

Grupos en el directorio, entre ellos listas no ordenadas de objetos individuales o de

grupos de objetos.

Emplazamientos, como por ejemplo:

El nombre del país y su descripción.

Organizaciones que están en el directorio.

Personas que están en el directorio.

Una entrada determinada puede pertenecer a más de una clase de objetos. Por ejemplo,

la entrada para personas se define mediante la clase de objetos person, pero también

puede definirse mediante atributos en las clases de

objetos inetOrgPerson, groupOfNames y organization. La estructura de clases de

objetos del servidor (su esquema) determina la lista total de atributos requeridos y

permitidos para una entrada concreta.

Los datos del directorio se representan mediante pares de atributo y su valor. Cualquier

pieza de información específica se asocia con un atributo descriptivo.

Por ejemplo el atributo commonName, o cn (“nombre de pila”), se usa para almacenar el

nombre de una persona. Puede representarse en el directorio a una persona llamada

Jonás Saqueiro mediante

cn: Jonás Saqueiro

Cada persona que se introduzca en el directorio se define mediante la colección de

atributos que hay en la clase de objetos person. Otros atributos que se usan para definir

esta entrada serán:

givenname: Jonás

surname: Saqueiro

mail: jonass@midominio.com

Los atributos requeridos son aquellos que deben estar presentes en las entradas que

utilicen la clase de objetos. Todas las entradas precisan del atributo objectClass, que

lista las clases de objeto a las que pertenece una entrada.

Los atributos permitidos son aquellos que pueden estar presentes en las entradas que

utilicen la clase de objetos. Por ejemplo, en la clase de objetos person, se requieren los

atributos cn y sn. Los atributos description (descripción), telephoneNumber (número

de teléfono), seeAlso (véase también), y userpassword (contraseña del usuario) se

permiten pero no se requieren.

Cada atributo tiene la definición de sintaxis que le corresponde. La definición de sintaxis

describe el tipo de información que proporciona ese atributo:

bin (binario)

ces (cadena con mayúsculas y minúsculas exactas - las mayúsculas y minúsculas

son significativas durante las comparaciones)

cis (cadena con mayúsculas y minúsculas ignoradas - las mayúsculas y minúsculas

no son significativas durante las comparaciones)

tel (cadena de número de teléfono - como cis, pero durante las comparaciones

se ignoran los espacios en blanco y los guiones "-")

dn ("distinguished name" - nombre distintivo)

Configuración del servidor LDAP

Para configurar el ldap haremos el típico configure, make y make install. El configure lo

haremos con las siguientes opciones:

$ ./configure --with-tls --enable-debug --enable-cache --enable-referrals --with-threads --enable-slapd --enable-slurpd

--with-tls nos permitirá tener soporte seguro a través de OpenSSL, por lo que deberemos

tener instaladas las bibliotecas de OpenSSL en nuestro sistema.

--enable-slapd y --enable-slurpd nos crearán los ejecutables para el servidor OpenLDAP y

para el encargado de la replicación. Aunque este último no lo trataremos en este artículo,

nos puede venir bien tenerlo para un futuro próximo.

Puedes ver la documentación para otros tipos de opciones, pero yo creo que con esta es

suficiente para lo que tenemos pensado montar.

Después, para compilar el software, testearlo e instalarlo en el sistema, haremos:

$ make depend $ make $ cd tests $ make tests $ cd .. $ su # make install

Si todo ha ido bien y no ha fallado ni la compilación ni los testeos, tendremos instalados

los binarios en /usr/local/libexec y los ficheros de configuración en

/usr/local/etc/openldap.

Procedemos ahora a configurar el fichero de configuración del openLDAP, que es

/usr/local/etc/openldap/slapd.conf. Este fichero está estructurado en dos partes, una

primera con las opciones globales del OpenLDAP y otra con las definiciones de cada base

de datos (directorio) que queramos tener. Hay que resaltar que las opciones de este

fichero deben comenzar en la primera columna del fichero, ya que si no lo hacen así, serán

considerados continuaciones de la línea anterior.

Veamos pues un fichero slapd.conf de ejemplo para definir un directorio que contendrá

una base de datos de usuario para un sistema de autentificación:

# See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema #include /usr/local/etc/openldap/schema/redhat/autofs.schema #include /usr/local/etc/openldap/schema/redhat/rfc822-MailMember.schema #include /usr/local/etc/openldap/schema/redhat/kerberosobject.schema ################################################################# #Los siguientes valores indican la ruta de los pid y los args. pidfile /var/run/slapd.pid argsfile /var/run/slapd.args # permisos para nuestra base de datos access to attr=userpassword

by self write

by * read access to * by self write by dn=".+" read by * read #################################################################### # DEFINICION DE LAS BASES DE DATOS (DIRECTORIOS) #################################################################### # Base de datos por defecto a usar ldbm database ldbm # Sufijo o raiz(root) del directorio. Es el nodo raiz superior # de nuestro directorio ldap suffix "dc=bulmalug, dc=net" # El nombre distinguido del directorio manager rootdn "cn=Manager, dc=bulmalug, dc=net" # No es muy buena idea guardar la contraseña en texto llano, # pero la dejaremos asi al principio hasta que controlemos mas sobre LDAP rootpw secret # Aqui es donde se guardara los datos del directorio directory /var/lib/ldap

Veamos lo que definimos con este fichero de configuración. Primeramente, la parte de

configuración global, donde le indicamos los schemas que queremos que siga OpenLDAP

por medio de la orden include. Definimos los ficheros dónde se guardarán el pid y los

argumentos con qué se ha llamado al programa con pidfile y argsfile y por último, en la

sección global, definimos los ACLs para la clave.

A continuación tenemos la definición de la base de datos que vamos a usar. Si queremos

tener más de una base de datos podemos añadir más sentencias como estas que vienen a

continuación. Veámoslas:

database ldbm: Con esto definimos, a parte del inicio de la configuración de la

base de datos, el tipo de base de datos que queremos usar. Lo normal es usar

ldbm, pero otras opciones son passwd y shell.

suffix "dc=bulmalug, dc=net": Con esto definimos la jerarquía que usaremos, o

sea, bulma.net.

rootdn "cn=Manager, dc=bulmalug, dc=net": Aquí definiremos quién va a ser el

usuario administrador de esta base de datos, es como el root de un sistema unix.

rootpw secret: Aquí definimos cual va a ser la clave de root, secret en este caso.

Vemos que aquí la clave está en modo texto plano, totalmente desaconsejada,

pero que, para hacer nuestras pruebas, nos sirve de momento. Después se debe

de cambiar a una clave encriptada con crypt, por ejemplo.

directory /var/lib/ldap: Directorio dónde se guardarán todos los datos del

directorio LDAP.

Si lo que quiere es usar otra jerarquía de internet, se puede cambiar las sentencias rootdn

a alguna que se adecue a vuestro caso, por ejemplo: "dc=eii,dc=us,dc=es".

Una vez que tenemos hecho todo esto, podemos proceder a lanzar el demonio. Lo normal

es lanzarlo a través de su script en /etc/init.d/, pero vamos a lanzarlo a mano hasta

comprobar que todo funciona bien. Lo hacemos con:

/usr/local/libexec/slapd -f /usr/local/etc/openldap/slapd.conf

Esto lanzará el servidor en modo demonio, pero podemos añadirle la opción "-d n", para

obtener el debug por pantalla, siendo n el nivel de debug que queremos.

Para comprobar que el servidor está funcionando, ejecutamos el siguiente comando:

$ ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts

lo que debe devolver debe ser algo parecido a:

dn: namingContexts: dc=bulmalug,dc=net

Si has obtenido algo parecido a eso, es que el servidor está funcionando correctamente y

ya podemos agregar las entradas iniciales al directorio.

La primera que vamos a añadir es la que va a sostener toda la estructura de los usuarios. O

sea, vamos a añadir una organización a la base de datos. Esta organización la

llamaremos bulma y estará sobre "dc=bulmalug,dc=net".

Todo el intercambio de datos con LDAP se hace con unos ficheros con un formato

especial. Este formato es el LDIF, LDAP interchange format El fichero que utilizaremos

para añadir la entrada original será este, llamemosle prueba.ldif:

####################################

dn: dc=bulmalug,dc=net objectclass: dcObject objectclass: organization o: bulma dc: bulmalug dn: cn=Manager,dc=bulmalug,dc=net objectclass: organizationalRole cn: Manager ####################################

Lo añadiremos al directorio con el comando siguiente, que nos pedirá la clave del

Manager:

$ ldapadd -x -D "cn=Manager,dc=bulmalug,dc=net" -W -f prueba.ldif

Una vez hecho esto ya podemos añadir el resto de datos al ldap. Una vez añadidos los

datos, que veremos en la siguiente sección, podemos comprobarlos con este comando:

$ ldapsearch -x -b 'dc=bulmalug,dc=net' '(objectclass=*)'

Este comando nos tiene que devolver una salida en formato LDIF con todos los datos en

que están en el directorio.

Configuración del servidor en modo seguro

Hasta ahora lo que hemos hecho ha sido configurar un servidor OpenLDAP para que

funcione por el puerto estándar, es decir, el puerto 389, que realiza las conexiones sin

cifrar. Para configurar el servidor en modo seguro, debemos tenerlo funcionando

correctamente por el puerto 389, tal y como hemos explicado en los apartados anteriores,

así como asegurarnos de que fue compilado con soporte OpenSSL.

OpenLDAP tiene dos formas de comunicación segura, SSL y TLS. SSL opera en otro puerto,

el 636 y, desde el principio, realiza las comunicaciones encriptadas en modo seguro. TLS,

por contra, es una solución más moderna que utiliza el puerto estándar 389 para iniciar las

comunicaciones y que, después, cambia a modo seguro a través del citado puerto 636.

Es conveniente tener los dos tipos activados, ya que no todas las aplicaciones cliente

soportan este método, e incluso hay aplicaciones que no soportan las transmisiones

seguras. Para las transmisiones seguras hace falta un certificado en formato PEM para la

llave SSL. Normalmente, se necesitaría que una organización dedicada a generar

certificados nos proporcionase una, pero como, normalmente, el OpenLDAP lo vamos a

usar en la red local, no a través de internet, ni para hacer comercio electrónico, basta con

que la generemos nosotros mismos. Para generar el certificado, debemos irnos al

directorio /usr/share/ssl/certs y allí ejecutar el comando:

# make slapd.pem

Esto nos creará un certificado, con lo que nos irá preguntando: Nombre del equipo, e-mail

del administrador, Organización, etc. Esto es, simplemente, la ejecución de un archivo

makefile que lo que hace es llamar a varias utilidades para generarlo. Si lo queremos hacer

a mano podemos hacer lo siguiente:

# /usr/bin/openssl req -newkey rsa:1024 -keyout temporal1 -nodes -x509 -days 365 -out temporal2 # cat temporal1 > slapd.pem # echo "" >> sldap.pem # cat temporal2 >> slapd.pem # rm -f temporal1 temporal2

Este comando crea una llave que se firma por sí misma. Esto no es lo normal en los

certificados seguros, pero, como hemos dicho, no pasa nada, ya que somos nosotros los

que vamos a utilizar estos en la red local privada. (Aunque siempre se puede confiar en

un Certification Authority, previo pago, claro).

Esta llave tiene que ser de sólo lectura para el usuario que ejecuta openldap. Si cualquier

otro usuario tiene acceso a esta llave, la seguriddad puede quedar comprometida.

Para configurar el servidor OpenLDAP para que utilice la llave correspondiente, tenemos

que editar el fichero /usr/local/etc/openldap/slapd.conf y añadir estas tres lineas:

TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /usr/share/ssl/certs/slapd.pem TLSCertificateKeyFile /usr/share/ssl/certs/slapd.pem

Llegados a este punto, ya podemos reiniciar el servidor OpenLDAP para que utilice el

puerto seguro. Para ello, llamamos a slapd con el parámetro -h de esta forma:

# /usr/local/libexec/slapd -h '"ldap:/// ldaps:///"'

La opción -h le indica a OpenLDAP que tipo de transmisión queremos hacer, normal,

segura o ambas. Teóricamente, cuando comprobemos que funciona en modo seguro,

podemos cerrar el puerto inseguro, ejecutando slapd con -h "ldaps:///" solamente. Para

comprobar que tenemos el servidor escuchando en el puerto podemos hacer varias cosas:

$ netstat -a |grep LISTEN

para ver los puertos de escucha y podemos ejecutar esta orden de openssl para ver el

certificado que tengamos en el puerto 636 (openLDAP seguro):

$ openssl s_client -connect localhost:636 –showcerts

con lo que nos tiene que salir por pantalla los datos relativos al certificado que hemos

creado. Con esto ya tenemos constancia de que el servidor LDAP está funcionando en

modo seguro. Ahora sólo queda configurar los clientes Linux para que la autentificación la

hagan a través del directorio LDAP en vez de en modo local con /etc/passwd, utilizando

tanto el modo seguro como el no seguro.

El Objetivo del Proyecto

Hemos descrito todo lo anterior solo para poder realizar la migración desde un servidor

con Sistema Operativo basado en Windows Server (nosotros seleccionamos Windows

2003 Server Standart Edition) hacia un servidor con Sistema Operativo basado en Linux

(que según el requerimiento especificado es el Debian 6).

Para lograr nuestro objetivo, se debe tener configurado el servidor Windows Server con

las condiciones idóneas, es decir, con la capacidad manejar un dominio (que en nuestro

caso hemos decido labunefa.edu.ve) y con el servicio o programa Active Directory

instalado y con varios usuarios establecidos o almacenados. Se debe obtener la

información antes descrita en un archivo para poder realizar la migración hacia el servidor.

Luego de obtener dicho archivo, es necesario llevarlo hacia el servidor con Debian 6, con

el sistema OpenLDAP ya instalado como se describió en los puntos anteriores, y realizar la

instalación requerida para realizar el reemplazo de los servidores.

Consideraciones que se han de tener en cuenta

El principal escollo con el que nos vamos a encontrar a la hora de migrar datos ente

ambos sistemas es la obtención de contraseñas del Active Directory. Aunque OpenLDAP y

Active Directory son implementaciones del protocolo LDAP, son muy distintas entre sí a la

hora de persistir las contraseñas. Mientras que OpenLDAP guarda la contraseña, a no ser

que se indique lo contrario, como un atributo más de un usuario (encriptada por

supuesto), Active Directory almacena esta información en la base de datos del SAM

(Security Account Manager) encriptada con el algoritmo Lan Manager, por lo que al

consultar la información de un usuario con un cliente LDAP no aparecerá dato alguno

sobre la contraseña y habrá que recurrir a otras herramientas para su obtención.

Cómo configurar un OpenLDAP

Cómo se ha mencionado anteriormente las contraseñas en Active Directory se

almacenan encriptadas con LanManager, así que el principal esfuerzo, a la hora de

configurar OpenLDAP, será dar soporte a dicho algoritmo de hashing. De este modo

cuando un usuario intente autenticarse, nuestro sistema deberá ser capaz de encriptar

con dicho algoritmo la contraseña que proporcione el usuario y comprobar si se

corresponde con el hash almacenado para él. Para que nuestro Open LDAP sea capaz de

realizar dicha tarea será necesario compilar los fuentes con la opción --enable-

lmpasswd. A continuación se especifica cómo realizar esta tarea sobre Debian:

1. Instalar en nuestro entorno los paquetes necesarios para llevar a cabo labores de construcción/compilación: dev:~# aptitude install build-essential

2. Intalaremos las dependencias con Berkeley DB necesarias para OpenLDAP (utilizaremos paquetes para simplificar el proceso):

dev:~# aptitude install libdb4.4-dev openssl-dev

3. Ejecutaremos ldconfig para cargar las librerías compartidas (este paso podríamos obviarlo): dev:~# ldconfig

4. Descargaremos los fuentes y descomprimimos: dev:~/dowloads# wget ftp://ftp.OpenLDAP.org/pub/OpenLDAP/openldap-

release/openldap-<version>.tgz

dev:~/dowloads# tar -xzf openldap-<version>.tgz

5. Ahora procederemos a compilar la herramienta con las siguientes instrucciones: dev:~/dowloads/openldap-<version># ./configure --

prefix="/opt/openldap" --enable-lmpasswd

dev:~/dowloads/openldap-<version># make depend

dev:~/dowloads/openldap-<version># make

dev:~/dowloads/openldap-<version># make test

dev:~/dowloads/openldap-<version># make install

Ya tenemos instalado servidor de LDAP en el directorio /opt/openldap y sólo nos

quedará configurarlo según nuestras necesidades. A continuación se establecerá una

configuración básica con la que poder probar la autenticación.

1. Editaremos el fichero slapd.conf (/opt/openldap/etc/openldap/slapd.conf) en

el que se modificarán las siguientes entradas:

include /opt/openldap/etc/openldap/schema/core.schema

include /opt/openldap/etc/openldap/schema/cosine.schema

include /opt/openldap/etc/openldap/schema/nis.schema

suffix "o=mrpotatoe,c=es"

rootdn "cn=admin,o=mrpotatoe,c=es"

rootpw admin

2. Ahora crearemos un fichero ldif (/tmp/carga.ldif) en con algunos datos a

persistir:

dn: o=mrpotatoe,c=es

objectclass: organization

o: mrpotatoe

dn: cn=admin,o=mrpotatoe,c=es

objectclass: organizationalRole

cn: admin

# En este punto crearíamos un usuario con la contraseña

12345678

# encriptada con lan manager para la realización de pruebas

dn: cn=user,o=mrpotatoe,c=es

objectClass: top

objectClass: account

objectClass: posixAccount

cn: user

gidNumber: 0

homeDirectory: -

uid: user

uidNumber: 0

userPassword:{lanman}0182BD0BD4444BF836077A718CCDF409

3. Lo próximo será iniciar el servidor e introducir los datos necesarios para realizar las

pruebas, para ello tendremos que ejecutar el siguientes comando:

dev:~# su -c /opt/openldap/libexec/slapd

dev:~# /opt/openldap/bin/ldapadd -xcWD 'cn=admin,o=mrpotatoe,c=es'

-f /tmp/carga.ldif

4. Una vez llegados a este punto podremos probar a autenticarnos contra nuestro

openldap con el usuario de prueba que hemos creado. Para ello podremos utilizar

cualquier cliente de LDAP.

Algunas herramientas útiles

A continuación se enumeran algunas herramientas para migrar usuarios de Directorio

Activo a OpenLDAP:

PwDump: Esta utilidad permite extraer las contraseñas en LM y en NTLM de los

usuarios de un sistema SAM. Esta herramienta nos será útil para obtener las

contraseñas de los usuarios de un directorio activo.

Apache Directory Studio: Se trata de un cliente LDAP bastante potente que nos

permitirá, además de navegar y consultar un LDAP, editar ficheros LDIF, crear y

editar esquemas para OpenLDAP y Apache Directory Server, utilizar un Apache

Directory Server embebido, etc.

Conclusión

La información que se suele guardar en un directorio está formada por entradas. Cada

entrada es un conjunto de atributos (información) que se identifica a través de un nombre

distinguido, DN, Distished name en inglés. Cada uno de estos atributos es de un tipo

concreto y puede tener uno o varios valores. Estos atributos suelen ser nemónicos como

por ejemplo cn (common name) o mail que indicaría el nombre o email de una entrada en

el directorio.

La información se almacena en el directorio en forma de árbol jerárquico.

Tradicionalmente se almacenaban utilizando como raíz los distintos países, siendo los

hijos las distintas provincias, e hijos de estos las distintas organizaciones o compañías que

podía haber en una provincia. También se puede utilizar la jerarquía de internet para

definir la estructura de un directorio LDAP utilizando, por ejemplo, los nombres de

dominio. Así, la raíz podría ser net, un hijo, bulmalug y dentro de este los diversos

usuarios que pudiera tener, etc.

LDAP posee un atributo, objectClass, que permite definir qué datos van a ser obligatorios y

cuales opcionales a través de los esquemas (schemas). O sea, los esquemas van a ser

como definiciones de los datos que va a contener el directorio. OpenLDAP incluye varios

esquemas, pero podremos añadir o modificar los ya existentes para cumplir con nuestras

necesidades.

El acceso a la información del directorio, se hace a través de los nombres distinguidos, DN,

y de los RND, nombres distinguidos relativos. Estos se construyen a partir de una entrada,

concatenándole el DN de todos sus padres. Por ejemplo, para el ejemplo de bulma,

imaginemos que tenemos un autor que tiene de uid autor1, su DN sería "uid=autor1,

ou=autores, dc=bulmalug, dc=net". Para encontrar más información sobre el formato DN,

puedes consultar el RFC2253.

OpenLDAP permite, además, definir ACL (access control lists) para el acceso a los datos,

aparte de que permite transmitir los datos sobre una capa segura como OpenSSL. Así

mismo, OpenLDAP permite la replicación de los datos entre varios servidores OpenLDAP

para descongestionar los servidores.