CIBERC-IGT-015020-12

Normativa de Uso del Directorio

Página 1 de 22

Normativa de Uso del Directorio

Este documento es propiedad de la Dirección General de Telecomunicaciones y Nuevas Tecnologías y se le ha establecido un nivel de seguridad acorde a la “Normativa clasificación de la seguridad de la documentación de CiberCentro”. En ningún caso el documento, o cualquiera de sus partes, que no sea clasificado de carácter público, deberá ser distribuido a terceros sin el consentimiento explícito, por escrito o correo electrónico firmado, por parte del personal autorizado de la Dirección General de Telecomunicaciones y Nuevas Tecnologías. Asimismo, ninguna de las partes del documento puede ser copiada, fotografiada, fotocopiada, transmitida electrónicamente, almacenada en un sistema de gestión documental o reproducida mediante cualquier otro mecanismo ajeno a la Dirección General de Telecomunicaciones y Nuevas Tecnologías sin autorización previa, por escrito o correo electrónico firmado, por parte del personal autorizado de la misma.

Rev.

Fecha

09 10 11 12

23-02-2009 02-03-2011 01-08-2012 19-03-2014

Descripción Desactivación de acceso anónimo. Acceso LDAPS. Actualización de formatos e información de portada. Actualización de contenidos. Actualización de contenidos

Documento : Ubicación:

CIBERC-IGT-015020-12 Normativa de uso del Directorio.doc http://www.gobiernodecanarias.net/cibercentro/documentos/documentos-denormativas.html http://www.gobiernodecanarias.org/cpj/temas/cibercentro/ciber_normativa.html

Nivel de Seguridad:

Público

Preparado por

Revisado por

Aprobado por

Gestión de Proyectos

DGTNT

DGTNT

Fecha: 19-03-2014

Fecha: 19-03-2014

CiberCentro

Fecha: 19-03-2014

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 2 de 22

INDICE 1

INTRODUCCIÓN ...................................................................................................................................... 4

2

ÁMBITO ..................................................................................................................................................... 4

3

POLÍTICAS CORPORATIVAS DE USO DEL SERVICIO ..................................................................... 4 3.1 NORMAS GENERALES DE ACCESO AL SERVICIO ........................................................................................ 4 3.1.1 Nombres cualificados de Internet (DNS)......................................................................................... 4 3.1.2 Puertos .......................................................................................................................................... 5 3.1.3 Bases de búsqueda LDAP............................................................................................................... 5 3.1.4 Identificación de acceso ................................................................................................................. 6 3.1.5 Pruebas ......................................................................................................................................... 6 3.1.6 Registro ......................................................................................................................................... 6 3.1.7 Resumen ........................................................................................................................................ 7 3.2 NORMAS GENERALES DE GESTIÓN DE ENTRADAS ..................................................................................... 8 3.2.1 Características comunes de las entradas de usuarios...................................................................... 8 3.2.2 Integración de aplicaciones............................................................................................................ 8 3.3 RECOMENDACIONES ..............................................................................................................................10 3.3.1 Autenticación y autorización de usuarios.......................................................................................10 3.3.2 Autorización para el acceso a aplicaciones ...................................................................................10 3.3.3 Tolerancia a fallos ........................................................................................................................11 3.3.4 Ampliación del esquema................................................................................................................11 3.3.5 Indexación de atributos .................................................................................................................12 3.3.6 Soporte de referencias...................................................................................................................12 3.3.7 Bajo el esquema del directorio corporativo LDAP, existe un referral para el sufijo “o=SPE”, que lo vincula con el servicio de directorio LDAP de Terceros.Búsqueda de entradas .............................................13 3.3.8 Denegación de búsquedas masivas no indexadas ...........................................................................13 3.3.9 Tiempos de espera ........................................................................................................................13 3.3.10 Uso de las conexiones ...................................................................................................................13 3.3.11 Mayúsculas y minúsculas ..............................................................................................................14 3.3.12 Desarrollo de aplicaciones............................................................................................................14

4

ANEXOS ....................................................................................................................................................16 4.1 GLOSARIO ............................................................................................................................................16 4.2 EJEMPLOS DE CONFIGURACIÓN DE CLIENTES ..........................................................................................17 4.2.1 Libreta de direcciones de Microsoft Outlook Express ....................................................................17 4.2.2 Softerra LDAP Browser ................................................................................................................17 4.3 DOCUMENTACIÓN COMPLEMENTARIA ....................................................................................................18 4.4 PLANTILLAS LDIF DE APLICACIÓN .........................................................................................................19 4.4.1 Unidad Organizativa de la aplicación (si la requiere para escritura) .............................................19 4.4.2 Usuario de conexión de la aplicación (bajo su propia Unidad Organizativa) .................................19 4.4.3 Usuario de conexión de la aplicación de lectura (sin Unidad Organizativa propia)........................19 4.4.4 Grupo de entradas (grupo de usuarios) .........................................................................................19 4.5 ATRIBUTOS GENÉRICOS INDEXADOS EN EL DIRECTORIO ..........................................................................20

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 3 de 22

