Loading ...
Recuerda que puedes obtener ayuda sobre Linux en nuestro Foro de Soporte.
ArtÃculo original de: Linux+DVD
Autor: Tomeu Capó Capó .
Introducción
En todas las redes informáticas donde hay un gran número de usuarios con diferentes usos (cuentas Windows, GNU/Linux, MacOSX, …), la gestión puede ser una tarea muy pesada. Tener un buen sistema de gestión de usuarios puede agilizar esta tarea. LDAP (Lightweight Directory Access Protocol) nos permite organizar de manera jerárquica todo tipo de datos como: cuentas de usuario, grupos, puntos de montaje, cuentas de equipos, etc. de manera rápida y sencilla.
OpenLDAP es una versión libre de LDAP que es un protocolo a nivel de aplicación que soporta un servicio de directorio, se parece a una libreta de direcciones. OpenLDAP se basa en el estándar de servicio de directorio ISO X.500 y en su protocolo DAP (Directory Access Protocol). Se diseñó para ser un protocolo simple y eficiente para acceder al directorio DAP, por eso lo de lightweight , implementa un subconjunto de operaciones del X.500. La base de datos se diferencia de una relacional principalmente en la terminologÃa, por ejemplo un registro es una entrada y campo un atributo, aparte de que la base de datos del OpenLDAP está sólo optimizada en las lecturas, de ahà su rápido acceso a sus datos. El directorio nos va a permitir, entre otras cosas, que los usuarios puedan buscar de manera rápida información sobre otros usuarios (e-mail, teléfonos, entre otras opciones) o bien autenticarse, aunque este servicio no siempre nos va a permitir el cambio de esa información, eso dependerá de nuestros permisos. El protocolo nos da acceso al directorio que es la base de datos donde está la información estructurada de manera jerárquica en forma de árbol, en general contiene información más descriptiva basada en objetos y atributos. Hay una serie de ventajas respecto a otros sistemas de directorio que hacen que OpenLDAP sea el sistema más flexible y escalable como por ejemplo está optimizado en lectura de registros, la posibilidad de múltiples directorios independientes, la mayorÃa de aplicaciones y sistemas operativos disponen de soporte para LDAP, realizar criterios de búsqueda complejos, permitir la réplica de la base de datos a otro servidor.
El directorio y su estructura
Como hemos comentado al principio, la base de datos estructura la información en forma de árbol. Para representar los nodos de dicho árbol utiliza una serie de cadenas de caracteres en un formato especial, como por ejemplo: dc=linuxplus, dc=org. Donde dc determina un componente del nombre del dominio, en nuestro caso el dominio linuxplus.org, esto se trata del directorio base o raÃz del árbol, como todo dominio también se podrÃa dar el caso de tener un sub dominio que representarÃamos como: dc=redaccion, dc=linuxplus, dc=org (redaccion.linuxplus.org).
Si nos fijamos el formato es muy simple: atributo = valor, podemos definir un nodo utilizando el formato LDIF: LDAP Data Interchange Format en el cual se pueden definir una serie de atributos con sus correspondientes valores como se puede observar en el Listado 1, la primera lÃnea define el distinguished name que nos determina la ubicación del nodo dentro del árbol, serÃa como la clave primaria en una base de datos relacional que identifica a uno y sólo un elemento (registro), el cual está compuesto por diferentes atributos (campos) separados por comas: el atributo uid es la clave del nodo, ou (Organizational Unit) nos indica en que unidad organizativa se encuentra este nodo y finalmente el dominio en que se encuentra la ou. Después nos podemos encontrar con más atributos seguidos del dn, como el objectClass, éste nos define el tipo o tipos de este registro, en nuestro caso la clase person nos da los atributos cn (Common Name) y sn (Surname), y la clase posixAccount los atributos uid y uidNumber. Dependiendo de las clases que utilicemos podremos utilizar unos u otros atributos, en nuestro caso este nodo definirÃa un usuario del sistema, ahora bien no podemos utilizar la clase que queramos, cada clase está definida dentro del esquema (schema) que se declarará antes de ser utilizado. Normalmente estos esquemas ya vienen predefinidos y rara vez se tienen que crear a mano por lo que no vamos a adentrarnos mucho en su construcción, solamente veremos un poco su estructura y cómo cargarlos.
Para acabar con esta pequeña introducción, y como hemos comentado, están las ou’s Organizational Unit o unidad organizativa que nos servirán como su nombre indica para organizar otros elementos dentro de ella, como otras ou’s u otro tipo de nodos, actúan como los directorios de un sistema de ficheros.
Listado 1. Definición básica de un nodo de LDAP
dn: uid=tomeu, ou=People, dc=linuxplus, dc=orgobjectClass: person
objectClass: posixAccount
cn: Tomeu Capó
sn: Capó
uid: tomeu
uidNumber: 512
…
Tipos de datos y esquemas
Dentro del directorio, como en otro tipo de base de datos, podemos tener diferentes tipos de datos y atributos, los esquemas son una colección de objetos
y definiciones de atributos los cuales definen la estructura de los registros dentro de la base de datos, en este artÃculo no vamos a entrar demasiado en los detalles de los esquemas por lo que vamos a dar unas pequeñas indicaciones sin profundizar mucho en su formato, para más información puede consultar la página: http://www.openldap.org/doc/admin23/schema.html. Los ficheros por defecto que definen estos esquemas se encuentran en /etc/ldap/schema, dichos ficheros contienen la definición de objetos y sus atributos, asà como: su descripción, sintaxis, matching rules … Un objeto se define de siguiente forma:
objectclass (definición del objeto)
Tal como se puede observar en el Listado 2 está definido el objeto person utilizado para registros donde almacenemos datos referentes a usuarios, si creamos un registro en la base de datos utilizando este objeto podremos usar sus atributos que se definen dentro de este esquema,
por ejemplo sn (Surname) (Listado 3).
Listado 2. Definición del objeto person
objectclass ( 2.5.6.6 NAME ‘person’
DESC ‘RFC2256: a person’
SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
Listado 3. Definición del atributos sn y name
attributetype ( 2.5.4.41 NAME ‘name’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
attributetype ( 2.5.4.4 NAME ( ’sn’ ’surname’ )
DESC ‘RFC2256: last (family) name(s) for which the entity is known by’
SUP name )
En la definición del objeto person y en primer lugar nos encontramos con el identificador de objeto o OID que identifica de manera global el objeto, seguidamente el nombre del objeto, luego definimos con SUP cual es el objeto padre de éste, en este caso es el objeto top que es el objeto más simple de todos. Seguidamente se define cuales serán los atributos obligatorios con MUST y los opcionales con MAY los cuales se representan uno detrás de otro separados por $.
Normalmente estas definiciones se encuentran dentro del fichero core.schema, primero se definen los atributos y finalmente los objetos, en nuestro caso sólo hemos cogido la definición de un objeto y dos de sus atributos. Siguiendo con la definición de los atributos, en el Listado 3 encontramos la definición de dos atributos de nuestro objeto person. El formato (definido en el RFC2252) no es muy diferente a la definición de los objetos:
attributetype ( definición )
Nos volvemos a encontrar con el OID, en este caso para identificar el atributo, nuevamente el nombre del atributo NAME, las reglas de búsqueda del atributo (Matching rules) que pueden ser (EQUALITY, ORDERING o SUBSTR) y la sintaxis que nos define el tipo de datos del atributo. La regla Matching Rule nos va a permitir definir cómo funcionarán las búsquedas sobre este atributo, en nuestro caso le decimos que tiene que ser igual EQUALITY a una cadena de caracteres y que no importe si tiene espacios, ni mayúsculas, ni minúsculas caseIgnoreMatch, podemos añadir más de una condición, por ejemplo SUBSTR, las subcadenas también tienen que cumplir la misma condición que la cadena de caracteres. La sintaxis utilizada en el atributo name es de tipo directoryString como podemos observar en la Tabla 1 y su longitud (32768) entre llaves.
TABLA 1. Diferentes tipos de datos disponibles
En donde se puede ver el uso de SUP con el atributo sn, que es un atributo el cual el campo padre es name, esto significa que heredarÃa sus condiciones del tipo de datos (Matching rules).
Entradas relacionadas: