Una Introducción a LDAP

Michael Donnelly

Si trabajas en la industria informática, hasta ahora has oído hablar de buenas oportunidades de LDAP. Te preguntas de qué va toda esa novedad ? Quieres saber un poco más acerca de la tecnología subyacente? Has venido al lugar adecuado. En esta introducción - la primera en una serie de artículos describiendo como diseñar, implementar, e integrar un entorno LDAP en tu empresa - te familiarizarás con los conceptos que hay tras LDAP mientras que se dejan los detalles duros del núcleo del asunto para más tarde. Aquí trataremos los siguientes asuntos;

• Qué es LDAP, en cualquier caso?
• Cuando deberías utilizar LDAP para almacenar tus datos?
• La estructura de un árbol de directorio LDAP
• Registros individuales LDAP
• Personalizando las clases de objetos (object classes) de tu directorio
• Un ejemplo de una entrada individual LDAP
• Replicación LDAP
• Seguridad y control de acceso

Espera, me diras. Ya estás utilizando una base de datos Oracle, Sybase, Informix, o Microsoft SQL para almacenar mucha de esa misma información. ¿ Qué tiene de diferente LDAP? ¿ Qué lo hace mejor? Sigue leyendo.
 

De cualquier manera, qué es LDAP ?

El Protocolo de Acceso Ligero a Directorio, mejor conocido como LDAP (por sus siglas en inglés), está basado en el estándar X.500, pero significativamente más simple y más realmente adaptado para satisfacer las necesidades del usuario. A diferencia de X.500 LDAP soporta TCP/IP, que es necesario para el acceso a Internet. El núcleo de las especificaciones LDAP está totalmente definido en las RFCs -- una lista completa de las RFCs relacionadas se puede encontrar en la página LDAPman RFC.
 

Utilizando "LDAP" en una frase
En una conversación de cualquier día, oirás que gente bien intencionada dice cosas como, "¿ Deberíamos almacenarlo en LDAP ?" o "Simplemente obtén los datos de la base de datos LDAP", o "¿ Cómo hacemos para enlazar LDAP con una RDB (Base de Datos Relacional en ingles) ?". Hablando estrictamente, piensa, LDAP no es una base de datos en absoluto, sino un protocolo utilizado para acceder a información almacenada en un directorio de información (también conocido como un directorio LDAP). Una formulación más precisa se podría parecer a algo como esto: "Utilizando LDAP, los datos serán recuperados (o almacenados en) la localización correcta dentro de nuestro directorio de información." Pero no me encontrarás corrigiendo a nadie en este punto: de otro modo, te harás una idea a lo largo de este punto, y eso es lo que cuenta.

¿ Es un directorio de información LDAP una base de datos ?
Así como un Sistema de Gestión de Base de Datos (DBMS por sus siglas en ingles) como Sybase, Oracle, Informix o Microsoft se utiliza para procesar consultas y actualizaciones a una base de datos relacional, un servidor LDAP es utilizado para procesar consultas y actualizaciones a un directorio de información LDAP. En otras palabras, un directorio de información LDAP es un tipo de base de datos, pero no es una base de datos relacional. Y a diferencia de una base de datos que está diseñada para procesar cientos o miles de cambios por minuto - como los sistemas de Procesamiento de Transacciones En Linea (OLTP por sus siglas en ingles) a menudo utilizados en el e-commerce - los directorios LDAP están fuertemente optimizados para el rendimiento en lectura.

Las ventajas de los directorios LDAP
Ahora que nos hemos "enderezado", ¿ cuales son las ventajas de los directorios LDAP ? La actual popularidad de LDAP es la culminación de un numero de factores. Te daré unas pocas razones básicas, con tal que tengas en mente que es solo una parte de la historia.

Tal vez la mayor ventaja de LDAP es que tu empresa puede accedes al directorio LDAP desde casi cualquier plataforma de computación, desde cualquier del numero creciente de aplicaciones fácilmente disponibles para LDAP. Es también fácil personalizar tus aplicaciones internas de empresa para añadirles soporte LDAP.