5

REFERENCIAS .........................................................................................................................................21

6

CONTACTOS ............................................................................................................................................22

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 4 de 22

1 Introducción El Servicio de Directorio funciona como un repositorio central de perfiles de identidad, contraseñas y privilegios de acceso que pueden ser usados sobre otras aplicaciones y recursos de red. El objetivo principal de este documento es describir de forma breve y clara cómo hacer un uso correcto del Servicio, tanto por parte de aplicaciones estándar como de desarrollos propietarios. Por lo tanto, no se pretende recoger toda la casuística relacionada con el servicio, sino aquella información más común que puede ser de utilidad antes de la integración de una aplicación con el Servicio de Directorio Todo Servicio de Directorio debe garantizar, al menos, las siguientes características: 

Integridad: Visión homogénea del repositorio para mantener la calidad de los datos.



Confidencialidad: Sólo los datos necesarios deben estar accesibles para quien corresponda.



Alta disponibilidad: El servicio debe estar operativo el mayor porcentaje de tiempo posible. Además, en caso de fallo debe minimizarse el tiempo necesario para la recuperación del servicio.



Independencia: Permitiendo la comunicación entre sistemas heterogéneos.



Escalabilidad: Vertical y horizontal, para adecuarse a las demandas de la organización.

Aunque el documento presupone del lector un conocimiento básico del estándar LDAP, es recomendable leer la sección 4.1 Glosario, para comprender correctamente el resto del documento.

2 Ámbito Este documento es de especial interés para desarrolladores y administradores de sistemas que participen en proyectos donde se requiera el uso del Servicio de Directorio del Gobierno de Canarias. Actualmente, el Servicio de Directorio del Gobierno de Canarias sólo es visible desde la red corporativa, sólo siendo accesible desde el exterior (Internet) mediante el uso de accesos VPN.

3 Políticas corporativas de uso del servicio 3.1

Normas generales de acceso al servicio

3.1.1

Nombres cualificados de Internet (DNS)

Todas las aplicaciones que hagan uso del directorio deben configurarse para consultar a los servidores de directorio mediante los siguientes nombres resueltos por el servicio de DNS: 

Producción (lectura): directorio.gobiernodecanarias.net

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 5 de 22



Producción (escritura): ldapmaster.gobiernodecanarias.net



Pre-explotación (lectura): directorio-pre.gobiernodecanarias.net



Pre-explotación (escritura): ldapmaster-pre.gobiernodecanarias.net



Desarrollo (escritura y lectura): ldapmaster-des.gobiernodecanarias.net

Siempre deben usarse los nombres completos FQDN (Fully Qualified Domain Name), nomenclatura tolerante a cualquier cambio de acceso en la infraestructura de servidores del Gobierno de Canarias. El directorio de pre-explotación es una copia del de producción, que pretende ser una imagen fiel del entorno de producción, y escenario de paso obligatorio para el paso a producción de cualquier cambio o modificación relativo a la configuración y características del sistema. El directorio de desarrollo es una copia parcial del de producción, sobre el que se realizan cambios (nuevas objectClass, ACI, etc.), utilizándolo como banco de pruebas para su posterior paso a preexplotación. 3.1.2

Puertos

Como norma general se utilizará el puerto TCP estándar para acceso al LDAPS, que es el 636. Este puerto brindará comunicación SSL/TLS para el consumo del servicio del directorio, de manera que desde el comienzo de las comunicaciones, estas garantizarán los niveles de privacidad y confidencialidad que la LOPD exigen para tal menester. Adicionalmente se podrá utilizar el puerto TCP estándar para acceso al LDAP (el 389), aunque es altamente recomendado el uso de su versión basada en SSL/TLS, para garantizar la privacidad y confidencialidad de las comunicaciones entre los clientes y los servidores. 3.1.3

Bases de búsqueda LDAP

El servicio de directorio LDAP está basado en una representación de objetos con datos (atributos en argot técnico), dispuestos de forma jerárquica sobre un sufijo común como raíz. Este sufijo, c=es, será utilizado como base de búsqueda por aplicaciones y desarrollos que necesiten información de los datos profesionales de los usuarios, o de atributos propios de aplicación. Las consultas más habituales se realizan sobre alguna de las ramas siguientes: Usuarios del Gobierno de Canarias:

o=gobiernodecanarias,c=es

Usuarios de la Administración de Justicia en Canarias: o=justiciaencanarias,c=es Personal externo colaborador:

o=canarias.org,c=es

