Resumen

  • El RFC 2307 propuso representar en LDAP cuentas Unix, grupos y recursos de red. Su clase posixAccount incluía uidNumber, el entero que consumen las funciones de consulta del sistema.
  • La sección de seguridad expuso la consecuencia de asignar mal los permisos de escritura: un usuario que pudiera cambiar uidNumber podría hacer que su cuenta equivaliera a la del superusuario.

Primero llega el número

Un proceso no le pregunta al directorio quién es alguien. Entrega un entero a la biblioteca C y espera una ficha de cuenta. El RFC 2307 usa getpwuid() como ejemplo: la función relaciona un identificador de usuario con un nombre de inicio de sesión. En la forma LDAP propuesta, la búsqueda selecciona una entrada posixAccount cuyo uidNumber coincide con el número recibido.

Parece un dato de archivo. El sistema lo trata como identidad.

Antes de LDAP, las redes Unix podían compartir información de cuentas y máquinas mediante Network Information Service (NIS). La guía de administración de Sun describe los mapas NIS como tablas de dos columnas: una clave y su valor. El servidor maestro de cada dominio mantiene los mapas; los servidores esclavos guardan copias; los clientes consultan a uno u otro. passwd.byname busca por nombre de usuario y passwd.byuid usa el identificador como clave. El administrador construye los mapas desde archivos locales en el maestro y propaga el resultado a los esclavos.

Así, un cambio de archivo podía convertirse en una decisión de red. Se modificaba el archivo de entrada, se reconstruía el mapa y la respuesta quedaba disponible para los clientes del dominio. El código de consulta no decidía si el nuevo número era sensato: consumía el valor recibido.

El manual de SunOS de 1999 añade una pequeña historia corporativa: NIS antes se llamaba Sun Yellow Pages y conservó la misma función tras el cambio de nombre. Cambió la etiqueta; los mapas de cuentas siguieron teniendo consecuencias.

LDAP cambió el directorio, no los permisos

La especificación LDAPv3 de 1997 propuso acceder a directorios basados en X.500 usando menos recursos que el protocolo DAP completo. Tres meses después, el RFC 2307, titulado An Approach for Using LDAP as a Network Information Service, propuso clases y atributos LDAP para datos de Unix y TCP/IP.

La lista iba mucho más allá de los nombres de host: incluía cuentas y grupos, servicios y números de protocolo, identificadores RPC, parámetros de arranque, direcciones de red y grupos NIS. Una entrada posixAccount podía guardar el nombre de acceso, un nombre visible, uidNumber, gidNumber, el directorio personal y el intérprete de comandos. El RFC incluso muestra cómo una línea de tipo /etc/passwd podía expresarse como atributos de directorio.

La integración tenía una lógica directa. Los programas Unix ya pedían datos de cuentas a la biblioteca C; el sistema podía dirigir la consulta a un directorio de red en vez de a un archivo local. La sección de implementación del RFC describe un servidor NIS respaldado por LDAP, código de referencia para la biblioteca C y scripts que convertían archivos como /etc/passwd y /etc/hosts en entradas LDAP.

El documento no ordenaba migrar a todos los sitios Unix. Se publicó como Experimental y ofrecía un enfoque para servicios de nombres de organizaciones. El RFC decía que el mecanismo ya se había implementado con cierto éxito, pero no contaba instalaciones ni medía su adopción.

El número era el límite de autoridad

La sección de seguridad del RFC 2307 es explícita sobre lo que podía hacer un atributo de directorio. Dice que solo los administradores deberían modificar las entradas del esquema ligadas al sistema operativo. Después explica el motivo: si un usuario pudiera cambiar su uidNumber, podría comprometer la seguridad haciendo que su cuenta equivaliera a la del superusuario.

El RFC 2307 formula un riesgo condicional y señala el punto de control: el software Unix relacionaba el número con una cuenta; un directorio podía publicar esa correspondencia para muchos clientes; quien controlara las escrituras podía cambiar la identidad que veían. El software Unix relaciona el número con una cuenta; el directorio puede publicar esa relación ante muchos clientes; quien controle las escrituras puede cambiar la identidad que estos ven. El esquema define la sintaxis. El permiso decide quién puede darle efecto.

La misma sección detecta otra colisión entre consulta y privilegio. Hacer visibles para usuarios sin privilegios hashes de contraseñas cifrados con funciones conocidas, como crypt(), puede exponerlos a ataques de diccionario y fuerza bruta. El RFC presenta esa práctica como compatibilidad con sistemas Unix existentes y recomienda un servicio de autenticación sólido cuando la seguridad sea importante. Un directorio compartido simplifica las búsquedas, pero también puede acercar material sensible a más clientes.

Las fuentes prueban una propuesta y los riesgos que documentó; no prueban la extensión de su despliegue LDAP. La nota de implementación del RFC acredita que hubo una implementación, pero este conjunto de documentos no mide cuántos sistemas Unix adoptaron el esquema.

El cambio importante no fue añadir campos a una base. Fue permitir que una respuesta de red resolviera una pregunta local del sistema operativo. uidNumber podía ser una columna; el proceso que interpretaba el valor le daba fuerza. Al pasar de /etc/passwd a NIS o LDAP también se movía el punto de control: había que saber qué fuente mandaba, qué réplicas tenían el mapa actual y quién podía editar la identidad.

Fuentes