El protocolo LDAP es utilizable por distintas plataformas y basado en estándares, de ese modo las aplicaciones no necesitan preocuparse por el tipo de servidor en que se hospeda el directorio. De hecho, LDAP esta encontrando mucha más amplia aceptación a causa de ese estatus como estandard de Internet. Los vendedores están más deseosos de codificar en sus productos integración con LDAP por que no tienen que preocuparse de lo que hay al otro lado. Tu servidor LDAP puede ser cualquiera de un numero de los servidores de directorio LDAP de código abierto o comercial ( o incluso un servidor DBMS con una interfaz LDAP), puesto que interactuar con cualquier servidor LDAP verdadero acarrea el mismo protocolo, paquete de conexión cliente y comandos de consulta. Por contraste, los vendedores que intentan integrar directamente con un DBMS habitualmente deben personalizar sus productos para trabajar con cada servidor de base de datos de cada vendedor individualmente.

A diferencia de las bases de datos relacionales, no tienes que pagar por cada conexión de software cliente o por licencia.

La mayoría de los servidores LDAP son simples de instalar, fácilmente mantenibles, y fácilmente optimizables.

Los servidores LDAP pueden replicar tanto algunos de sus datos como todos a través de métodos de envío o recepción, lo que permite enviar datos a oficinas remotas, incrementar tu seguridad y demás. La tecnología de replicación está incorporada y es fácil de configurar. Por contraste, muchos de los vendedores de DBMS cobran un extra por esta característica, y es bastante más difícil de gestionar.

LDAP te permite delegar con seguridad la lectura y modificación basada en autorizaciones según tus necesidades utilizando ACIs (colectivamente, una ACL, o Lista de Control de Acceso por sus siglas en inglés). Por ejemplo, tu grupo de facilidades puede dar acceso a cambiar la localización de los empleados, su cubículo, o número de oficina, pero no se permite que se modifiquen entradas de cualquier otro campo. Las ACIs pueden controlar el acceso dependiendo de quien está solicitando los datos, que datos están siendo solicitados, dónde están los datos almacenados, y otros aspectos del registro que está siendo modificado. Todo esto hecho directamente a través del directorio LDAP, así que no necesitas preocuparte de hacer comprobaciones de seguridad en el nivel de aplicación de usuario.

LDAP es particularmente utilizable para almacenar información que desees leer desde muchas localizaciones, pero que no sea actualizada frecuentemente. Por ejemplo, tu empresa podría almacenar todos los datos siguientes en un directorio LDAP:

• La listín de teléfonos de empleados de la empresa y el esquema organizacional
• Información de contacto de clientes externos
• Información de la infraestructura de servicios, incluyendo mapas NIS, alias de email, y demás
• Información de configuración para paquetes de software distribuidos
• Certificados públicos y claves de seguridad

La mayoría de los servidores LDAP están fuertemente optimizados para operaciones de lectura intensivas. A causa de esto, típicamente uno puede ver un orden de magnitud diferente cuando lee datos de un directorio LDAP frente a la obtención de los mismos datos de una base de datos relacional optimizada para OLTP. Sin embargo, a causa de esta optimización a la mayoría de los directorios LDAP no les viene bien el almacenamiento de datos donde los cambios son frecuentes. Por ejemplo, un servidor de directorio LDAP es bueno para almacenar el directorio de teléfonos internos de la empresa, pero ni se te ocurra pensar en utilizarlo como repositorio de base de datos para un sitio de comercio electrónico de alto volumen.

Si las respuestas a cada una de las siguientes preguntas es Sí, entonces, almacenar tus datos en LDAP es una buena idea.

• Te gustaría que tus datos estén disponibles a través de varias plataformas?
• Necesitas acceso a estos datos desde un número de ordenadores o aplicaciones?
• Los registros individuales que estás almacenado cambian unas pocas veces al día o menos, como medía?
• Tiene sentido almacenar este tipo de datos en una base de datos plana en lugar de una base de datos relacional? Esto es, puede almacenar todos los datos, para un item dado, efectivamente en un solo registro?

La estructura de un árbol de directorio LDAP

