| SUSE LINUX – Manual de Administración Capítulo 13. Fundamentos de conexión a redes / 13.7. El servicio de directorio LDAP | ||||
|---|---|---|---|---|
 | 13.6. DNS – Domain Name System | 13.8. NIS – Network Information Service |  | |
| SUSE LINUX – Manual de Administración Capítulo 13. Fundamentos de conexión a redes / 13.7. El servicio de directorio LDAP | ||||
|---|---|---|---|---|
| 13.6. DNS – Domain Name System | 13.8. NIS – Network Information Service | | |
En entornos de trabajo en red es de vital importancia el poder acceder de forma rápida y estructurada a la información que se necesita. Los datos desorganizados no sólo influyen negativamente en el uso de Internet, sino también pueden dificultar los procesos de búsqueda en la intranet de la empresa: ¿cuál es la extensión telefónica del Sr. X del departamento Y? ¿Y su dirección de correo electrónico?
Los servicios de directorio son la respuesta a este problema. De manera semejante a las páginas amarillas (Yellow Pages) en la vida ordinaria, dichos servicios contienen toda la información necesaria de forma estructurada y accesible.
En el caso ideal, un servidor central guarda los datos en un directorio y los distribuye a los clientes de la red a través de un protocolo determinado. Los datos han de estar estructurados de tal forma que un máximo número de aplicaciones pueda acceder a ellos. De este modo no es necesario que cada aplicación de calendario o cliente de correo electrónico disponga de una base de datos propia, sino basta con que puedan recurrir al depósito central, lo que reduce considerablemente el esfuerzo de administración de la información. El uso de un protocolo estandarizado y abierto como LDAP garantiza que el mayor número posible de aplicaciones de clientes tenga acceso a esta información.
En este contexto pues, un directorio es una especie de base de datos optimizada para poder ser examinada y leída muy fácil y rápidamente:
Para permitir un alto número de accesos de lectura (simultáneos), los permisos de escritura están limitados a unas pocas actualizaciones por parte del administrador. Las bases de datos tradicionales están optimizadas para recoger en poco tiempo el mayor volumen de datos posible.
Debido a que los permisos de escritura sólo pueden ejercerse de forma muy limitada, el servicio de directorio administra información estática que cambia rara vez. En contraposición, los datos en una base de datos convencional se modifican con mucha frecuencia (se trata de información dinámica). Por poner un ejemplo, los números de teléfono de un directorio de empleados están sujetos a muchos menos cambios que las cifras manejadas por el departamento de contabilidad.
En la gestión de datos estáticos, los registros de datos se actualizan con muy poca frecuencia. En cambio, cuando se trabaja con datos dinámicos, especialmente en el terreno de cuentas bancarias y datos de contabilidad, la coherencia de los datos es primordial. Si una cantidad ha de restarse de un sitio para ser añadida a otro, ambas operaciones han de ejecutarse simultáneamente en una “transacción” para garantizar la concordancia del conjunto de los datos. Las bases de datos soportan estas transacciones, mientras que los directorios no lo hacen. En estos últimos, la falta de concordancia de los datos resulta aceptable durante breves periodos de tiempo.
El diseño de un servicio de directorio como LDAP no está concebido para soportar complejos mecanismos de actualización o consulta. Todas las aplicaciones que accedan a este servicio han de poder hacerlo de la forma más fácil y rápida posible.
Han existido y existen numerosos servicios de directorio, no sólo en el mundo Unix, sino también, por ejemplo, Novells NDS, Microsofts ADS, Banyans Street Talk y el estándar OSI X.500.
Originalmente, LDAP fue planeado como una variante más simple de DAP (Directory Access Protocol) desarrollado para acceder a X.500. El estándar X.500 reglamenta la organización jerárquica de entradas de directorio.
LDAP no incorpora algunas de las funciones de DAP y puede ser utilizado en múltiples plataformas y, sobre todo, con un bajo consumo de recursos, sin renunciar a la jerarquía de entradas definida en X.500. Gracias al uso de TCP/IP es mucho más fácil implementar interfaces entre la aplicación y el servicio LDAP.
Entre tanto, LDAP ha seguido desarrollándose y se utiliza cada vez con más frecuencia como solución autónoma sin soporte X.500. Con LDAPv3 (la versión de protocolo disponible en su sistema con el paquete openldap2 instalado), LDAP soporta remisiones o referrals que permiten implementar bases de datos distribuidas. Otra de las novedades consiste en la utilización de SASL (Simple Authentication and Security Layer) como capa de autentificación y protección.
LDAP no sólo puede aplicarse para consultar datos de servidores X.500 como era su propósito original: slapd es un servidor de código abierto u Open Source que permite guardar la información de un objeto en una base de datos local. Este servidor se complementa con slurpd, el cual se encarga de replicar varios servidores LDAP.
El paquete openldap2 está formado fundamentalmente por dos programas.
Un servidor LDAPv3 autónomo que gestiona la información de objetos en una base de datos basada en BerkeleyDB.
Este programa permite replicar los cambios realizados en los datos del servidor LDAP local en otros servidores LDAP instalados en la red.
slapcat, slapadd, slapindex
Tradicionalmente, los administradores de sistemas Unix utilizan el servicio NIS para la resolución de nombres y distribución de datos en la red. Los datos de configuración procedentes de los archivos /etc y los directorios group, hosts, mail, netgroup, networks, passwd, printcap, protocols, rpc y services son distribuidos entre los clientes de la red desde un servidor central. Como simples archivos de texto, estos archivos pueden mantenerse sin grandes dificultades. No obstante, la administración de cantidades mayores de datos resulta bastante más complicada debido a la falta de estructura. NIS está dirigido únicamente a plataformas Unix, lo que hace imposible su uso para la administración central de datos en redes heterogéneas.
Al contrario que NIS, el campo de aplicación del servicio LDAP no está limitado a redes sólo Unix. Los servidores Windows (2000 y superiores) soportan LDAP como servicio de directorio. Novell también ofrece un servicio LDAP. Además, sus funciones no se limitan a las mencionadas en líneas superiores.
El principio de LDAP puede aplicarse a cualquier estructura de datos que deba administrarse de forma centralizada. Entre los ejemplos de aplicación cabe destacar:
Uso en sustitución de un servidor NIS
Enrutamiento de correo (postfix, sendmail)
Libreta de direcciones para clientes de correo como Mozilla, Evolution, Outlook, …
Administración de descripciones de zonas para un servidor de nombres BIND9
Esta enumeración podría prolongarse indefinidamente ya que LDAP, al contrario que NIS, es expandible. Su estructura de los datos claramente definida ayuda a la hora de administrar grandes cantidades de datos, ya que puede examinarse más fácilmente.
El directorio LDAP tiene una estructura en forma de árbol. Cada entrada (denominada objeto) del directorio ocupa una posición determinada dentro de esa jerarquía (denominada DIT o Directory Information Tree). La ruta completa a una entrada la identifica de modo inequívoco y se conoce como DN o Distinguished Name. Cada uno de los nodos en la ruta a dicha entrada se llaman RDN o Relative Distinguished Name. Por lo general, existen dos tipos de objetos:
Este tipo de objeto puede contener a su vez otros objetos. Algunos ejemplos de estos elementos son root (elemento raíz del árbol de directorios que no existe en realidad), c country, ou OrganizationalUnit, y dc domainComponent. Este modelo es equiparable a los directorios (carpetas) en el sistema de archivos.
Este tipo de objeto se encuentra al final de una rama y carece de objetos subordinados. Algunos ejemplos son Person/InetOrgPerson o groupofNames.
En la cúspide de la jerarquía del directorio se encuentra el elemento raíz Root. A este elemento le puede seguir en un nivel inferior c country, dc domainComponent o o organization.
El siguiente ejemplo ilustra mejor las relaciones jerárquicas dentro de un árbol de directorios LDAP (ver Figura 13.4, “Estructura de un directorio LDAP”).
La figura representa un DIT ficticio con entradas (entries) en tres niveles. Cada entrada se corresponde con una casilla en la figura. En este caso, el nombre válido completo (DN o Distinguished Name) del empleado ficticio de Geeko Linux es cn=Geeko Linux,ou=doc,dc=suse,dc=de. Este nombre se forma al añadir el RDN al DN de la entrada precedente cn=Geeko Linux.
La definición global de qué tipo de objetos han de guardarse en el DIT se realiza mediante un esquema. El tipo de objeto se determina mediante la clase de objeto. La clase de objeto especifica qué atributos deben o pueden ser asignados a un objeto determinado. Por lo tanto, un esquema debe contener definiciones de todas las clases de objetos y atributos que van a utilizarse en el escenario de aplicación. Existen algunos esquemas de uso extendido (véase RFC 2252 y 2256). No obstante, si el entorno en el que va a utilizarse el servidor LDAP lo requiere, también pueden crearse nuevos esquemas en función del usuario o pueden combinarse varios esquemas entre sí.
La tabla 13.9, “Clases de objetos y atributos de uso extendido” ofrece un resumen de las clases de objetos utilizadas en el ejemplo de core.schema e inetorgperson.schema junto con los atributos obligatorios y los valores adecuados de atributo.
Tabla 13.9. Clases de objetos y atributos de uso extendido
| Clase de objeto | Significado | Entrada de ejemplo | Atributo obligatorio |
|---|---|---|---|
| dcObject | domainComponent (partes del nombre del dominio) | suse | dc |
| organizationalUnit | organizationalUnit (unidad organizativa) | doc | ou |
| inetOrgPerson | inetOrgPerson (datos sobre personal para Internet/intranet) | Geeko Linux | sn y cn |
En la salida 13.17, “Extracto de schema.core (Numeración de líneas para facilitar la comprensión)” puede ver un extracto de una instrucción de esquema con aclaraciones que le ayudarán a entender la sintaxis de nuevos esquemas.
Ejemplo 13.17. Extracto de schema.core (Numeración de líneas para facilitar la comprensión)
...
#1 attributetype ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' )
#2 DESC 'RFC2256: organizational unit this object belongs to'
#3 SUP name )
#4 objectclass ( 2.5.6.5 NAME 'organizationalUnit'
#5 DESC 'RFC2256: an organizational unit'
#6 SUP top STRUCTURAL
#7 MUST ou
#8 MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
internationaliSDNNumber $ facsimileTelephoneNumber $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l $ description) )
...
Como ejemplo se ha tomado el tipo de atributo organizationalUnitName y la clase de objeto correspondiente organizationalUnit. En la línea 1 aparece el nombre del atributo, su número de identificación de objeto (OID o Object Identifier) (numérico) y la abreviatura del atributo. En la línea 2, DESC introduce una breve descripción del atributo que incluye el RFC del que procede la definición. SUP en la línea 3 hace referencia a un tipo de atributo superior al que pertenece este atributo.
La definición de la clase de objeto organizationalUnit comienza en la línea 4 con un OID y el nombre de la clase de objeto, al igual que en la definición de atributo. La línea 5 contiene una breve descripción de la clase de objeto. La entrada SUP top en la línea 6 indica que esta clase de objeto no está subordinada a ninguna otra clase de objeto. La línea 7, que empieza por MUST, enumera todos los tipos de atributo que deben ser utilizados obligatoriamente en un objeto del tipo organizationalUnit. A continuación de MAY en la línea 8 se incluyen todos los tipos de atributos que pueden ser utilizados en conexión con esta clase de objeto.
La documentación del programa OpenLDAP, disponible en el sistema en /usr/share/doc/packages/openldap2/admin-guide/index.html, constituye una excelente introducción para la utilización de esquemas.
Su sistema instalado contiene un archivo de configuración completo para el servidor LDAP en /etc/openldap/slapd.conf. A continuación se explicarán brevemente cada una de las entradas y las modificaciones necesarias. Tenga en cuenta que las entradas precedidas del signo # se encuentran inactivas. Para activar dichas entradas basta con borrar el signo de comentario.
Ejemplo 13.18. slapd.conf: Instrucción Include para esquemas
include /etc/openldap/schema/core.schema include /etc/openldap/schema/inetorgperson.schema
Con esta primera instrucción en slapd.conf se define el esquema utilizado para organizar el directorio LDAP (ver salida 13.18, “slapd.conf: Instrucción Include para esquemas”). La entrada core.schema se requiere obligatoriamente. Si necesita esquemas adicionales, introdúzcalos detrás de esta instrucción (como ejemplo se ha añadido aquí inetorgperson.schema). Puede encontrar otros esquemas disponibles en el directorio /etc/openldap/schema/. Si NIS va a ser sustituido por un servicio LDAP, integre aquí los esquemas cosine.schema y rfc2307bis.schema. Puede obtener información adicional sobre este tema en la documentación incluida en OpenLDAP.
Ejemplo 13.19. slapd.conf: pidfile y argsfile
pidfile /var/run/slapd.pid argsfile /var/run/slapd.args
Estos dos archivos contienen el número de identificación de proceso (PID o process id) y algunos argumentos con los que se iniciará el proceso slapd. En esta sección no es necesario realizar ningún cambio.
Ejemplo 13.20. slapd.conf: Controles de acceso
#
# Sample Access Control
# Allow read access of root DSE
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
#
access to dn="" by * read
access to *
by self write
by users read
by anonymous auth
#
# if no access controls are present, the default is:
# Allow read by all
#
# rootdn can always write!
La salida 13.20, “slapd.conf: Controles de acceso” es el fragmento de slapd.conf que regula los controles de acceso al directorio LDAP en el servidor. Las opciones definidas en esta sección global de slapd.conf tienen validez mientras no se especifiquen otras reglas de acceso en la sección específica de las bases de datos que sobreescriban a estas. Conforme a las reglas aquí definidas, todos los usuarios tienen permiso de lectura para el directorio pero sólo el administrador (rootdn) puede escribir en el mismo. Debido a que la regulación de los permisos de acceso en LDAP es un tema muy complejo, incluimos a continuación unas reglas generales que le ayudarán a comprender este proceso:
La sintaxis de todas las reglas de acceso es la siguiente:
access to <what> by <who> <access>
what representa al objeto o atributo para el que quiere definir el acceso. Puede proteger de forma explícita diversas ramas del directorio o bien cubrir zonas enteras del árbol de directorios por medio de expresiones regulares. slapd evalúa todas las reglas en el orden en el que aparecen en el archivo de configuración. Por lo tanto, anteponga siempre las reglas más restrictivas a las más generales. slapd analiza la primera regla aplicable que encuentra e ignora el resto.
who define quién tiene acceso a los sectores definidos en what. El uso de expresiones regulares le ahorrará aquí también mucho trabajo. Como en el caso anterior, slapd interrumpe el proceso de análisis de who al encontrar la primera regla aplicable. Por lo tanto, las reglas específicas han de anteponerse de nuevo a las más generales. Pueden utilizarse las siguientes entradas (ver tabla 13.10, “Grupos de usuarios con acceso autorizado”):
Tabla 13.10. Grupos de usuarios con acceso autorizado
| Identificador | Significado |
|---|---|
| * | todos los usuarios sin excepción |
| anonymous | usuarios no autentificados (“anónimos”) |
| users | usuarios autentificados |
| self | usuarios unidos al objeto destino |
| dn=<regex> | todos los usuarios a los que puede aplicarse esta expresión regular |
access especifica el tipo de acceso. Aquí se distingue entre las posibilidades que aparecen en la tabla 13.11, “Tipos de acceso”:
Tabla 13.11. Tipos de acceso
| Identificador | Significado |
|---|---|
| none | acceso prohibido |
| auth | para contactar con el servidor |
| compare | para accesos comparables a objetos |
| search | para utilizar filtros de búsqueda |
| read | permiso de lectura |
| write | permiso de escritura |
slapd compara los permisos solicitados por el cliente con los que han sido concedidos en slapd.conf. Si allí están autorizados derechos iguales o más amplios que los que solicita el cliente, este obtiene autorización. Si por el contrario el cliente solicita más permisos que los concedidos en slapd.conf, el acceso será denegado.
La salida 13.21, “slapd.conf: Ejemplo de control de acceso” contiene un ejemplo muy simple de un control de acceso sencillo que puede configurarse de la forma deseada utilizando expresiones regulares.
Ejemplo 13.21. slapd.conf: Ejemplo de control de acceso
acess to dn.regex="ou=([^,]+),dc=suse,dc=de"
by cn=administrator,ou=$1,dc=suse,dc=de write
by user read
by *
Según esta regla, sólo el administrador tiene permiso de escritura para todas las entradas ou, los usuarios autentificados disponen de permiso de lectura, y al resto se le ha denegado el acceso.
![[Tip]](admon/tip.png) | Definición de reglas Access |
|---|---|
Si no es posible aplicar ninguna regla access to o instrucción by <who>, el permiso será denegado. Sólo se conceden aquellos permisos autorizados explícitamente. En caso de no existir ninguna regla, se aplica el siguiente principio: permiso de escritura para el administrador y permiso de lectura para todos los demás. | |
La documentación en línea del paquete instalado openldap2 incluye información más detallada y una configuración de muestra de los permisos de acceso para LDAP. Además de la administración de los permisos de acceso a través del archivo de configuración central (slapd.conf), existe también la posibilidad de utilizar informaciones de control de acceso o ACIs (Access Control Information). Las ACIs permiten almacenar la información de acceso a cada objeto en el mismo árbol LDAP. Debido a que este tipo de control de acceso está todavía muy poco extendido y su estado ha sido calificado por los desarrolladores como experimental, referimos aquí a la documentación del proyecto OpenLDAP en Internet: http://www.openldap.org/faq/data/cache/758.html.
Ejemplo 13.22. slapd.conf: Instrucciones para bases de datos
database ldbm
suffix "dc=suse,dc=de"
rootdn "cn=admin,dc=suse,dc=de"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd/tools. Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain
index objectClass eq
En la primera línea de esta sección (ver salida 13.22, “slapd.conf: Instrucciones para bases de datos”) se define el tipo de base de datos, LDBM en este caso. La entrada suffix de la segunda línea especifica la parte del árbol de directorios LDAP de la que se va a ocupar este servidor. En la línea inferior, rootdn determina quién dispone de derechos de administración para este servidor. No es necesario que el usuario indicado en esta sección posea una entrada LDAP o que exista siquiera como usuario “normal”. La contraseña de administrador se define con la instrucción rootpw. Aquí puede sustituir secret por el resumen criptográfico generado con slappasswd. La instrucción directory indica el directorio en el que están almacenados los directorios de la base de datos en el servidor. La última instrucción, index objectClass eq, hace que se cree un índice con las clases de objetos. Si lo desea, puede introducir otros atributos que en su caso particular se busquen con más frecuencia. Cuando se definen reglas Access propias para la base de datos y se colocan detrás, se aplicarán estas en lugar de las reglas Access globales.
Una vez que el servidor LDAP ha sido configurado y en el directorio LDAP se han llevado a cabo todas las entradas deseadas según el modelo descrito abajo (ver apartado 13.7.4, “Administración de datos en el directorio LDAP”), puede iniciar el servidor LDAP como usuario root introduciendo el siguiente comando:
rcldap start
Para detener el servidor de forma manual ha de introducir el comando rcldap stop y para consultar el estado del servidor, rcldap status. También es posible configurar el servidor para que se inicie y detenga automáticamente al encender y apagar al ordenador. Para ello puede utilizar el editor de niveles de ejecución de YaST (véase el apartado 12.5, “El editor de niveles de ejecución de YaST”) o bien crear directamente los enlaces correspondientes en los scripts de inicio y final por medio de insserv en la línea de comandos (ver apartado 12.4.1, “Añadir scripts init”).
OpenLDAP proporciona al administrador numerosos programas para gestionar los datos en el directorio LDAP. A continuación le presentamos los cuatro programas más importantes para añadir, eliminar, examinar y modificar los datos existentes.
Como condición previa para la introducción de nuevas entradas, la configuración del servidor LDAP en /etc/openldap/slapd.conf ha de ser correcta y apta para su aplicación, es decir, debe contener las instrucciones adecuadas para suffix, directory, rootdn, rootpw e index. La introducción de entradas en OpenLDAP puede llevarse a cabo con el comando ldapadd. Por razones prácticas se recomienda añadir los objetos a la base de datos en forma de paquetes. Con este fin, LDAP contempla el formato LDIF (LDAP Data Interchange Format). Un archivo LDIF es un simple archivo de texto que puede estar formado por un número indeterminado de pares de atributo y valor. Puede consultar los objetos y atributos disponibles en los archivos de esquemas indicados en slapd.conf. El archivo LDIF utilizado para crear el armazón del ejemplo de la figura 13.4, “Estructura de un directorio LDAP” podría presentar el siguiente aspecto (ver archivo 13.23, “Ejemplo de archivo LDIF”):
Ejemplo 13.23. Ejemplo de archivo LDIF
# La organización SUSE dn: dc=suse,dc=de objectClass: dcObject objectClass: organization o: SUSE AG dc: suse # La unidad de organización Desarrollo (devel) dn: ou=devel,dc=suse,dc=de objectClass: organizationalUnit ou: devel # La unidad de organización Documentación (doc) dn: ou=doc,dc=suse,dc=de objectClass: organizationalUnit ou: doc # La unidad de organización Administración de Sistemas (it) dn: ou=it,dc=suse,dc=de objectClass: organizationalUnit ou: it
![[Important]](admon/important.png) | Codificación de los archivos LDIF |
|---|---|
LDAP funciona con UTF-8 (Unicode), por lo que caracteres especiales como acentos, etc., han de introducirse con la codificación correcta. Utilice para ello editores que soporten UTF-8, como Kate o versiones actuales de Emacs). De lo contrario, deberá usar recode para convertir el texto a UTF-8. | |
Guarde el archivo como <archivo>.ldif y páselo al servidor con el siguiente comando:
ldapadd -x -D <dn del administrador> -W -f <archivo>.ldif
La primera opción -x indica que en este caso no se va a producir una autentificación a través de SASL. -D identifica al usuario que realiza esta operación. Introduzca aquí el DN válido del administrador tal y como ha sido configurado en slapd.conf (en nuestro ejemplo, cn=admin,dc=suse,dc=de). -W evita tener que introducir la contraseña en la línea de comandos (texto en claro) y activa una pregunta por separado de la contraseña. Dicha contraseña ha sido especificada previamente en slapd.conf en la entrada rootpw. -f pasa el archivo al servidor. A continuación se muestra la salida 13.24, “ldapadd de ejemplo.ldif” de ldapadd:
Ejemplo 13.24. ldapadd de ejemplo.ldif
ldapadd -x -D cn=admin,dc=suse,dc=de -W -f ejemplo.ldif Enter LDAP password: adding new entry "dc=suse,dc=de" adding new entry "ou=devel,dc=suse,dc=de" adding new entry "ou=doc,dc=suse,dc=de" adding new entry "ou=it,dc=suse,dc=de"
Los datos de usuario de los empleados de cada uno de los departamentos pueden introducirse en archivos LDIF adicionales. Por medio del siguiente ejemplo tux.ldif (ver la salida 13.25, “Archivo LDIF para Tux”), el empleado Tux es añadido al nuevo directorio LDAP:
Ejemplo 13.25. Archivo LDIF para Tux
# El empleado Tux dn: cn=Tux Linux,ou=devel,dc=suse,dc=de objectClass: inetOrgPerson cn: Tux Linux givenName: Tux sn: Linux mail: tux@suse.de uid: tux telephoneNumber: +34 123 4567-8
Un archivo LDIF puede contener un número ilimitado de objetos. Es posible pasar al servidor árboles de directorios completos de una vez o sólo partes de los mismos, como por ejemplo objetos sueltos. Si necesita modificar los datos con frecuencia, se recomienda el fraccionamiento en objetos individuales para evitar laboriosas búsquedas en archivos grandes del objeto que debe ser modificado.
Los registros de datos pueden modificarse con la herramienta ldapmodify. El método más fácil consiste en editar el archivo LDIF respectivo y pasar de nuevo el archivo modificado al servidor LDAP. Por ejemplo, para cambiar el número de teléfono del empleado Tux de +34 123 4567-8 a +34 123 4567-10, edite el archivo LDIF como se muestra en 13.26, “Archivo LDIF tux.ldif modificado”.
Ejemplo 13.26. Archivo LDIF tux.ldif modificado
# El empleado Tux dn: cn=Tux Linux,ou=devel,dc=suse,dc=de changetype: modify replace: telephoneNumber telephoneNumber: +34 123 4567-10
Utlice el siguiente comando para importar el archivo modificado al directorio LDAP:
ldapmodify -x -D cn=admin,dc=suse,dc=de -W -f tux.ldif
Como alternativa, también puede introducir directamente en la línea de comandos los atributos que deben ser modificados con ldapmodify. En este caso proceda como se describe a continuación:
Ejecute ldapmodify e introduzca su contraseña:
ldapmodify -x -D cn=admin,dc=suse,dc=de -W Enter LDAP password:
Introduzca los cambios siguiendo la estructura definida a continuación y el orden especificado:
dn: cn=Tux Linux,ou=devel,dc=suse,dc=de changetype: modify replace: telephoneNumber telephoneNumber: +34 123 4567-10
Puede obtener información detallada sobre ldapmodify y su sintaxis en la página del manual correspondiente (man ldapmodify).
OpenLDAP ofrece ldapsearch, una herramienta de línea de comandos para examinar y leer datos en el directorio LDAP. La sintaxis de un comando de búsqueda sencillo sería la siguiente:
ldapsearch -x -b dc=suse,dc=de "(objectClass=*)"
La opción -b define la base de búsqueda, es decir, la sección del árbol donde va a efectuarse la búsqueda (en este caso, dc=suse,dc=de). Si desea realizar una búsqueda más depurada en subsecciones determinadas del directorio LDAP (por ejemplo sólo en el departamento devel), puede definir dicha sección en ldapsearch con la opción -b. La opción -x especifica la utilización de una autentificación sencilla. (objectClass=*) indica que desea leer todos los objetos incluidos en el directorio. Puede utilizar este comando tras la creación de un nuevo árbol de directorios para comprobar si todas las entradas han sido aceptadas correctamente y si el servidor responde en la forma deseada. Puede obtener información adicional sobre el uso de ldapsearch en su página del manual (man ldapsearch).
Utilice el comando ldapdelete para borrar entradas del directorio LDAP. Su sintaxis es muy semejante a la de los comandos descritos en líneas superiores. Por ejemplo, para borrar la entrada completa de Tux Linux, introduzca el comando:
ldapdelete -x -D cn=admin,dc=suse,dc=de -W cn=Tux \ Linux,ou=devel,dc=suse,dc=de
En este capítulo se han omitido de forma consciente temas de cierta complejidad como la configuración de SASL o de un servidor LDAP de replicación que comparte el trabajo con varios esclavos (“slaves”). Puede encontrar información detallada sobre ambos temas en OpenLDAP 2.1 Administrator's Guide (ver enlace más abajo).
La página web del proyecto OpenLDAP contiene abundante documentación en inglés para usuarios de LDAP tanto noveles como expertos:
Una extensa colección de preguntas y respuestas en torno a la instalación, configuración y utilización de OpenLDAP. http://www.openldap.org/faq/data/cache/1.html
Breves instrucciones paso a paso para su primer servidor LDAP http://www.openldap.org/doc/admin21/quickstart.html o bien en su sistema instalado en /usr/share/doc/packages/openldap2/admin-guide/quickstart.html
Una detallada introducción a todos los aspectos importantes de la configuración de LDAP incluyendo codificación y control de acceso http://www.openldap.org/doc/admin21/ o bien en su sistema instalado en /usr/share/doc/packages/openldap2/admin-guide/index.html
Los siguientes libros rojos (redbooks) de IBM tratan también de LDAP:
Una introducción general muy amplia a los principios básicos de LDAP http://www.redbooks.ibm.com/redbooks/pdfs/sg244986.pdf
Este libro está dirigido especialmente a administradores de IBM SecureWay Directory. No obstante, también contiene información general sobre LDAP http://www.redbooks.ibm.com/redbooks/pdfs/sg245110.pdf.
Bibliografía impresa (en inglés) sobre LDAP:
Howes, Smith & Good: Understanding and Deploying LDAP Directory Services. Addison-Wesley, 2. Aufl., 2003. - (ISBN 0-672-32316-8)
Hodges: LDAP System Administration. O'Reilly & Associates, 2003. - (ISBN 1-56592-491-6)
Los RFCs correspondientes (engl. Request for comments) 2251 a 2256 constituyen la obra de consulta definitiva sobre LDAP.
