Preparación para el examen 301 del LPI, Tema 301: Conceptos, arquitectura y diseño

Nivel Senior de Linux Professional (LPIC-3)

En este tutorial, Sean Walberg lo ayuda a prepararse para la certificación ® de nivel senior de Linux Professional (LPIC-3) del Linux Professional Institute. En este primer tutorial de una serie de seis, Sean presenta los conceptos, la arquitectura y el diseño del Lightweight Directory Access Protocol (LDAP). Con este tutorial, aprenderá sobre los conceptos y la arquitectura, el diseño del directorio y los esquemas del LDAP.

Sean A. Walberg, Senior Network Engineer

Author photoSean Walberg ha trabajado con los sistemas Linux y UNIX desde 1994 en entornos académicos, corporativos, y de proveedores de servicios de Internet. Ha escrito bastante sobre la administración de sistemas en los últimos años. Usted puede contactarse con el en sean@ertw.com.



15-07-2011

Antes de comenzar

Aprenda lo que pueden enseñarle estos tutorials y cómo aprovecharlos al máximo.

Sobre estas series

El Linux Professional Institute (LPI) certifica a los administradores de sistemas Linux en tres niveles: nivel junior (también denominado "nivel de certificación 1"), nivel avanzado (también denominado "nivel de certificación 2"), y nivel senior (también denominado "nivel de certificación 3"). Para alcanzar el nivel de certificación 1, debe pasar los exámenes 101 y 102. Para obtener el nivel de certificación 2, debe aprobar los exámenes 201 y 202. Para lograr el nivel de certificación 3, debe tener una certificación activa de nivel avanzado y aprobar el examen 301 ("principal"). También debe pasar los exámenes de especialidad adicionales en el nivel senior.

developerWorks le ofrece tutorials para ayudarlo a prepararse para los cinco exámenes de certificación junior, advanzada, y senior. Cada examen abarca varios temas, cada tema tiene un tutorial de autoaprendizaje determinado en developerWorks. La Tabla 1 le muestra una lista de los seis temas y sus correspondientes tutorials de developerWorks para el examen 301 de LPI.

Tabla 1. Examen 301 de LPI: Tutorials y temas
Tema del examen 301 de LPITutorial de developerWorksResumen del tutorial
Tema 301Preparación para el examen 301 de LPI:
Conceptos, arquitectura, y diseño
(Este tutorial.) Aprenda sobre los conceptos y la arquitectura de LDAP, aprenda cómo diseñar e implementar un directorio de LDAP, y aprenda sobre los esquemas. Vea los objectivos en detalle a continuación.
Tema 302 Preparación para el examen 301 de LPI:
Instalación y desarrollo
Próximamente.
Tema 303 Preparación para el examen 301 de LPI:
Configuraión
Próximamente.
Tema 304 Preparación para el examen 301 de LPI:
Uso
Próximamente.
Tema 305 Preparación para el examen 301 de LPI:
Integración y migración
Próximamente.
Tema 306 Preparación para el examen 301 de LPI:
Planificación de capacidades
Próximamente.

Para aprobar el examen 301 (y obtener el nivel de certificación 3), debería:

  • Tener varios años de experiencia en la instalación y el mantenimiento de Linux® en varias computadoras para diferentes fines.
  • Tener experiencia en la integración con diversas tecnologías y sistemas operativos.
  • Tener experiencia profesional, o capacitación, en Linux profesional de nivel empresarial (incluyendo experiencia como parte de otro rol).
  • Conocer los niveles avanzado y empresarial de administración de Linux incluyendo la instalación, la administración, la seguridad, la localización de problemas, y el mantenimiento.
  • Ser capaz de utilizar herramientas de código abierto para medir problemas relacionados con la planificación de capacidad y los recursos para la localización de problemas.
  • Tener experiencia profesional en el uso de LDAP para integrar con servicios UNIX® y Microsoft® Windows®, incluyendo Samba, Pluggable Authentication Modules (PAM), correo electrónico, y el servicio de directorio de Microsoft Active Directory.
  • Ser capaz de planificar, diseñar, crear e implementar un entorno completo usando Samba y LDAP, así como medir la planificación de capacidad y la seguridad de los servicios.
  • Ser capaz de crear scripts en Bash o Perl, o tener conocimiento de al menos un lenguaje de programación de sistemas (como C).

El Linux Professional Institute no aprueba material o técnicas para la preparación de exámenes de ninguna tercera parte en particular.

Sobre este tutorial

Bienvenido a "Conceptos, arquitectura y diseño," el primero de seis tutorials diseñado para prepararlo para el examen 301 de LPI. En este tutorial, aprenderá sobre los conceptos y la arquitectura de LDAP, cómo diseñar e implementar un directorio LDAP, y sobre los esquemas.

Este tutorial está organizado según los objetivos de LPI para este tema. En líneas generales, espere más preguntas sobre las preguntas del examen relacionadas con los objetivos de mayor valor.

Objetivos

La Tabla 2 suministra los objetivos detallados para este tutorial.

Tabla 2. Conceptos, arquitectura, y diseño: los objetivos de examen que abarca este tutorial
Objetivo del examen de LPIValor del objetivoResumen del objetivo
301.1
Conceptos y arquitectura
3Familiarísese con los conceptos de LDAP y X.500.
301.2
Diseño del directorio
2Diseñe e implemente un directorio LDAP mientras planifica un árbol de información de directorio adecuado para evitar la redundancia. Debería conocer todos los tipos de datos que son apropiados para el almacenaje en un directorio LDAP.
301.3
Esquemas
3Familiarísese con los conceptos de los esquemas y los archivos de los esquemas de la base incluidos en una instalación de OpenLDAP.

Prerequisitos

Para aprovechar al máximo este tutorial, debería tener un conocimiento avanzado de Linux y un sistema Linux en funcionamiento en el que pueda practicar los comandos explicados aquí.

Si sus capacidades básicas de Linux están un poco oxidadas, quizá desee revisar primero los tutorials for the LPIC-1 and LPIC-2 exams.

Diferentes versiones de un programa pueden presentar de forma distinta sus datos de salida, de modo que sus resultados pueden no verse exactamente igual a los listados y figuras en este tutorial.

Requisitos de sistema

Para seguir con los ejemplos en estos tutorials, necesita una estación de trabajo de Linux con el paquete y soporte de OpenLDAP para PAM. La mayoría de las distribuciones modernas responden a estos requisitos.


Conceptos y arquitectura

Esta sección abarca material para el tema 301.1 del examen 301 del Senior Level Linux Professional(LPIC-3). Este tema tiene un valor de 3.

En esta sección, aprenda sobre:

  • Especificación técnica de LDAP y X.500
  • Definiciones de los atributos
  • Espacios de nombre de directorios
  • Distinguished names
  • LDAP Data Interchange Format
  • Meta-directorios
  • Operaciones Changetype