También existe un sufijo, o=SPE, habilitado como referral (enlace simbólico a otro servicio de directorio LDAP) contra el servicio de directorio de Terceros, y está destinado a ser un catálogo de usuarios externos a la organización.

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 6 de 22

3.1.4

Identificación de acceso

El servicio de directorio LDAP corporativo no permite acceso anónimo para realizar consultas, acorde al cumplimiento de la LOPD1, por lo que cada acceso al servicio irá sujeto a un proceso de autenticación de de usuario válido para la conexión. Cada aplicación corporativa que acceda al servicio deberá identificarse mediante una operación de autenticación de conexión (BIND en argot técnico) antes de realizar consultas. Para ello se crearán cuentas específicas para dichas aplicaciones, usuarios de aplicación, éstos sólo dispondrán de los derechos estrictamente necesarios, contando por defecto con el acceso de sólo lectura a los datos básicos de usuario, desde la base de búsqueda “c=es”, para empleados públicos o personal externo colaborador, y “o=SPE” para terceros. Las credenciales de inicio de sesión (DN –Distinguished Name- en argot técnico) vendrán definidos por cualquiera de las siguientes nomenclaturas: uid=,o=Applications,o=gobiernodecanarias,c=es uid=,ou=, o=Applications, o=gobiernodecanarias,c=es 3.1.5

Pruebas

Antes de la entrada en producción de una aplicación que accede al servicio de directorio LDAP, ésta debe validarse en el entorno de pre-explotación. Además, los responsables de la nueva aplicación deben proveer los procedimientos necesarios para crear las estructuras que requiera la misma (por ejemplo para la creación de clases y atributos no estándares, reglas de control de acceso, etc.). Si las pruebas realizadas sobre este entorno son satisfactorias, el personal de CiberCentro se encargará de repetir el proceso (siguiendo el procedimiento validado o mediante exportación e importación de los datos) en el entorno de producción. Además, en el entorno de pruebas deberá evaluarse el impacto sobre el rendimiento del servicio o posibles problemas de integración con otras aplicaciones cliente, de cara a un mantenimiento pro-activo del servicio. 3.1.6

Registro

La metodología de gestión de las TIC implementada en CiberCentro (basada en ITIL) exige que todo activo a gestionar (servicio, software, servidor, etc.) disponga de su documentación asociada. Como preparativo para la puesta en marcha de un nuevo servicio, es habitual el cumplimentar algunos formularios y redactar procedimientos de gestión. Para controlar el acceso a los datos, cuando una nueva aplicación requiera el uso del directorio, debe informarse por escrito. Por ejemplo, en el CI Servicio o en el CI Software, deben incluirse los datos necesarios para documentar el uso que se realiza del servicio de directorio. Los datos mínimos a incluir en los CI, son los descritos en el anexo 4.3 Documentación complementaria.

1

Ley Orgánica de Protección de Datos de carácter personal

CIBERC-IGT-015020-12

Normativa de Uso del Directorio

Página 7 de 22 Además, este registro permite planificar y notificar a los responsables los cambios en el servicio como una actualización del software involucrado o una parada programada del mismo. 3.1.7 o

Resumen En el caso de tratarse de un acceso de aplicación que use los datos del directorio LDAP corporativo, es necesario configurar los siguientes parámetros:

Parámetro

Descripción

Ejemplo / Notas

SERVER

Indica el FQDN del servidor de directorio LDAP

directorio-pre.gobiernodecanarias.net

PORT

Indica el puerto TCP usado por el servicio de directorio

686

BASEDN

Indica la base o sufijo del árbol a partir del cual buscar

c=es (para empleados públicos y personal externo colaborador) o=SPE (para Terceros)

BINDDN

Indica el DN del usuario con el que se realizará la consulta

PASSWORDDN

Indica la clave del BINDDN a usar para conectar

SCOPE

Indica si la búsqueda se realizará en un solo nivel o en el subárbol a partir de la base de búsqueda BASEDN

SUB2

FILTER

Filtro de entradas, equivalente a un WHERE en SQL

uid=rmazgon

2

La opción SUB indica que se realizarán búsquedas en todo el subárbol

uid=,o=applications,o=gobiernodecanarias,c=es

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 8 de 22

3.2

Normas generales de gestión de entradas

El servicio de directorio provisto por el Gobierno de Canarias implementa una serie de restricciones y características que tendrán que ser tomadas en cuenta de cara al consumo del mismo y a la integración de las aplicaciones de terceros. 3.2.1

Características comunes de las entradas de usuarios

3.2.1.1

Unicidad de atributos

Los sistemas utilizados para el servicio implementan reglas de control sobre algunos atributos clave, para evitar que existan duplicados. 

UID: identificador único de usuario.



gdcDNI, jecDNI y employeeNumber: número de identificación fiscal.



mail y mailAlternateAddress: direcciones de correo electrónico (únicas por usuario).