Los servidores de directorio LDAP almacenan sus datos jerárquicamente. Si has visto las reresentaciones de árboles DNS descendientes o directorios de ficheros UNIX, una estructura de directorio LDAP te será un terreno familiar. Como con los nombres de host en DNS, un registro Nombre Distinguido (Distinguished Name en ingles, DN en corto) de un directorio LDAP se lee desde su entrada individual, recursivamente a través del árbol, hasta el nivel más alto. Más sobre este punto después.

¿ Porque seccionarlas dentro de una jerarquía ? Hay un número de razones. He aquí algunos escenarios posibles:

• Puedes querer enviar todos tus contactos de clientes con base en US a un servidor LDAP en la oficina de Seattle (que esta dedicada a ventas), mientras que probablemente no necesites enviar allí la información de gestión de los activos de la empresa.
• Puedes querer conceder permisos a un grupo de individuos basado en la estructura del directorio. En el ejemplo listado abajo, el equipo de gestión de activos de la empresa puede necesitar acceso completo a la sección activos-gest, pero no a otras áreas.
• Combinado con replicación, puedes hacer a la medida la expansión de tu estructura de directorio para minimizar la utilización de ancho de banda de tu WAN. Tu oficina en Seattle puede necesitar actualizaciones al minuto de los contactos de ventas en US, pero solo actualizaciones cada hora para la información de ventas Europeas.

o="FooBar, Inc.", c=US
(DN base en formato  X.500)
En este ejemplo, o=FooBar,inc. se refiere a la organización, que en este contexto debería ser tratada como un sinónimo del nombre de la empresa. c=US indica que el cuartel general de la empresa está en los US. Erase una vez en que éste fue el método de especificar tu DN base. Los tiempos y las modas cambian, sin embargo; estos días, la mayoría de las empresas están (o planean estar) en Internet. Y con la globalización de Internet, utilizar un código de país en el base DN probablemente haga las cosas más confusas al final. Con el tiempo, el formato X.500 ha evoluciado a otros formatos listados más abajo.

o=foobar.com
(DN base derivado de la presencia en Internet de la empresa)
Este formato es bastante sencillo, utilizando el nombre de dominio de la empresa como base. Una vez has pasado la porción o= (la cual viene de organization= ), cualquiera en tu empresa debería saber de dónde viene el resto. Este fue, hasta hace poco, probablemente el más común de los formato usados actualmente.

dc=foobar, dc=com
(DN base derivado de los componentes de dominio DNS de la empresa)
Como el formato previo, este utiliza el nombre de dominio DNS como su base. Pero donde el otro formato deja en nombre de dominio intacto (y así legible para las personas), este formato está separado en componentes de dominio: foobar.com deviene dc=foobar, dc=com. En teoría, esto puede ser levemente más versátil, aunque es un poco más duro de recordar para los usuarios finales. A modo de ilustración, consideremos foobar.com. Cuando foobar se fusiona con gizmo.com, simplemente empiezas a pensar en "dc=com" como el DN base. Pon los nuevos registros en tu directorio existente bajo dc=gizmo, dc=com y listo para seguir. (Por supuesto, esta aproximación no ayuda si foobar.com se fusiona con wocket.edu) Este es el formato que recomiendo para cualquier instalación nueva. Oh, si estás planeando utilizar Active Directory, Microsoft ya ha decidido por ti que éste es el formato que necesitas.

Tiempo de ramificar: Cómo oraganizar tus datos en tu árbol de directorio
En un sistema de ficheros UNIX, el nivel más alto es el raíz. Por debajo de la raíz tienes muchos ficheros y directorios. Como mencione anteriormente los directorios LDAP están configurados en gran parte de la misma manera.

Debajo de tu base de directorio, querrás crear contenedores que separen lógicamente tus datos. Por razones históricas (X.500), la mayoría de los directorios configuran estas separaciones lógicas como entradas OU. OU vienen de "Unidades Organizacionales" (Organizational Units, en ingles), que en X.500 eran utilizadas para indicar la organización funcional dentro de la empresa: ventas, finanzas, etcétera. Actualmente las implementaciones de LDAP han mantenido la convención del nombre ou=, pero separa las cosas por categorías amplias como ou=gente (ou=people), ou=grupos (ou=groups), ou=dispositivos (ou=devices), y demás. Los niveles inferiores de OUs son utilizados a veces para separar categorías por debajo más lejos. Por ejemplo, un árbol de directorio LDAP (sin incluir entradas individuales) podría parecerse a esto:

    dc=foobar, dc=com 
        ou=customers 
            ou=asia 
            ou=europe 
            ou=usa 
        ou=employees 
        ou=rooms 
        ou=groups 
        ou=assets-mgmt 
        ou=nisgroups 
        ou=recipes