La mayoría de los exámenes LPIC-3 se centran en el uso de Lightweight Directory Access Protocol (LDAP). Como consecuencia, el primer objetivo se relaciona con la comprensión de lo que es LDAP, lo que hace, y la terminología básica relativa a este concepto. Cuando comprenda esto, podrá pasar al diseño del directorio e integrar sus aplicaciones con el directorio.

LDAP, ¿qué es?

Antes de hablar sobre LDAP, repasemos el concepto de directorio. El ejemplo clásico de un directorio es la agenda telefónica, en la cual aparecen las personas en orden alfabético junto con su número de teléfono y su dirección. Cada persona (o familia) representa un objeto, y el número de teléfono y dirección són atributos de ese objeto. Aunque no siempre resulta obvio a simple vista, algunos objetos son empresas en lugar de personas, y estas pueden incluir números de fax y horarios de trabajo.

A diferencia de su contraparte impresa, un directorio informático es jerárquico por naturaleza, lo que permite colocar los objetos bajo otros objetos para indicar una relación padre-hijo. Por ejemplo, la agenda telefónica podría ampliarse para tener objetos que representen áreas de la ciudad, cada una con objetos personas y empresas en los respectivos objetos área. Estos objetos de área entonces se ubicarían en un objeto ciudad, el cual se ubicaría en un objeto estado o provincia, etc, de modo similar a lo que se observa en la Figura 1. Esto haría una copia impresa mucho más dífícil de utilizar porque sería necesario conocer el nombre y la ubicación geográfica, pero las computadoras están hechas para ordenar información y buscar en varias partes del directorio, así que este no es un problema.

Figura 1. Un directorio de muestra
Un directorio de muestra

Al ver la Figura 1, sabiendo donde el registro de Simpson le dice más que simplemente la dirección y el número de teléfono. Usted también sabe que está en el extremo este del pueblo de Springfield. Esta estructura se denomina árbol. Aquí, la raíz del árbol es el objeto Springfield, y los diversos objetos representan niveles de branching.

Este enfoque basado en directorios para almacenar datos es bastante diferente a las bases de datos relacionales con la que está familiarizado. Para comparar los dos modelos, en la Figura 2 se muestra cómo se presentan los datos telefónicos si se modelan como una base de datos relacional.

Figura 2. Datos del directorio modelados en forma relacional
Datos del directorio modelados en forma relacional

En el modelo relacional, cada tipo de datos es una tabla separada que permite el manejo de diferentes tipos de información. Cada tabla también tiene un enlace a su tabla padre de modo que las relaciones entre los objetos puedan manejarse. Tenga en cuenta que las tablas tendrían que modificarse para agregar más campos de información.

Recuerde que nada sobre el modelo de directorio coloca ninguna restricción sobre el modo de almacenar los datos en el disco. De hecho, OpenLDAP soporta muchos backends incluyendo archivos flat y bases de datos Structured Query Language (SQL). Los mecanismos para el diseño de tablas en el disco se encuentran bien ocultos para usted. Por ejemplo, Active Directory proporciona una interfaz LDAP para su backend propietario.

La historia de LDAP

LDAP se ideó en Request for Comments (RFC) 1487 como una forma sencilla de acceder a un directorio X.500 en lugar del protocolo de acceso al directorio más complejo. (Consulte la sección Resources para acceder a los enlaces a esto y RFCs relacionados.) X.500 es un estandar (y una familia de estándares) desde la International Telecommunication Union (ITU, antiguamente CCITT) que especifica cómo los directorios se implementan. Usted quizá conozca el estandar X.509 que forma el núcleo de la mayoría de los certificados de Public Key Infrastructure (PKI) y Secure Sockets Layer (SSL). LDAP desde entonces ha evolucionado a la versión 3 y se define en RFC 4511.

La conexión a una base de datos X.500 en principio requería el uso de la suite de protocolos de Open Systems Interconnection (OSI),y , requería la comprensión de las pilas consistentes de documentación de protocolo. LDAP permitió a las redes basadas en Internet Protocol (IP) conectarse al mismo directorio con muchos menos ciclos de desarrollo que con el uso de protocolos OSI. Eventualmente la popularidad de las redes IP condujeron a la creación de servidores LDAP que soportan sólo la cantidad de conceptos X.500 necesaria.

A pesar del triunfo de LDAP y IP sobre X.500 y OSI, la organización subyacente de los datos del directorio es todavía X.500-ish. Los conceptos que aprenderás en este tutorial, como distinguished names e identificadores de objetos, se muestran desde X.500.

X.500 se ideó como una forma de crear un sistema de directorio global, en gran parte para ayudar con la serie de estándares de X.400 por correo electrónico. LDAP puede utilizarse como directorio global con algo de esfuerzo, pero generalmente se utiliza en una empresa.

Una mirada más profunda a los nombres y atributos

En el mundo de LDAP, los nombres son importantes. Los nombres le permiten acceder a registros y explorarlos, y a menudo el nombre brinda una indicación de dónde se encuentra el registro en el arbol LDAP. La Figura 3 muestra un típico árbol LDAP.

Figura 3. Un típico árbol LDAP que muestra un usuario
Un típico árbol LDAP que muestra un usuario

En la parte superior, o raíz, del árbol se encuentra una entidad denominada dc=ertw,dc=com. El dc es una abreviatura de domain component. Dado que ertw se encuentra bajo el dominio de nivel superior .com, los dos están separados en dos unidades diferentes. Los componentes de un nombre son enlazados con una coma cuando se utiliza la nomenclatura X.500, con los nuevos componentes agregados a la izquierda. Nada técnicamente le impide referirse a la raíz como dc=ertw.com, sin embargo en beneficio de la interoperabilidad futura es mejor tener los componentes de dominio por separado (de hecho, RFC 2247 recomienda los componentes de dominio por separado).

dc=ertw,dc=com es una forma excepcional de identificar esa entidad en el árbol. En el lenguaje de X.500, esto se denomina el distinguished name, o el DN. El DN se parece mucho a una clave primaria en el mundo de la base de datos relacional porque sólo puede haber una identidad con un DN determinado en el árbol. El DN de la entrada superior se denomina DN Raíz.

Bajo el DN raíz se encuentra un objeto con el DN de ou=people,dc=ertw,dc=com. ou significa organizational unit, y usted puede estar seguro de que se encuentra bajo la raíz DN porque la ou aparece inmediatamente a la izquierda del DN raíz. Usted puede además denominar ou=people al relative distinguished name, o RDN, porque es único en el nivel. En términos recursivos, el DN de una entidad es el RDN de la entidad más el DN del padre. La mayoría de los navegadores LDAP muestran sólo el RDN porque elimina la redundancia.