3.2.1.2

Validación del esquema

Cuando se modifica el valor de un atributo, el sistema comprobará que es sintácticamente válido. Es decir, se comprueba que el nuevo valor puede ser almacenado correctamente en el atributo (en función del tipo de dato). Por ejemplo, el servidor no permitirá guardar la cadena “hola” en el atributo createTimestamp, ya que éste atributo estándar está definido como tipo fecha (Generalized Time). En el argot LDAP, los tipos de datos se denominan “syntaxes”. Por ejemplo, algunos de los más frecuentemente utilizados son: DirectoryString, Integer, Boolean, URI, TelephoneNumber, etc. 3.2.2

Integración de aplicaciones

Para el desarrollo e integración de aplicaciones que utilicen el directorio como medio de autenticación o autorización para su catálogo de usuarios, el Gobierno de Canarias propone la siguiente forma de trabajo: 1. Si la aplicación no requiere almacenar datos de configuración en el directorio: 

Cada aplicación contará con un usuario de conexión específico (usuario de aplicación) dentro del siguiente sufijo de la jerarquía del directorio: o=Applications,o=gobiernodecanarias,c=es

Ejemplo: uid=app-user,o=Applications,o=gobiernodecanarias,c=es 2. Si la aplicación requiere almacenar datos de configuración en el directorio: 

Cada aplicación contará con un unidad organizativa (OU en el argot técnico) dentro del siguiente sufijo de la jerarquía del directorio:

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 9 de 22

o=Applications,o=gobiernodecanarias,c=es Bajo esta unidad organizativa la aplicación tendrá permisos totales de escritura y podrá crear y/o modificar las entradas necesarias para su normal funcionamiento (roles de la aplicación, etc.). Ejemplo: ou=nombre_app,o=Applications,o=gobiernodecanarias,c=es 

Cada aplicación contará con un usuario de conexión específico, dentro de su OU. Se usará tanto para iniciar los procesos de autenticación y autorización de los usuarios, como para la consulta de datos de necesarios para el funcionamiento de la aplicación.

Ejemplo: uid=app-user,ou=nombre_app,o=Applications,o=gobiernodecanarias,c=es

Por defecto, cada aplicación y mediante su usuario de conexión, estará restringido sólo a operaciones de lectura sobre el resto de las entradas del directorio y los atributos que la política de seguridad de la DGTNT haya permitido (cn, sn, givenName, mail, etc.). Si en un caso muy excepcional se requiriera de accesos de escritura y/o lectura sobre otros atributos, sería necesario solicitarlo de forma explícita y justificada al responsable del Gobierno asignado para la implantación de la aplicación. Hay que tener presente que este tipo de permisos están muy controlados por motivos de seguridad Ejemplo: uid=app-user,ou=nombre_app,o=Applications,o=gobiernodecanarias,c=es Ejemplo de atributos habilitados para la escritura: appPermisos, appGrupo

Para la creación de agrupaciones de entradas (grupos de usuarios basados en LDAP), el Gobierno de Canarias propone el uso de entradas de grupo (objetos de grupo) con las clases groupOfUniqueNames y groupOfNames, que permitan una asociación lógica y bidireccional: Ejemplo de grupo: cn=Admins,ou=nombre_app,o=Applications,o=gobiernodecanarias,c=es member: uid=msegced,o=gobiernodecanarias,c=es member: uid=rmazgon,o=canarias.org,c=es … Ejemplo de miembro asociado: uid=msegced,o=gobiernodecanarias,c=es isMemberOf: cn=Admins,ou=nombre_app,o=Applications,o=gobiernodecanarias,c=es

Para la solicitud de creación de todos los elementos (OU y usuario de aplicación) referenciados, se podrá hacer uso de las plantillas adjuntas como anexo en el apartado 4.4 Plantillas de Aplicación.

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 10 de 22

3.3

Recomendaciones

3.3.1

Autenticación y autorización de usuarios

Existe un número creciente de aplicaciones que se apoyan en el servicio de directorio sólo para la autenticación de usuarios. La manera más sencilla y habitual de comprobar la identidad de un usuario es realizando una autenticación contra el servidor. Es decir: 

La aplicación solicita al usuario su código (UID) y contraseña.



La aplicación realiza una búsqueda del código de usuario (UID) y obtiene el DN.



La aplicación intenta conectar con el servidor LDAP (BIND) usando el DN y la contraseña.



La aplicación, una vez finalice todas sus tareas o deje de estar en memoria, cerrará todas las conexiones abiertas (UNBIND).

Este sencillo método permite que el usuario sólo tenga que recordar sus claves del LDAP y descarga al resto de las aplicaciones de la tediosa tarea de gestionar cuentas de usuario. Existen mecanismos en la organización mediante los cuales se define el ciclo de vida de las cuentas de usuario así como bloqueos temporales de las mismas. Estos procesos pueden llegar a inhabilitar cuentas, no permitiendo el sistema que éstas se autentiquen en el directorio si esto ocurre. 3.3.2