¿ Qué hay en un nombre ? El DN de una entrada LDAP
Todas las entradas almacenadas en un directorio LDAP tienen un único "Distinguished Name," o DN. El DN para cada entrada está compuesto de dos partes: el Nombre Relativo Distinguido (RDN por sus siglas en ingles, Relative Distinguished Name) y la localización dentro del directorio LDAP donde el registro reside.

El RDN es la porción de tu DN que no está relacionada con la estructura del árbol de directorio. La mayoría de los items que almacenas en un directorio LDAP tendrá un nombre, y el nombre es almacenado frecuentemente en el atributo cn (Common Name). Puesto que casi todo tiene un nombre, la mayoría de los objetos que almacenarás en LDAP utilizarán su valor cn como base para su RDN. Si estoy almacenando un registro para mi receta favorita de comida de avena, estaré utilizando cn=ComidaDeAvena Deluxe como el RDN de mi entrada.

• El DN base de mi directorio es dc=foobar,dc=com
• Estoy almacenando todos los registros LDAP para mis recetas en ou=recipes
• El RDN de mi registro LDAP es cn=Oatmeal Deluxe

cn=ComidaDeAvena Deluxe,ou=recipes,dc=foobar,dc=com

Las personas son siempre más problemáticas que los objetos inanimados
Ahora es el momento de abordar el DN de un empleado de una empresa. Para las cuentas de usuario, típicamente verás un DN basado en el cn o en el uid (ID del usuario). Por ejemplo, el DN del empleado de FooBar, Fran Smith (nombre de login: fsmith) puede parecerse a uno de estos dos formatos:

uid=fsmith,ou=employees,dc=foobar,dc=com
(basado en el login)
LDAP (y X.500) utilizan uid para significar "ID del usuario", no se debe confundir con el numero uid de UNIX. La mayoría de las empresas intentar dar a cada uno un nombre de login, así esta aproximación hace que tenga sentido el almacenar información sobre los empleados. No tienes que preocuparte sobre que harás cuando contrates al próximo Fran Smith, y si Fran cambia su nombre (¿se casa? se divorcia? ¿tiene una experiencia religiosa?), no tienes que cambiar el DN de la entrada LDAP.

cn=Fran Smith,ou=employees,dc=foobar,dc=com
(basado en el nombre)
Aquí vemos la entrada Nombre Común (CN por sus siglas en ingles) utilizada. En el caso de un registro LDAP para una persona, piense en el nombre común como sus nombres completos. Uno puede ver fácilmente lo colateral de esta aproximación: si el nombre cambia, el registro LDAP debe "moverse" de un DN a otro. Como se indica anteriormente, debes evitar cambiar en DN de una entrada siempre que sea posible.

Personalizando las clases de objeto de tu directorio

Tu puedes utilizar LDAP para almacenar datos en casi cualquier tipo de objetos, mientras que el objeto pueda ser descrito en términos de varios atributos. Aquí hay algunos ejemplos de información que puedes almacenar:

• Empleados: ¿ Cual es el nombre completo del empleado, nombre de login, contraseña, número de empleado, login de su gerente, servidor de correo ?
• Seguimiento de "activos": ¿ cual es el nombre de la computadora, dirección IP, etiqueta del activo, información de marca y modelo, localización física ?
• Listas de contacto de clientes: ¿ Cual es el nombre de la empresa del cliente? ¿ Primer teléfono de contacto, fax, e información de correo electrónico ?
• Información de la sala de reuniones: ¿ Cual es el nombre de la habitación, localización, capacidad en asientos, número de teléfono ? ¿ Hay acceso para silla de ruedas? ¿ Hay un proyector?
• Información de recetas: Nombre que se le da al plato, la lista de ingredientes, el tipo de cocina, y las instrucciones para prepararlo.