Moviendose hacia abajo en el árbol hacia cn=Sean Walberg,ou=people,dc=ertw,dc=com, usted encuentra el registro de una persona. cn significa common name. Por primera vez, sin embargo, un registro tiene algo de información adicional en la forma de atributos. Los atributos proporcionan información adicional sobre la entidad. De hecho, verá que el componente del extremo izquierdo del DN está duplicado; en este caso, es el atributo cn. En otras palabras, el RDN de una entidad está compuesta de uno (o más) atributos de la entidad.

Mientras mail y description son bastante fáciles de comprender, objectClass no es tan obvio. Una clase de objeto es un grupo de atributos que corresponde a un tipo de entidad en particular. Una clase de objeto puede contener atributos para personas y otros para cuentas UNIX. Aplicando los dos tipos de objetos a una entidad, ambos conjuntos de atributos están disponibles para ser almacenados.

A cada clase de objeto se le asigna un object identifier (OID) que únicamente lo identifica. La clase de objeto también especifica los atributos, y cuáles son obligatorios y cuáles opcionales. Los atributos obligatorios deben tener algunos datos para que la entidad sea almacenada. La clase de objeto también identifica el tipo de datos almacenados y si los múltiples atributos del mismo nombre son permitidos. Por ejemplo, una persona podría tener solamente un número de empleado pero múltiples primeros nombres (por ejemplo, Bob, Robert, y Rob).

Los objetos de nivel inferior no las únicas clases de objetos relacionadas con ellos. Estos objetos, denominados contenedores, también tienen clases de objetos y atributos. El people ou es del tipo organizationalUnit y tiene un atributo description junto con ou=people para crear el RDN. La raíz del árbol es del tipo dcObject y organization. Sabiendo qué clases de objetos asignar un objeto depende de qué se almacena en el objecto y bajo el mismo. Consulte la sección Schemas por más detalles.

El DN raíz también define el espacio de nombre del árbol o, para ser más técnico, el Directory Information Tree (DIT). Algo que termina en dc=ibm,dc=com quedaría fuera del espacio de nombre de la Figura 3, considerando el registro para Sean Walberg queda dentro del espacio de nombre. Teniendo esto en cuenta, sin embargo, es posible que un servidor LDAP contenga múltiples espacios de nombre. Un elemento de alguna forma abstracto denominado Root DSE contiene la información sobre todos los espacios de nombre disponibles en el servidor. DSE significa DSA-Specific Entry, y DSA significa Directory System Agent (que es, el servidor LDAP).

La Figura 4 resume la terminología asociada con el árbol LDAP.

Figura 4. Resumen de terminología LDAP
Resumen de terminología LDAP

Finalmente, un árbol LDAP puede sincronizarse con otros árboles o fuentes de datos. Por ejemplo, una rama del árbol podría venir desde un sistema de seguridad, otro desde una base de datos personalizada, y el resto podría almacenarse en el servidor LDAP. Esto se denomina meta-directorio y se pretende que sea una fuente única de datos para aplicaciones como registro único.

El archivo LDIF

Los datos pueden introducirse en un servidor LDAP de dos formas. Pueden cargarse por la red, usando el protocolo LDAP, o pueden importarse desde el servidor a través de un archivo en el LDAP Data Interchange Format (LDIF). LDIF puede utilizarse en cualquier momento, como para crear el árbol inicial, y para agregar espacio o modificar datos en algún momento más adelante. Los datos de salida de una búsqueda puede también encontrarse en LDIF para analizar gramaticalmente fácilmente o importarse a otro servidor. La especificación completa para LDIF se encuentra en RFC 2849 (vea Resources para encontrar el enlace).

Incorporación de registros

El LDIF que generó el árbol de la Figura 3 se muestra en el Listado 1.

Listado 1. Un archivo LDIF simple para poblar un árbol
# This is a comment
dn: dc=ertw,dc=com
dc: ertw
description: This is my company
 the description continues on the next line
 indented by one space
objectClass: dcObject
objectClass: organization
o: ERTW.COM

dn: ou=people,dc=ertw,dc=com
ou: people
description: Container for users
objectclass: organizationalunit

dn: cn=Sean Walberg,ou=people,dc=ertw,dc=com
objectclass: inetOrgPerson
cn: Sean Walberg
cn: Sean A. Walberg
sn: Walberg
homephone: 555-111-2222
mail: sean@ertw.com
description: Watch out for this guy
ou: Engineering

Antes de profundizar sobre los detalles del archivo LDIF, observe que los nombres de los atributos no son sensibles a las mayúsculas. Es decir, objectclass es lo mismo que objectClass y OBJECTCLASS. Mucha gente elije colocar en mayúscula la primera letra de cada palabra, salvo la primera, como objectClass, homePhone, y thisIsAReallyLongAttribute.