Autorización para el acceso a aplicaciones

Además de la autenticación de usuarios, muchas aplicaciones utilizan el servicio de directorio para comprobar los privilegios específicos de una cuenta de usuario. Esto se puede implementar de varias maneras, siendo una de las más comunes, la consulta LDAP sobre las clases asociadas a la aplicación3 que deba contener la entrada a autorizar (búsqueda filtrada por objectClass). Si el usuario dispone de las clases necesarias, entonces se consultan los atributos que especifiquen los permisos del usuario en la aplicación. Ejemplo de filtro de búsqueda para dar acceso a una aplicación que utiliza la clase “newApp”: “(&(uid=rmazgon)(objectclass=newApp))” El filtro debe devolver el puntero (DN en el argot técnico) a la entrada de usuario que intente acceder, si es que éste cumple los requisitos (posee la objectclass de autorización). Siguiendo el ejemplo de la clase “newApp”: dn: uid=rmazgon,o=canarias.org,c=es objectclass: newApp uid: rmazgon

3

Para el desarrollo de aplicaciones específicas, que necesitaran el uso de clases y atributos no incluidos en el directorio, sería necesaria la ampliación del esquema.

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 11 de 22

3.3.3

Tolerancia a fallos

La DGTNT pone todos los medios a su alcance para garantizar la disponibilidad del Servicio, usando sistemas redundantes, con tolerancia a fallos y balanceadores de carga. Sin embargo, al igual que los clientes que consultan el servicio de DNS, es deseable que las aplicaciones permitan configurar más de un servidor. Así, en caso de fallo del servidor “primario”, el cliente repite la consulta contra uno de los servidores “secundarios” (o de backup). 3.3.4

Ampliación del esquema

El esquema de un directorio representa el conjunto de las clases, atributos y sintaxis posibles para los mismos. Es importante evitar la proliferación del esquema con clases y atributos propietarios. En la medida de lo posible se debe intentar utilizar las clases y atributos estándar 4 y evitar la duplicación atributos existentes. Por ejemplo, si ya existe un atributo para almacenar el NIF de un usuario, se debería usar ese y no crear otro nuevo. Tampoco es recomendable utilizar un atributo estándar con otro contenido distinto del esperado. Durante el desarrollo de una aplicación, ésta se puede diseñar para que implemente sus mecanismos de autorización basándose en el directorio. Si para ello necesitara hacer uso de clases y atributos propietarios, y así quedara justificado bajo el criterio de los departamentos responsables de la DGTNT, sería necesario llevar a cabo una ampliación del esquema. Este mecanismo se utilizará siempre que no se pueda implementar mediante la creación de grupos de usuarios basados en LDAP. Para la ampliación del esquema, sería obligatorio presentar una propuesta de las clases y atributos a incluir, tal que: 

Clase: o Descripción: o OID5: o Atributos requeridos6:  Atributo1: Multi-valor:  …  AtributoN: Multi-valor: o Atributos permitidos7:  Atributo1: Multi-valor:  …  AtributoN: Multi-valor:



Se recomienda que las sintaxis de los atributos propietarios se basen en tipo “Directory String”. No se permitirá la ampliación de nuevas sintaxis en el esquema.

4

Son atributos con una descripción del contenido estandarizada en un RFC.

5

Si la clase fuera estándar, representaría el OID que se le ha asignado bajo la ASN.1. Si se tratara de una clase propietaria, se omitiría este valor. 6

Han de estar incluidos en cada entrada LDAP que contenga esta clase.

7

Pueden estar o no presentes en la entrada LDAP que contenga esta clase.

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 12 de 22

Es altamente recomendable indexar aquellos tributos propietarios que sean usados masivamente, como atributos de fltro para las aplicaciones. 3.3.5

Indexación de atributos

Para optimizar los tiempos de búsquedas, y no comprometer el servicio mediante búsquedas pesadas que sobrecarguen el sistema, o produzcan sensación de lentitud en las aplicaciones, es altamente recomendable el realizar búsquedas mediante el uso de atributos indexados. La indexación de un atributo bajo LDAP puede estar presente de tres formas diferentes: 

Indexación por presencia de atributo: el atributo por el que se busca alguna entrada, ha de estar presente en la entrada.

Ejemplo de filtro de presencia: (mail=*) Devuelve todas aquellas entradas que contenga el atributo “mail”. 

Indexación por igualdad: el valor del atributo por el que se busca, debe coincidir exactamente con el patrón buscado: (atributo=patrón)

Ejemplo de filtro de igualdad: (estado=activo) Devuelve todas aquellas entradas que tengan exactamente el valor “activo” presente en el atributo “estado”. 

