LDAP y recursos compartidos

Si cada servidor guarda sus propios usuarios, dar de alta a una persona son quince altas y darla de baja son quince bajas, con la garantía de que alguna se olvidará. Un servicio de directorio resuelve eso: una única base de datos de identidades que consultan todas las aplicaciones y todos los servidores.

El protocolo con el que se consulta ese directorio es LDAP, el protocolo ligero de acceso a directorio. Se llama ligero porque es una versión aligerada de un estándar anterior, el de los servicios de directorio de la familia OSI, del que hereda la idea de organizar la información en árbol. La versión vigente es la tercera.

No es una base de datos relacional ni pretende serlo. Es jerárquica, está pensada para leerse muchísimo más de lo que se escribe, y guarda cosas que se consultan constantemente y cambian poco. Y no sirve solo para personas: en el directorio están también las máquinas, los grupos, las impresoras y las unidades de la organización.

Sobre que «LDAP es binario» conviene un matiz, porque suele malinterpretarse: lo que se codifica en binario son los mensajes del protocolo, que no son texto legible como los de correo o los de web. Los datos del directorio son texto corriente y de hecho se exportan como texto.

Desde Java, las consultas a un directorio se hacen con la interfaz de nombres y directorios de la plataforma, que viene incluida en el propio entorno de ejecución y no hay que instalar aparte. Y para quien venga del bloque de sistemas operativos: el Active Directory que allí se estudia como dominio de Windows es, por dentro, un directorio de este tipo. Aquí se ve el protocolo; allí, el producto y sus políticas.

Un directorio se optimiza para leer, no para escribir. Por eso vale para autenticar mil veces al día y no para llevar la contabilidad de una empresa.

La unidad de información del directorio es la entrada, y una entrada no es más que un conjunto de atributos, cada uno con su nombre y su valor: el nombre de la persona, su correo, su teléfono, su departamento. Las entradas cuelgan unas de otras formando el árbol.

Cada entrada se identifica sin ambigüedad con su nombre distinguido, que es el equivalente a la clave primaria de una tabla. Y se construye igual que una ruta de ficheros pero al revés: el nombre relativo de la entrada, seguido del nombre distinguido de su padre, hasta llegar a la raíz.

dn: cn=ana.torres,ou=alumnos,dc=llegandoalcorte,dc=com
     |__________|  |__________|  |_______________________|
         rdn        rama ou        raíz por componentes

rdn de la entrada : cn=ana.torres
dn del padre      : ou=alumnos,dc=llegandoalcorte,dc=com

De ahí sale una consecuencia práctica que conviene entender antes de diseñar un árbol: mover una entrada de rama le cambia el nombre distinguido, porque cambia el de su padre. Por eso las ramas se diseñan según algo estable, como la estructura de la organización, y no según algo que cambie cada temporada.

El nombre distinguido se forma con el relativo propio más el nombre distinguido del padre. Se lee de lo particular a lo general, al contrario que una ruta de ficheros.

El protocolo tiene un juego corto de operaciones. La primera de toda sesión es la de conexión y autenticación, que es la que presenta al cliente ante el directorio. Después vienen las de consulta y las de escritura, y hay además una operación para pasar la conexión a modo seguro.

Las búsquedas se pueden expresar como una dirección de servicio, con una forma fija que se pregunta: el esquema y el servidor con su puerto, la entrada desde la que se busca, los atributos que se quieren de vuelta, la profundidad de la búsqueda, el filtro y, al final, las extensiones.

ldap://directorio.llegandoalcorte.com:389/ou=alumnos,dc=llegandoalcorte,dc=com?cn,mail?sub?(objectClass=person)

partida     : ou=alumnos,dc=llegandoalcorte,dc=com
atributos   : cn, mail
profundidad : sub (todo el subárbol)
filtro      : las entradas cuya clase sea person

La profundidad es el parámetro que más se falla. Buscar solo en la entrada indicada sirve para leer un registro que ya se conoce; un nivel por debajo, para listar lo que cuelga directamente de una rama; y todo el subárbol, para buscar de verdad. El valor por defecto es el primero, el más restrictivo, así que una búsqueda que «no devuelve nada» suele ser una búsqueda sin profundidad declarada.

LDAP viaja sobre TCP, y ahí hay dos puertos que hay que saberse. El 389 es el del servicio normal. El 636 es el del servicio dentro de un túnel cifrado desde el primer momento, que es lo que se conoce como LDAP seguro.

La alternativa al puerto dedicado es empezar la conversación en claro por el puerto normal y pedir el cambio a modo seguro antes de mandar credenciales. Ese mecanismo no es exclusivo del directorio: es el mismo que usan el correo entrante y saliente, la transferencia de ficheros y la web, y consiste siempre en lo mismo, una extensión que convierte en cifrado un protocolo de texto plano sin cambiar de puerto.