La primera línea del LDIF muestra un comentario de estilo UNIX, el cual tiene como prefijo un signo numeral (#), también conocido como signo de la unidad de peso libra o signo de número. LDIF es un archivo ASCII estandar y puede ser editado por humanos, así que los comentarios pueden ser útiles. Los comentarios son, sin embargo, ignorados por el servidor LDAP.

Los registros en el archivo LDIF están separados por una línea en blanco y contienen una lista de atributos y valores separados por dos puntos (:). Los registros comienzan con el atributo dn, el cual identifica el distinguished name del registro. La Figura 1, por lo tanto, muestra tres registros: Los RDNs dc=ertw, ou=people, y cn=Sean Walberg, respectivamente.

Eligiendo atributos

Los nombres de los atributos pueden ser confusos en este punto. ¿Cómo decidir qué clase de objeto asignar a un registro? ¿Cómo descubrir qué atributos están disponibles? ¿Cómo saber que o significa organization?

En pocas palabras, las respuestas a todas estas preguntas se hallan en el esquema, el cual se encuentra en Schemas. El esquema proporciona una descripción de lo que significa cada atributo. El esquema también correlaciona atributos en clases de objetos. La incorporación de una clase de objeto a un registro le permite utilizar los atributos incluidos en el mismo.

La pieza final del rompecabezas es comprender cómo se debe utilizar el árbol LDAP. Si va a autenticar cuentas contra el árbol, sería mejor que los usuarios tengan una clase de objeto que les de el mismo atributo userid que el sistema está buscando.

Si observa nuevamente la Figura 1, podrá ver el primer registro definido en la raíz del árbol. El distinguished name aparece primero. Luego sigue una lista de todos los atributos y valores, separados por dos puntos. Los dos puntos dentro del valor no necesitan ningún tratamiento especial. Las herramientas LDAP entienden que los primeros dos puntos separan al atributo del valor. Si necesita definir dos valores para un atributo, simplemente enumérelos como dos líneas separadas. Por ejemplo, el objeto raíz define dos clases de objetos.

Cada registro debe definir al menos una clase de objeto. La clase de objeto, a su vez, quizá requiera la presencia de ciertos atributos. En el caso del objeto raíz, la clase de objeto dcObject requiere que se defina un domain component, o dc, y la clase de objeto organization requiere que se defina un atributo organization , u o. Dado que un objeto debe contener un atributo y un valor correspondientes al RDN, la clase de objeto dcObject debe imporarse al atributo dc. La definición de un atributo o no es necesaria para crear un registro válido.

También se utiliza una descripción en el objeto raíz para describir la compañía. El objetivo aquí es demostrar el formato del comentario. Si su valor necesita abarcar múltiples líneas, inicie cada línea nueva con un espacio de interlineado en lugar de un valor. Recuerde que al especificar múltiples pares atributo: valor se definen múltiples instancias del atributo.

El segundo registro en la Figura 1 define una organizationalUnit, la cual es un contenedor para objetos people en este caso. La tercera define un usuario de tipo inetOrgPerson, el cual proporciona atributos comunes para la definición de la gente en una organización. Tenga en cuenta que se definieron dos atributoscn; uno se ha utilizado también en el DN del registro. El segundo, con la inicial del segundo nombre, ayudará en la búsqueda, pero es la primera que se necesita para satisfacer la condición de que se defina el RDN.

En el registro de usuario hay también un ou que no corresponde a la organizationalUnit en la que se encuentra el usuario. El contenedor al que pertenece el objeto del usuario puede siempre encontrarse analizando gramaticalmente el DN. Este atributo ou se refiere a algo definido por el usuario, en este caso un departamento. El servidor no impone integridad referencial, aunque la aplicación puede estar buscando un DN válido como ou=Engineering,ou=Groups,dc=ertw,dc=com.

La única otra restricción sobre los archivos LDIF que agrega registros es que el árbol debe crearse en orden, desde la raíz. La Figura 1 muestra la creación del objeto raíz, luego una ou, luego un usuario dentro de esa ou. Ahora que ha sido creada la estructura, los usuarios pueden agregarse directamente al contenedor people pero en el caso de utilizar otro contenedor, primero hay que crearlo.

El LDIF detrás de la incorporación de objetos es bastante fácil. El formato es más complejo cuando deben cargarse o borrarse los objetos. LDIF define un changetype, el cual puede ser alguno de los siguientes:

  • add agrega un elemento (por omisión).
  • delete borra el elemento especificado por el DN.
  • modrdn renombra el objeto especificado en el contenedor actual, o mueve el objeto a otra parte del árbol.
  • moddn es sinónimo de modrdn.
  • modify modifica los atributos en el DN actual.

Eliminación de usuarios

La eliminación de un elemento es el caso más sencillo, sólo requiere dn y changetype. El Listado 2 muestra la eliminación de un usuario.

Listado 2. La eliminación de un usuario con LDIF
dn: cn=Fred Smith,ou=people,dc=ertw,dc=com
changetype: delete

Administración del DN

La administración del DN del objeto es un poco más compleja. A pesar del hecho de que hay dos comandos, moddn y modrdn, ¡estos hacen lo mismo! La operación consiste de tres partes diferentes:

  1. Especificación del nuevo RDN (componente del extremo izquierdo del DN).
  2. Determinación de si el antiguo RDN debería ser colocado por el nuevo RDN en el registro, o si este debería dejarse.
  3. Como opción, mueva el registro a una nueva parte del árbol especificando un nuevo DN padre.

Pensemos en Jane Smith, quien cambia su nombre a Jane Doe. Lo primero que tiene que hacer es modificar su atributo cn para reflejar el cambio de nombre. Dado que el nuevo nombre es el modo principal en el que desea ser reconocida, y el nombre común forma parte del DN, la operación moddn es adecuada. (Si el nombre común no formara parte del DN, esta sería una modificación de atributo, lo cual explicamos en la siguiente sección.) La segunda decisión es determinar si el cn: Jane Smith debería permanecer agregado a cn: Jane Doe, lo cual permite a las personas buscarla bajo cualquiera de sus nombres. El Listado 3 muestra el LDIF que realiza el cambio.

Listado 3. LDIF para modificar el RDN de usuario
# Specify the record to operate on
dn: cn=Jane Smith,ou=people,dc=ertw,dc=com
changetype: moddn
# Specify the new RDN, including the attribute
newrdn: cn=Jane Doe
# Should the old RDN (cn=Jane Smith) be deleted?  1/0, Default = 1  (yes)
deleteoldrdn: 0

El Listado 3 comienza identificando el registro de Jane, luego el operador moddn . Se especifica el nuevo RDN, y se utiliza un tipo de nombre común pero con el nuevo nombre. Finalmente, deleteoldrdn ordena al servidor para mantener el viejo nombre. Tenga en cuenta que mientras newrdn es la única opción necesaria para el changetype moddn si usted omite deleteoldrdn, la acción borrará el viejo RDN. Según RFC 2849, deleteoldrdn es un elemento necesario.

En el caso de que se enviara a la nueva señorita Jane Doe a una nueva parte del árbol, como por ejemplo un traslado a ou=managers,dc=ertw,dc=com, el LDIF debe especificar la nueva parte del árbol de algún modo, como en el Listado 4.

Listado 4. Moviendo un registro a una nueva parte del árbol
dn: cn=Jane Doe,ou=people,dc=ertw,dc=com
changetype: modrdn
newrdn: cn=Jane Doe
deleteoldrdn: 0
newsuperior: ou=managers,dc=ertw,dc=com

Es interesante como un nuevo RDN debe especificarse aunque sea idéntico al antiguo, y el analizador gramatical de OpenLDAP ahora requiere que deleteoldrdn esté presente aunque este no tenga sentido si el RDN queda igual. newsuperior continua, el cual es el DN del nuevo padre del árbol.

Una nota final en la operación modrdn es que la orden importa, a diferencia de lo que sucede en la mayoría de los formatos LDIF. Después de changetype viene newrdn, seguido de deleteoldrdn, y, opcionalmente, newsuperior.

Modificación de atributos

El último changetype es modify, el cual se utiliza para modificar los atributos de un registro. En base a la discusión anterior sobre moddn, debería quedar claro que modify no aplica al DN o al RDN de un registro.

El Listado 5 muestra varias modificaciones realizadas a un único registro.

Listado 5. Modificación de un registro a través de LDIF
dn: cn=Sean Walberg,dc=ertw,dc=com
changetype: modify
replace: homePhone
homePhone: 555-222-3333
-
changetype: modify
add: title
title: network guy
-
changetype: modify
delete: mail
-

El LDIF para la operación modify se ve similar a los otros. Comienza con el DN del registro, luego el changetype. Después se encuentra replace:, add:, o delete:, seguido del atributo. Para delete, esta información es suficiente. Los demás requieren el par atributo:valor. Cada modificación es seguida de un guión (-) en una línea en blanco, incluyendo la modificación final.

LDIF tiene un formato de fácil lectura, tanto para los humanos como para las computadoras. Para la importación y la exportación de grandes cantidades de datos, LDIF resulta una herramienta útil.


Diseño del directorio

Esta sección abarca el material para el tema 301.2 del c del Senior Level Linux Professional (LPIC-3). El tema tiene un valor de 2.

En esta sección, aprenda sobre:

  • La definición del contenido del directorio LDAP
  • La organización del directorio
  • Cómo planificar árboles de información de directorio adecuados

Determinación de si LDAP es adecuado

Al igual que cualquier otra herramienta, LDAP no es adecuada para todas las soluciones. Antes de elegir LDAP, debe preguntarse lo siguiente:

  • ¿Cada cuánto tiempo se realizarán cambios, y de qué changetypes se trata?
  • ¿Qué utilizará los datos?
  • ¿Qué tipo de consultas se realizarán a los datos?
  • ¿Es la información de naturaleza jerárquica?

Las bases de datos LDAP están dirigidas a operaciones de lectura intensiva. La gente puede sólo cambiar información personal algunas veces por año, pero quizá consulten los atributos mucho más seguido, como la resolución de UserID que pertenece a un archivo a un nombre imprimible al buscar en un directorio. Los datos de LDAP tienden a indexarse bastante, lo cual significa que cada cambio realizado a los datos subyacentes requiere múltiples cambios a los listados que ayudan al servidor a encontrar luego los datos. LDAP además no ofrece un medio para realizar cambios masivos al árbol, aparte de realizar una búsqueda y luego modificar cada DN individual.

Las especificaciones LDAP no definen transacciones, las cuales son comunes en las bases de datos relacionales. Las transacciónes aseguran que todas las operaciones de la transacción tengan éxito, o que los datos sean colocados en estado de pre-transacción (los servidores individuales pueden implementar esto, pero no es necesario). Estas limitaciones en la actualización de datos y la falta de transacciónes hacen que LDAP resulte una elección pobre para transacciones bancarias.

Determinar el usuario, o el consumidor, de los datos también es importante. Si ninguno de los consumidores habla LDAP, entonces LDAP puede no resultar apropiado. A favor de LDAP diremos que es un protocolo de implementación extremadamente sencilla y está disponible en la mayoría de los lenguajes en la mayoría de las plataformas. Con sólo algunas operaciones disponibles definidas, puede integrarse a las aplicaciones existentes con facilidad.

LDAP suministra funcionalidad de búsqueda, pero nada comparable al nivel de una base de datos correlacional. El servidor LDAP puede almacenar los datos subyacentes usando SQL, pero usted como usuario no tiene acceso a esto y no puede utilizarlo. Por lo tanto, está limitado a los filtros de búsqueda soportados por su servidor LDAP. Estos filtros serán investigados con más detalle en artículos futuros de esta serie, pero por ahora comprenda que los filtros son sólo eso-- filtros. Usted puede realizar algunas búsquedas importantes, como "mostrar todos los empleados que viven en Washington y en Texas que son mayores de 40." Pero las sentencias equivalentes al GROUP BY del SQL no están disponibles. LDAP es más adecuado para operaciones de estio look-up, como "mostrar nombre de usuario de la persona con UID 4131," y "mostrar los nombres de todas las personas que trabajan para Jim Smith."

Finalmente, debería ser capaz de almacenar jerárquicamente la información que está tratando de almacenar . Debería almacenar una lista sencilla de datos en un servidor LDAP, pero esto probablemente sería una pérdida de recursos.

Cuando usted puede responder estas preguntas y ha determinado que LDAP es la solución correcta, es hora de diseñar el árbol del directorio.

Organización de su árbol

La idea principal es tener en cuenta que la reorganización del árbol no es algo deseable. El objetivo es desglosar sus objetos como cada rama del árbol contiene objetos de tipo similar, pero las posibilidades de que un objeto deba moverse es baja. Las razones para esto son dos. La primera es que resulta una molestia. La segunda es que un movimiento cambia el DN del objeto, y luego usted debe actualizar todos los objetos que remiten al objeto movido.

El DN raíz

La raíz de su árbol debería ser algo que represente su compañía. RFC 2247 llama al uso del atributo dc y el formato familiar dc=example,dc=com para correlacionar el dominio primario de la compañía en un DN. Su compañía probablemente tenga muchos dominios de Internet pero quizá uno sea el preferido. Es común elegir algo bajo el local top-level domain (TLD), el cual no existe actualmente en Internet. Microsoft ha sugerido por mucho tiempo el uso de este TLD para las implementaciones de su Active Directory a pesar de no ser un TLD reservado.

Si no desea utilizar el nombre de dominio en su DN raíz, puede simplemente tener un objeto con objectclass: organization, el cual le da un DN raíz de o=My Corporation.

Completando la estructura

Decidir qué colocar en el próximo nivel del DIT es difícil. A menudo resulta tentador describir la estructura organizativa de la compañía como una serie de objetos organizationalUnit anidados, pero las compañías se reorganizan constantemente, lo cual rompe con la primera regla. En lugar de esto, considere el uso de atributos para almacenar esta información.

Dependiendo del uso que le de al servidor LDAP y de cómo elija nombrar los objectos, quizá desee mantener todos los usuarios en un árbol o separarlos según su rol. Por ejemplo, puede crear un contenedor para empleados y otro para clientes, o puede agruparlos en un único contenedor. La elección depende de sus aplicaciones y de cómo planifica la administración del árbol. Si el departamento de ventas se ocupa de administrar la lista de clientes, y los administradores de sistemas se ocupan del personal, podría ser mejor crear dos contenedores. La Figura 5 muestra un DIT que ha sido dividido en clientes y usuarios.

Figura 5. Un árbol LDAP con ramas separadas para usuarios y clientes
Un árbol LDAP con ramas separadas para usuarios y clientes

La Figura 5 muestra una agrupación de personal y otra de clientes. Todo el personal reside en la misma organizational unit (OU), pero los clientes están divididos por región. En esta situación, esto permite a diferentes personas administrar su propios clientes en la región.

Si planea usar LDAP para autenticar recursos UNIX, debe entonces decidir donde almacenar la información. Ya nos hemos ocupado de las cuentas de usuario anteriormente, pero necesitaremos almacenar grupos, y posiblemente otras correlaciones como hosts, servicios, redes y aliases. Cuáles de estos almacenar en LDAP, y cuáles dejar como archivos locales depende de usted y de si necesita o no poder actualizarlos centralmente.

El caso más sencillo es el almacenamiento de cada correlación en una organizationalUnit diferente. Usted encontrará que al configurar su sistema UNIX para leer esta información, necesita especificar el DN del contenedor y los filtros. Si usted almacena grupos en la OU del usuario, usted tendrá que escribir algunos filtros. Quizá necesite también ajustar los filtros si alguna vez hace cambios estructurales a la OU del personal.

Determinación de las clases de objetos

Hasta ahora la discusión se ha centrado en el diseño del árbol LDAP con el objetivo básico de evitar tener que renombrar objetos en el futuro. Después de decidir sobre el árbol, debe decidir que clases de objetos utilizar. Es ciertamente posible asignar clases de objetos diferentes a objetos bajo la misma rama del árbol, pero esto ciertamente casi conducirá el mantenimiento de problemas en el futuro.

Para agregar más presión a la situación, no siempre es posible agregar más clases de objetos a un objeto si comete un error. Los esquemas LDAP definen dos tipo se clases de objetos: estructurales y auxiliares. Las clases de objetos estructurales generalmente heredan propiedades de otras clases de objetos en una cadena que termina en una clase de objeto denominada top. Puede decirse que las clases de objetos estructurales definen la identidad del objeto, mientras que las clases de objetos auxiliares están allí para agreagar atributos. UnaorganizationalUnit es una clase de objeto estructural, al igual que inetOrgPerson. Volviendo al Listado 1, la entrada de nivel superior tenía dos clases de objetos: dcObject y organization. organization es la clase de objeto estructural. dcObject juega un rol auxiliar definiendo el atributo dc

.

La parte que puede causar problemas es que una entrada sólo puede tener una clase de objeto estructural. A veces verá inetOrgPerson, organizationalPerson, person, y top en el mismo registro, pero todos forman parte del mismo árbol de herencia. inetOrgPerson y account son estructurales, no se encuentran en el mismo árbol de herencia, y por lo tanto no pueden utilizarse juntos. Algunos servidores LDAP permiten esto, pero eventualmente este comportamiento puede cambiar y provocar problemas.

Hay un tercer tipo de clase de objeto denominado abstracto. Es muy parecido al estructural, salvo por el hecho de que debe ser heredado para utilizarse. top es de este tipo de clase.

Sin obtener las especificaciones de cada aplicación hay algunas clases de objetos estructurales generales que son útiles:

  • inetOrgPerson: define una persona genérica, junto con información de contacto.
  • organizationalRole: muy parecido a una persona, pero define un rol genérico como IT Helpdesk o Fire Warden.
  • organizationalUnit: contenedor genérico, puede describir un departamento en un contenedor o puede utilizarse para separar varias partes del árbol LDAP como grupos, personas y servidores
  • organization: una compañía u otra organización.
  • groupOfNames: almacena uno o más DNs relacionados a miembros de un grupo. No es necesariamente útil para grupos UNIX, pero ayuda a responder invitaciones o en otras tareas sencillas.

Si utiliza estos para personas y organizaciones estará a salvo. La mayoría de las extensiones, como las autenticaciones, usan atributos auxiliares. Cuando tenga una duda, consulte el esquema.

La consideración final del diseño es la elección de DNs. La mayoría de las ramas son bastante fáciles porque no hay posibilidad de duplicación. El nombre y la ID de un grupo UNIS son únicos, por lo tanto el uso de cn como RDN de un grupo es posible. ¿Qué sucede si tiene dos empleados de nombre Fred Smith? Dado que el DN debe ser único, cn=Fred Smith,ou=People,dc=example,dc=com podría ser cualquiera de ellos. O se debe utilizar otra alternativa, como employeeNumber, o el RDN tendrá que realizarse de dos atributos diferentes separados por un signo más (+). Por ejemplo, cn=Fred Smith+userid=123, ou=people, dc=example, dc=com tiene un RDN realizado de dos atributos diferentes. Cualquier cosa que haga, ¡que sea consistente!


Esquemas

Esta sección contiene el material para el tema 301.3 del examen 301 del Senior Level Linux Professional (LPIC-3). El tema tiene un valor de 3.

En esta sección aprenderá sobre:

  • Los conceptos de los esquemas LDAP
  • Cómo crear o modificar esquemas
  • La sintaxis de los atributos y las clases de objetos

Hasta ahora, el esquema ha sido mencionado varias veces pero no se ha explicado en forma completa. El esquema es una colección de clases de objetos y sus atributos. El archivo de un esquema contiene uno o más clases de objetos y atributos en un formato de texto que el servidor LDAP puede comprender. Usted importa el archivo del esquema a la configuración del servidor LDAP, y luego utiliza los clases de objetos y atributos en sus objetos. Si los esquemas disponibles no responden a sus necesidades, puede crear su propio esquema o extender uno existente.

Conceptos de esquemas LDAP

Técnicamente, un esquema es un mecanismo de empaquetado para clases de objetos y atributos. Sin embargo, el agrupamiento de clases de objetos no se realiza al azar. Los esquemas generalmente se organizan junto con una aplicación, como un núcleo, la compatibilidad X.500, los servicios de red UNIX, sendmail, etc. Si usted necesita integrar una aplicación con LDAP, generalmente tiene que agregar un esquema a su servidor LDAP.

Una mirada más profunda de la configuración de OpenLDAP se realizará en otro tutorial de esta serie, pero para agregar esquemas se utiliza include /path/to/file.schema. Después de reiniciar el servidor, el nuevo esquema estará disponible.

Cuando el esquema está cargado, usted aplica entonces la nueva clase de objeto a los objetos relevantes. Esto puede realizarse a través de un archivo LDIF o a través de la application program interface (API) de LDAP. Aplicar clases de objetos le da más atributos para utilizar.

Creación y modificación de esquemas

Los esquemas tienen un formato bastante sencillo. En el Listado 6 se muestra el esquema para la clase de objeto inetOrgPerson junto con algunos de sus atributos.

Listado 6. Parte de la definición de inetOrgPerson
attributetype ( 2.16.840.1.113730.3.1.241
        NAME 'displayName'
        DESC 'RFC2798: preferred name to be used when displaying entries'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE )

attributetype ( 0.9.2342.19200300.100.1.60
        NAME 'jpegPhoto'
        DESC 'RFC2798: a JPEG image'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )

objectclass     ( 2.16.840.1.113730.3.2.2
    NAME 'inetOrgPerson'
        DESC 'RFC2798: Internet Organizational Person'
    SUP organizationalPerson 
    STRUCTURAL
        MAY ( 
                audio $ businessCategory $ carLicense $ departmentNumber $
                displayName $ employeeNumber $ employeeType $ givenName $
                homePhone $ homePostalAddress $ initials $ jpegPhoto $
                labeledURI $ mail $ manager $ mobile $ o $ pager $
                photo $ roomNumber $ secretary $ uid $ userCertificate $
                x500uniqueIdentifier $ preferredLanguage $
                userSMIMECertificate $ userPKCS12 )
        )

Los espacios entre líneas no son importantes en los archivos de los esquemas -- están allí más que nada para facilitar la lectura. La primera definición es attributetype, que significa atributo. Los paréntesis encierran la definición del atributo. Primero aparece una serie de números, separados por períodos, denominados object ID, u OID, que es un número globalmente único. El OID es además jerárquico, tanto que si a usted se le asigna el árbol 1.1, puede crear algo como 1.1.1 o 1.1.2.3.4.5.6 sin tener que registrarlo.

Registro de OIDs

Usted no puede simplemente tomar series de números para su propio OID porque no sabe si el valor que elije está, o estará, en uso en otro lugar. Los OIDs deben ser únicos. Algunos servidores le permiten especificar OIDs textuales (mycompany.1.2) que serían únicos, pero no necesariamente compatibles. Todo lo que se encuentra bajo el espacio de nombre 1.1 puede ser utilizado localmente pero no se garantiza que sean único.

La mejor solución es registrar su propio OID. Hay muchas formas de hacer esto, dependiendo de si se trata de un país, un operador telefónico, u otra categoría. Afortunadamente, Internet Assigned Numbers Authority (IANA) le dará gratuitamente su propia rama en .1.3.6.4.1 si lo pide.

Tras la OID se encuentra una serie de claves, cada una de las cuales tiene un valor después de la misma. Primero el NAME del atributo define el nombre que utilizarán los humanos, como en el caso del archivo LDIF o al recuperar información a través de la API de LDAP. A veces podría ver el nombre en la forma de NAME ( 'foo' 'bar' ), lo cual significa que se aceptan foo o bar. El servidor, sin embargo, considera que el primero es el nombre primario del atributo.

DESC suministra una descripción del atributo. Esto lo ayuda a comprender el atributo si está navegando por el archivo del esquema. EQUALITY, SUBSTR, y ORDERING (no se muestra aquí) requieren una regla de concordancia. Esta define como se comparan, se buscan y se ordenan, respectivamente las cadenas. caseIgnoreMatch es una concordancia insensible a las mayúsculas, y caseIgnoreSubstringsMatch tampoco distingue las mayúsculas. Consulte la sección Resources para acceder a los sitios Web que definen todas las reglas estándares de concordancia. Al igual que la mayoría de las cosas en LDAP, un servidor puede definir sus métodos de concordancia para sus propios atributos, así que no hay listas amplias de reglas de concordancia.

La SYNTAX del atributo define el formato de los datos que hacen referencia a una OID. RFC 2252 hace una lista de las sintaxis estándares y sus OIDs. Si la OID está seguida inmediatamente por un número entre corchetes ({}), esto significa la extensión máxima de los datos. 1.3.6.1.4.1.1466.115.121.1.15 representa un DirectoryString que es una cadena UTF-8.

Finalmente, la palabra clave SINGLE-VALUE no tiene argumentos y especifica que se permite sólo una instancia de displayName .

El atributo jpegPhoto tiene una definición muy corta: sólo la OID, el nombre y la descripción, y una sintaxis que significa un objeto JPEG, lo cual es una cadena codificada de los datos binarios. No es práctico buscar u ordenar una imagen, y múltiples fotografías pueden existir en un mismo registro.

La definición de una clase de objeto sigue un método similar. La palabra clave objectclass inicia la definición, seguida de paréntesis, la OID de la clase de objeto, y luego las definiciones. NAME y DESC quedan igual que antes. SUP define una clase de objeto superior, el cual es otra forma de decir que la clase de objeto definida hereda de la clase de objeto especificado por la palabra clave SUP. Por lo tanto, un inetOrgPerson contiene los atributos de un organizationalPerson.

La palabra clave STRUCTURAL lo define como una clase de objeto estructural, la cual puede considerarse el tipo primario de objetos. Otras opciones son AUXILIARY, el cual agrega atributos a un objeto existente, y ABSTRACT, el cual es igual al estructural pero no puede utilizarse directamente. Las clases de objetos abtractas deben ser heredadas por otra clase de objeto, que puede utilizarse luego. La clase de objeto top es abstracta. Esta es heredada por la mayoría de las clases de objetos estructurales, incluyendo person, que es el padre de organizationalPerson, que a su vez es heredado por inetOrgPerson.

Dos palabras claves, MAY y MUST, definen los atributos que están permitidos y son obligatorios, respectivamente, para registros que usan esa clase de objeto en particular. Para los elementos obligatorios no puede guardar un registro sin identificar todos los elementos. Cada atributo está separado por un signo de dolar ($), aún si la línea continua en la línea siguiente.

No es una buena idea modificar clases de objetos estructurales, ni tampoco los existentes y bien conocidos clases de objetos auxiliares. Porque estos son bien conocidos, podría problemas de incompatibilidad en el futuro si su servidor es diferente. Generalmente la mejor solución es definir su propia clase de objeto auxiliar, crear un esquema local, y aplicarlo a sus registros. Por ejemplo, si se encuentra en una universidad y desea almacenar atributos de estudiantes, podría considerar la creación de una clase de objeto student que es heredado de organizationalPerson o inetOrgPerson y agregar sus propios atributos. Podría entonces crear clases de objetos auxiliares para agrear más atributos como los horarios de clase.

Comprendiendo qué esquemas utilizar

Después de aprender sobre cómo se crean los esquemas, resulta tentador comenzar a actualizar -- para crear su propio esquema basado en su entorno. Esto ciertamente resolvería sus necesidades actuales, pero posiblemente a la larga acarrearía dificultades al incorporar más funcionalidad a su árbol LDAP e integrar otros sistemas. El mejor enfoque es apegarse a las clases de objetos y atributos estándares cuando puede y ampliarlo cuando debe hacerlo.

OpenLDAP generalmente almacena sus archivos de esquemas en /etc/openldap/schema, en archivos con una extensión .schema. La Tabla 3 muestra una lista de los esquemas por omisión junto con sus objetivos.

Tabla 3. Esquemas que vienen junto con OpenLDAP
Nombre de archivoObjetivo
corba.schemaDefine algunas clases de objetos y atributos para administrar referencias de objetos de Common Object Request Broker Architecture (CORBA) en múltiples máquinas.
core.schemaDefine muchos atributos y clases de objetos comunes. Este esquema es donde encontrará organizationalUnit, top, dcObject, y organizationalRole. core.schema es el primer lugar donde debería buscar si necesita encontrar algo.
cosine.schemaAtributos y clases de objetos desde las especificicaciones X.500. Mientras hay algunas cosas útiles aquí, a menudo hay mejores alternativas en otros, como core e inetorgperson.
dyngroup.schemaUn conjunto experimental de objetos utilizados con Netscape Enterprise Server.
inetorgperson.schemaDefine el objeto inetOrgPerson (el cual abarca objetos desde core.schema).
java.schemaComo corba.schema, este esquema define una serie de clases de objetos y atributos para administrar la búsqueda de clases Java™ en un árbol LDAP.
misc.schemaImplementa algunos objetos para administrar búsquedas de correo en el árbol. Es mejor consultar la documentación de su servidor para ver qué esquema utiliza.
nis.schemaEste es un esquema que usted utiliza si mueve la autenticación a LDAP. nis.schema define posixAccount, el cual suministra los atributos para almacenar datos de autenticación en el objeto del usuario. Este también tiene varios tipos de correlaciones para administrar grupos, redes, servicios y otros archivos que se encuentran en los mecanismos de autenticación basados en la red como el Network Information System (NIS).
openldap.schemaEste es más para fines de ejemplos y para mostrar algunos objetos básicos.
ppolicy.schemaUn conjunto de objetos para implementar políticas de contraseñas en LDAP, como aging. Tenga en cuenta que algunos de estos son administrados por los mecanismos de sombras tradicionales de UNIX y ya son administrados en nis.schema.

Además, RFC 4519 explica atributos comunes. Después de encontrar los atributos que desea, puede entonces ver a través de los archivos del esquema para determinar cuáles son los archivos que se deben incluir en su configuración LDAP y cuáles son las clases de objetos que debe utilizar para sus registros.


Resumen

En este tutorial aprendió sobre los conceptos, la arquitectura y el diseño de LDAP. LDAP surgió de una necesidad de conectarse a directorios X.500 por IP de un modo más simple. Un directorio le presenta datos en un modo jerárquico, muy similar al de un árbol. En este árbol hay registros que son identificados por un distinguished name y tienen muchos pares atributo-valor, incluyendo una o más clases de objetos que determinan qué datos pueden almacenarse en el registro.

LDAP se refiere al protocolo utilizado para buscar y modificar el árbol. Sin embargo, practicamente el término LDAP es utilizado para todos los componentes, como servidor LDAP, datos LDAP, o simplemente "Se encuentra en LDAP".

Los datos en LDAP a menudo son importados y exportados con LDIF, lo cual es una representación textual de los datos. Un archivo LDIF especifica un changetype, como add, delete, modrdn, moddn, y modify. Estas operaciones le permiten agregar entradas, borrar entradas, mover datos por el árbol, y modificar los atributos de los datos.

El diseño correcto del árbol es crucial para la viabilidad al largo plazo del servidor LDAP. Un diseño correcto significa pocas operaciones de cambio necesarias, lo cual lleva a datos sólidos fácilmente ubicables por otras aplicaciones. Eligiendo atributos comunes, se asegura que otros consumidores de datos LDAP comprendan el significado de los atributos y de que se requieren pocas traducciones.

El esquema LDAP determina cuales atributos se pueden utilizar en su servidor. En el esquema hay definiciones de los atributos, incluyendo OIDs simplemente para identificarlos, instrucciones sobre cómo almacenar y ordenar los datos, y descripciones textuales sobre lo que hacen los atributos. Las clases de objetos agrupan atributos y pueden definirse como estructurales, auxiliares o abstractas.

Las clases de objetos estructurales definen el registro, por lo tanto un registro puede tener sólo una clase de objeto estructural. Las clases de objetos auxiliares agregan más atributos para fines específicos y pueden agregarse a cualquier registro. Una clase de objeto abstracta debe ser heredada y no puede utilizarse directamente.

Recursos

Aprender

  • Relea toda la LPI exam prep tutorial series en developerWorks para aprender los fundamentos de Linux y prepararse para la certificación en administrador de sistemas.
  • En el LPIC Program, encuentre listas de tareas, preguntas de muestra, y objetivos detallados de los tres niveles de la certificación en administración de sistemas Linux del Linux Professional Institute.
  • RFC 1487, X.500 Lightweight Directory Access Protocol, le da algo de percepción sobre el desarrollo de LDAP y la historia de X.500.
  • RFC 2247, Using Domains in LDAP/X.500 Distinguished Names, es una breve descripción del atributo domainComponent y de cómo utilizarlo correctamente en su árbol LDAP.
  • RFC 2252, Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions, ofrece una lista de las sintaxis estándares de atributos, lo cual puede ayudarlo a descubrir el formato que se espera de un atributo determinado.
  • RFC 2849, The LDAP Data Interchange Format (LDIF) - Technical Specification, describe el lenguaje del LDIF. Esta utiliza Backus-Naur Form (BNF) para especificar el lenguaje, el cual puede ser difícil de comprender. RFC 2234, Augmented BNF for Syntax Specifications: ABNF, podría ayudarlo a comprender los diversos operadores.
  • RFC 4511, Lightweight Directory Access Protocol (LDAP): The Protocol, es el último bosquejo del protocolo LDAP.
  • RFC 4519, Lightweight Directory Access Protocol (LDAP): Schema for User Applications, es una lista actualizada de los atributos más utilizados; esta lista lo ayuda a asegurarse de que está utilizando los mismos atributos que los demás para describir los mismos datos.
  • El enlace OID descriptions for 2.5.13 a descripciones detalladas de cómo funciona cada regla coincidente (comparación de cadenas, subcadenas y ordenamiento).
  • Esta FAQ entry on object classes le brinda los detalles de algunas de las reglas más difíciles de tratar con tipos de objetos. Algunos de los mensajes de error de OpenLDAP son concisos, especialmente los relacionados con las importaciones de LDIF.
  • El framework overlay en OpenLDAP es fundamental porque el concepto de metadirectorio puede profundizarse más que simplemente enlazando servidores LDAP múltiples. Una solicitud de un árbol particular u OID puede dirigirse para personalizar código que puede llamar un script, leer una base de datos, o llamar una API. Otra descripción se encuentra en el sitio Web Symas Corporation .
  • "Demystifying LDAP Data" (O'Reilly, noviembre de 2006) explica la herencia de clases de objetos. Este trata el tema de las clases de objetos de inetOrgPerson y describe las clases de objetos estructurales y auxiliares.
  • LDAP for Rocket Scientists es una excelente guía de código abierto, a pesar de que se trata de una tarea en progreso.
  • En la developerWorks Linux zone, encuentre más recursos para los desarrolladores de Linux, y examine nuestros most popular articles and tutorials.
  • Vea todos los Linux tips y los Linux tutorials en developerWorks.
  • Manténganse al día con los developerWorks technical events and Webcasts.

Obtener los productos y tecnologías

  • OpenLDAP es una buena alternativa si está buscando un servidor LDAP.
  • phpLDAPadmin es una herramienta de administración de LDAP basada en la Web.
  • Luma resulta una buena GUI si es más su estilo.
  • Con IBM trial software, que puede descargar directamente desde developerWorks, cree su próximo proyecto de desarrollo en Linux.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=651048
ArticleTitle=Preparación para el examen 301 del LPI, Tema 301: Conceptos, arquitectura y diseño
publish-date=07152011