Indexación por subcadena: el valor del atributo por el que se busca, debe coincidir parcialmente con el patrón buscado, pudiendo utilizarse el valor comodín “*” para re-emplazar partes del patrón a localizar: (atributo=patr*). El único requisito es que el patrón debe contener al menos 3 caracteres. De tener menos, el índice no aplica.

Ejemplo de filtro de subcadena: (mail=*@midominio,org) Devuelve todas aquellas entradas que tengan la subcadena “@midominio.org” presente en el atributo “mail”. En el anexo 4.5 se puede localizar un listado de los atributos genéricos que actualmente están indexados para todas las aplicaciones. 3.3.6

Soporte de referencias

Cuando un cliente realiza una petición al servidor de directorio, puede suceder que el servidor no devuelva directamente los datos solicitados, sino una referencia (referral). Una referencia es una redirección a otro servidor de directorio que consiste en una URL completa, donde se especifica el servidor, puerto y base de búsqueda.

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 13 de 22

3.3.7

Bajo el esquema del directorio corporativo LDAP, existe un referral para el sufijo “o=SPE”, que lo vincula con el servicio de directorio LDAP de Terceros.Búsqueda de entradas

Cuando se utiliza por primera vez un objeto, lo aconsejable es realizar primero una búsqueda (por ejemplo utilizando el UID) y obtener de su resultado, el DN (Distinguished Name) completo. Entonces, durante el resto de la sesión, se puede utilizar el DN completo para referenciarlo. Cuando se realiza una búsqueda que puede devolver múltiples entradas, es conveniente limitar el número de entradas coincidentes. Aunque el propio servidor LDAP limita el número máximo de entradas devueltas por una búsqueda, este límite es bastante alto (del orden de 2000 coincidencias). Por lo tanto, para mejorar los tiempos de respuesta y evitar problemas de rendimiento en el servidor, es conveniente limitar en el software cliente el número de coincidencias a un valor razonable bajo como por ejemplo 50 o 100 entradas. Para mejorar los tiempos de respuesta del servidor LDAP, se recomienda hacer búsquedas de manera que se minimicen el número de entradas coincidentes. También es conveniente filtrar los resultados de una búsqueda usando los atributos indexados y evitar el uso de comodines. Por ejemplo, no es recomendable usar filtros como (mail=*juan.perez*). Como norma general para la búsqueda de usuarios, se recomienda el uso del atributo UID como filtro, o cualquier otro atributo que esté indexado, y que proporcione unos resultados de búsqueda óptimos. El RFC 2254 - The String Representation of LDAP Search Filters, indica de una manera sencilla, cómo especificar un filtro de búsqueda en formato de texto, de forma que sea legible por un humano. 3.3.8

Denegación de búsquedas masivas no indexadas

Por defecto, el sistema está blindado para evitar denegación de servicio o deterioro del rendimiento, ante búsquedas masivas de datos que puedan provocarlo, bien porque los filtros de búsqueda que se usen no son filtro indexados, o porque el resultado del filtro usado devuelve más de 4000 entradas. En el caso de que cualquier aplicación requiriera hacer uso de filtros no indexados (que devuelvan más de 4000 entradas o que usen filtros no indexados), es necesario contar con una autorización especial a nivel de acceso, que se debe solicitar y que tiene que estar formalmente justificada. 3.3.9

Tiempos de espera

Si la aplicación cliente lo permite, puede configurarse un tiempo máximo de espera (timeout) para el establecimiento de la conexión con el servidor de 60 segundos. Si la conexión no se establece en ese tiempo, se debe considerar que el servidor no está disponible. Cuando se realiza una búsqueda, es común especificar el tiempo máximo de espera para que se complete la búsqueda. Normalmente este valor suele configurarse a unos 30 segundos. 3.3.10 Uso de las conexiones En el caso de que la aplicación requiera hacer un gran número de consultas en un corto espacio de tiempo, es recomendable crear y mantener abierta una misma conexión, realizar todos los accesos

CIBERC-IGT-015020-12

Normativa de Uso del Directorio

Página 14 de 22 necesarios al LDAP y liberar la conexión finalizando la sesión correctamente, es decir, enviando al servidor el mensaje de desconexión (unbind). 3.3.11 Mayúsculas y minúsculas Las aplicaciones no deberán distinguir entre mayúsculas o minúsculas, tanto en los valores devueltos como en los nombres de los atributos y las clases. Sin embargo, cuando se realice el alta de una entrada, su UID debe crearse en minúsculas, para evitar problemas con las aplicaciones de terceros que lean esta información y que sean sensibles a esta característica. 3.3.12 Desarrollo de aplicaciones Este apartado proporciona un seudo-código, haciendo uso de las funciones descritas en el RFC 1823 - The LDAP Application Program Interface, que puede ayudar a los desarrolladores para implementar en un lenguaje específico, las funciones de acceso al servicio de directorio. Para explicar el seudo-código se hará uso de las variables siguientes: 