Los directorios LDAP almacenan toda la información para unas entradas dadas de registros como una series de pares de atributos, cada una consistente en un tipo de atributo y un valor de atributo. (Esto es completamente diferente a la manera en que los servidores de bases de datos relacionales almacenan datos, en columnas y filas.) Considera esta porción de mi registro de receta, como se almacena en un directorio LDAP:

  dn: cn=ComidaDeAvena Deluxe, ou=recipes, dc=foobar, dc=com 
  cn: Comida de avena instantánea Deluxe 
  recipeCuisine: desayuno 
  recipeIngredient: 1 paquete de comida de avena instantánea 
  recipeIngredient: 1 tazón de agua 
  recipeIngredient: 1 pizca de sal 
  recipeIngredient: 1 tsp de azúcar marrón 
  recipeIngredient: 1/4 de manzana, de cualquier tipo

A causa de que los datos son almacenado de este modo, la forma de la base de datos es completamente fluida - no necesitas recrear una tabla de base de datos (y todos sus índices) para empezar a seguir un nuevo trozo de datos. Aún más importante, los dorectorios LDAP no utilizan memoria o almacenamiento para manejar campos "vacíos" - de hecho, tener campos opcionales no utilizados no te supone ningún coste en absoluto.

Un ejemplio de una entrada individual LDAP

Miremos un ejemplo. Utilizaremos el registro de LDAP de Fran Smith, nuestro amigable empleado de Foobar, Inc. El formato de esta entrada es un LDIF, el formato utilizado cuando exportamos e importamos entradas del directorio LDAP.

  dn: uid=fsmith, ou=employees, dc=foobar, dc=com
  objectclass: person
  objectclass: organizationalPerson
  objectclass: inetOrgPerson
  objectclass: foobarPerson
  uid: fsmith
  givenname: Fran
  sn: Smith
  cn: Fran Smith
  cn: Frances Smith
  telephonenumber: 510-555-1234
  roomnumber: 122G
  o: Foobar, Inc.
  mailRoutingAddress: fsmith@foobar.com
  mailhost: mail.foobar.com
  userpassword: {crypt}3x1231v76T89N
  uidnumber: 1234
  gidnumber: 1200
  homedirectory: /home/fsmith
  loginshell: /usr/local/bin/bash

Separemos esta entrada y observemosla pieza a pieza.

  dn: uid=fsmith, ou=employees, dc=foobar, dc=com

  objectclass: person 
  objectclass: organizationalPerson 
  objectclass: inetOrgPerson 
  objectclass: foobarPerson

  uid: fsmith 
  givenname: Fran 
  sn: Smith 
  cn: Fran Smith 
  cn: Frances Smith 
  telephonenumber: 510-555-1234 
  roomnumber: 122G 
  o: Foobar, Inc.

Date cuenta que hay múltiples entradas para el CN. Como se mencionó anteriormente, LDAP permite que algunos atributos tengan valores múltiples, con el número de valores sean arbitrarias. ¿ Cuando puedes querer esto ? Digamos que estás buscando en el directorio LDAP de la empresa el número de teléfono de Fran. Mientras que tu puedes conocerla como Fran (habiendola oido derramar sus tripas sobre las margaritas del almuerzo en más de una ocasión), la gente en RRHH pueden referirse a ella (algo más formalmente) como Frances. A causa de que ámbas versiones de su nombre están almacenadas, las dos búsquedas encontrarán exitosamente el número de teléfono de Fran, su dirección de correo electrónico, el número de su cubículo, y demás.

  mailRoutingAddress: fsmith@foobar.com 
  mailhost: mail.foobar.com

  userpassword: {crypt}3x1231v76T89N 
  uidnumber: 1234 
  gidnumber: 1200 
  gecos: Frances Smith 
  homedirectory: /home/fsmith 
  loginshell: /usr/local/bin/bash

  periodic pull: ou=asia,ou=customers,o=sendmail.com
  periodic pull: ou=us,ou=customers,o=sendmail.com
  immediate push: ou=europe,ou=customers,o=sendmail.com