Hay una distinción de la que dependen muchas preguntas: el directorio autentica, pero no autoriza. Comprueba que quien dice ser alguien lo es de verdad, y cada aplicación decide después qué puede hacer esa identidad dentro de ella. La consecuencia práctica es que una máquina o un usuario que no estén dados de alta en el directorio no pueden entrar en ningún sitio, porque no hay quien los reconozca.

Para poder autenticar, el directorio guarda los datos con los que se comprueba la identidad: el par de usuario y contraseña, que no se almacena en claro sino como resumen, o bien un certificado electrónico cuando la organización trabaja con ellos.

389 en claro y 636 cifrado de principio a fin. Y una tercera vía: empezar por el 389 y elevar la conexión a segura antes de autenticarse.

Dar de alta trescientos alumnos uno a uno desde una interfaz gráfica no es trabajo de administrador. Para eso está el formato de intercambio de datos de LDAP, que es sencillamente un fichero de texto donde se escriben entradas y se envían al servidor de una tacada.

Sus dos usos son la importación y la exportación, y las dos direcciones son igual de útiles. Se genera el fichero y se sube para poblar el árbol de forma masiva; o se vuelca el árbol a fichero para revisarlo, guardarlo como copia o llevarlo a otro servidor. Al ser texto, se puede generar desde una hoja de cálculo o desde un script y se puede revisar antes de aplicarlo.

dn: ou=alumnos,dc=llegandoalcorte,dc=com
objectClass: organizationalUnit
ou: alumnos

dn: cn=ana.torres,ou=alumnos,dc=llegandoalcorte,dc=com
objectClass: person
cn: ana.torres
sn: Torres
telephoneNumber: 900 000 000

La estructura del fichero se explica sola: cada entrada empieza por su nombre distinguido y debajo van sus atributos, uno por línea, separando las entradas con una línea en blanco. Cargar el fichero anterior crea la rama y, dentro, la persona.

Es un formato de fichero, no un protocolo. Sirve para poblar el árbol de forma masiva y para sacar copias legibles de lo que hay dentro.

Un directorio no admite cualquier atributo en cualquier entrada: tiene un esquema que define qué se puede guardar y con qué forma. La pieza que lo materializa es la clase de objeto, que es la que dice, para cada tipo de entrada, qué atributos son obligatorios y cuáles opcionales.

Las clases se organizan por herencia, en una jerarquía que arranca de una clase raíz de la que descienden todas las demás. Una entrada declara varias clases y lo que vale es la más específica, que es la que aporta los atributos propios de ese tipo.

Esas clases predefinidas, con sus atributos, no las inventa cada producto: vienen de la normalización del directorio del mundo OSI, y por eso una entrada de persona se parece tanto en un directorio de Windows como en uno libre.

En un fichero de intercambio hay además un atributo especial que indica qué se quiere hacer con cada entrada, y no qué es. Cuando se pide añadir, equivale a llamar a la operación de alta del protocolo. Ese atributo es lo que convierte un fichero de datos en un fichero de instrucciones de cambio.

La clase de objeto define qué atributos exige y admite una entrada. Una entrada declara varias y manda la última, la más específica.

La otra mitad de la gestión de usuarios es la de los recursos que usan. Compartir una carpeta en la red evita las copias sueltas por los puestos, permite respaldar en un solo sitio y hace que el permiso se conceda por pertenencia a un grupo y no persona a persona.

Sobre una carpeta compartida hay dos capas de permisos que no son la misma: los del recurso compartido, que se aplican a quien llega por la red, y los del sistema de ficheros, que se aplican siempre, se llegue por la red o sentado delante. Cuando las dos se pronuncian, gana la más restrictiva, y ese es el origen de la mitad de las incidencias de «yo debería poder entrar ahí».

La recomendación práctica es no repartir permisos a personas. Se crean grupos en el directorio, se dan los permisos al grupo y las altas y bajas se convierten en meter o sacar a alguien de un grupo, que es una operación reversible y auditable.

Con las impresoras ocurre lo mismo. En lugar de conectar cada impresora a un puesto, se publica en un servidor de impresión que mantiene la cola, aplica los permisos y lleva la contabilidad de lo que imprime cada quien. El protocolo estándar para hacerlo es el de impresión por internet, que trabaja sobre HTTP y es el que hablan tanto los servidores de impresión de Windows como el sistema de impresión habitual de Linux.

Entre permisos de recurso compartido y permisos del sistema de ficheros, siempre gana el más restrictivo de los dos.