SERVER = Dirección FQDN del servidor LDAP

  

PORT = Puerto específico del servidor LDAP USER_APP = DN del usuario genérico de aplicación que hace uso del LDAP PASSWORD_APP = Clave asociada al USERDN_APP

    

UID_USR = Código del usuario final USER_USR = DN del usuario final (de la aplicación que hace uso del LDAP) PASSWORD_USR = SCOPE = “SUB”, para poder realizar búsquedas en todo el subárbol FILTER = “(uid=UID_USR)”



BASEDN = Base de búsqueda (sufijo o nivel) de la jerarquía del directorio sobre la que empezar ha realizar la búsqueda.

Como norma general, el usuario introduce sus credenciales en la aplicación y ésta trata de validar dichas credenciales contra el servicio de directorio. El siguiente esquema muestra, de manera simplificada, el modo habitual de operación: ldap_bind(USER_APP,PASSWORD_APP)

ldap_search(CONEXION_APP, BASEDN, SCOPE, FILTER, USER_USR)

Login(USER_USR,PASSWORD_USR)

Usuario final

ldap_bind(USER_USR,PASSWORD_USR)

Directorio

Aplicación

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 15 de 22

El código para que una aplicación autentique sus usuarios contra el LDAP, sin tener en cuenta el tratamiento de todos los errores y excepciones, puede implementarse de la siguiente manera: CONEXION_APP = ldap_open(SERVER, PORT); SI (CONEXION_APP != NULL) ENTONCES RESULT = ldap_bind(CONEXION_APP, USER_APP, PASSWORD_APP); SI (RESULT == LDAP_SUCCESS) ENTONCES RESULT = ldap_search(CONEXION_APP, BASEDN, SCOPE, FILTER, USER_USR) ENTONCES SI (RESULT == LDAP_SUCCESS) ENTONCES /* Usuario encontrado, intentar autenticación */ CONEXION_USR = ldap_open(SERVER, PORT); SI (CONEXION_USR != NULL) ENTONCES RESULT = ldap_bind(CONEXION_USR, USER_USR, PASSWORD_USR); SI (RESULT == LDAP_SUCCESS) ENTONCES /* Usuario autenticado correctamente */ ldap_unbind(CONEXION_USR); EN_OTRO_CASO /* Usuario no autenticado, error de contraseña */ EN_OTRO_CASO /* Usuario no autenticado, usuario no encontrado */ ldap_unbind(CONEXION_APP); EN_OTRO_CASO /* Error de conexión al servidor LDAP con el usuario de la aplicación */ Para la inmensa mayoría de los lenguaje de programación (C, Java, VisualBasic, Perl,..) existen librerías, APIs y fragmentos de código a modo de ejemplo para facilitar el establecimiento de la conexión, realizar las búsquedas y el control de errores.

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 16 de 22

4 Anexos 4.1

Glosario

ACI

Access Control Item Determina quién tiene un determinado tipo de acceso a una rama del directorio.

Autenticación Proceso por el que se determina si una persona (o aplicación) es realmente quien dice ser. La identidad puede probarse de diversas maneras, siendo la más extendida el utilizar una pareja de identificación: usuario + clave. Base DN

Nodo del árbol LDAP que se usará como raíz en las búsquedas.

BIND

Conexión de una aplicación cliente a un servidor LDAP utilizando credenciales.

Cliente

En el modelo cliente-servidor, un cliente es la aplicación que accede a un servicio.

DN

Distinguished Name Es una cadena de texto que describe, de manera única, la ruta en el árbol del directorio requerida para acceder a una entrada desde la raíz del directorio.

Esquema

Conjunto de reglas que definen los tipos de datos que pueden almacenarse en un directorio LDAP.

LDAP

Lightweight Directory Access Protocol Protocolo estándar que provee acceso para el acceso (tanto de lectura como de escritura) y la gestión de directorios compatibles con X.500.

LDIF

LDAP Data Interchange Format Es un formato de texto para describir objetos del servicio de directorio y sus atributos.

RFC

Request For Comments Recopilan normativas de estándares de Internet.

SHA / SSHA

Secure Hash Algorithm / Salted Secure Hash Algorithm Algoritmo de encriptación utilizado para almacenar claves.

UID

Unique Identifier Atributo utilizado para identificar unívocamente a una entrada LDAP, sin necesidad de conocer su DN completo.

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 17 de 22

4.2

Ejemplos de configuración de clientes

4.2.1

Libreta de direcciones de Microsoft Outlook Express

4.2.2

Softerra LDAP Browser

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 18 de 22

4.3

Documentación complementaria

Las aplicaciones que utilizan el directorio (LDAP) deben informar a la DGTNT los siguientes datos: Datos administrativos Aplicación

Nombre descriptivo de la aplicación

Tipo Aplicación

□ Software desarrollado ad-hoc (Interno o Externo) □ Software estándar

Servidor Producción

Servidor de explotación desde la que se lanzan las peticiones LDAP

Servidor Preexplotación

Servidor de pre-explotación desde la que se lanzan las peticiones LDAP

Autorizador

Persona responsable de autorizar y/o supervisar cambios

Contacto técnico

Persona o grupo que implementa los cambios técnicos

Datos técnicos Usuario LDAP

DN LDAP usado por la aplicación de acceso al LDAP

Servidor LDAP

Nombre del servidor contra el que se lanzan las peticiones

Atributos Lectura

Lista de atributos sobre los que la aplicación accede en modo lectura

Atributos Escritura

Lista de atributos sobre los que la aplicación accede en modo escritura

Clases

Lista de las clases

Nota

Anotaciones de interés

(Esquema gráfico)

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 19 de 22

4.4

Plantillas LDIF de aplicación

4.4.1 Unidad Organizativa de la aplicación (si la requiere para escritura) dn: ou=,o=Applications,o=gobiernodecanarias,c=es ou: objectClass: top objectClass: organizationalunit description:

4.4.2 Usuario de conexión de la aplicación (bajo su propia Unidad Organizativa) dn: uid=,ou=,o=Applications,o=gobiernodecanarias,c=es sn: objectClass: top objectClass: person objectClass: inetUser objectClass: organizationalPerson objectClass: inetOrgPerson givenName: uid: cn: -

4.4.3 Usuario de conexión de la aplicación de lectura (sin Unidad Organizativa propia) dn: uid=,o=Applications,o=gobiernodecanarias,c=es sn: objectClass: top objectClass: person objectClass: inetUser objectClass: organizationalPerson objectClass: inetOrgPerson givenName: uid: cn: -

4.4.4 Grupo de entradas (grupo de usuarios) dn: cn=, ou=,o=Applications,o=gobiernodecanarias,c=es cn: objectClass: top objectClass: groupOfNames objectClass: groupOfUniqueNames member: member: …

CIBERC-IGT-015020-12

Normativa de Uso del Directorio

Página 20 de 22 4.5

Atributos genéricos indexados en el directorio Nombre / Tipo

Presencia

Igualdad

Subcadena

cn

X

X

X

gdcdni

X

X

gdcfechadesactivacion

X

X

X

givenName

X

X

X

inetuserstatus

X

X

ismemberof

X

X

mailAlternateAddress

X

X

X

mail

X

X

X

member

X

X

X

memberOf

X

X

X

memberuid

X

X

X

nif

X

X

X

objectclass

X

X

o

X

X

X

ou

X

X

X

privatetelephonenumber

X

X

X

sn

X

X

X

telephoneNumber

X

X

X

uid

X

X

X

uniquemember

X

X

X

userprincipalname

X

X

X

employeenumber

X

X

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 21 de 22

5 Referencias Documento

RFC 4510 – LDAP Technical Specification Road Map

Descripción

Este documento es sólo una lista de las especificaciones técnicas sobre LDAP

Ubicación

http://tools.ietf.org/html/rfc4510

Documento

RFC 2849 – The LDAP Data Interchange Format (LDIF)

Descripción

Formato de fichero para describir información o modificar datos de un directorio

Ubicación

http://www.faqs.org/rfcs/rfc2849.html

Documento

RFC 4515 - The String Representation of LDAP Search Filters

Descripción

Recomendaciones para crear un filtro de búsqueda en formato texto (LDAPv3)

Ubicación

http://tools.ietf.org/html/rfc4515

Documento

RFC 1823 - The LDAP Application Program Interface

Descripción

Definición de una API en C para LDAP, con código de ejemplo

Ubicación

http://www.faqs.org/rfcs/rfc1823.html

Documento

RFC 4519 – LDAP Schema for User Applications

Descripción

Descripción de las clases y atributos comunes utilizados por clientes LDAP para servicios como libretas de direcciones o páginas blancas.

Ubicación

http://tools.ietf.org/html/rfc4519

Documento

Best Practices Guide for Sun Java System Directory Server

Descripción

Recomendaciones para el desarrollo de aplicaciones que interactúan con LDAP

Ubicación

http://developers.sun.com/prodtech/dirserver/reference/techart/bestpractices.html

Normativa de Uso del Directorio

CIBERC-IGT-015020-12 Página 22 de 22

6 Contactos Persona de contacto

CiberCentro

Teléfono interno

912

Teléfonos

902 111 912 - 922 922 912 - 928 117 912

Fax red interna

922 474 880 (24880) - 928 307 880 (87880)

Fax

902 345 880

Correo electrónico

[email protected]