Cómo encontrar una URL LDAP

RFC 4516 define URL LDAP. Proporciona una forma de codificar los parámetros de una operación de búsqueda LDAP en una URL estándar. Si conoce el DN del objeto y el servidor LDAP que desea consultar, puede componer la URL LDAP para él. Básicamente, la URL LDAP se compone de lo siguiente:

  1. El esquema “ldap”, por ejemplo, “ldap: //”
  2. Nombre de host y puerto opcionales, por ejemplo: “http://dc1.megacorp.com:389”. Si no proporciona un nombre de host y un puerto, su cliente debe tener otra forma de averiguar el servidor al que conectarse. 389 es el puerto predeterminado.
  3. DN opcional del objeto base de la búsqueda, escapado correctamente para formar parte de una URL válida. “Dc = com, dc = megacorp, ou = Contabilidad”. El valor predeterminado es el DN vacío, que se refiere al rootDSE.
  4. Parámetros de URL opcionales para los atributos, el alcance y el filtro, separados por signos de interrogación, por ejemplo, “? DisplayName, mail? Sub? (ObjectClass = User)”. Puede dejar uno o todos ellos vacíos (los valores predeterminados se describen en el RFC), pero los signos de interrogación deben permanecer.
  5. Especificadores de control LDAP opcionales, como “1.2.840.113556.1.4.1339” (para los controles que requieren un valor, agrega un signo igual y el valor).

La URL para consultar a todos los usuarios en la unidad organizativa “Hanford West” podría verse así:

ldap: //dc2.megacorp.com/dc=com,dc=megacorp,ou=Hanford%20West ?? sub? (objectClass = User)

Sin embargo, todo lo que la URL hace por ti es identificar un recurso. Es necesario que haya un servicio web en esa ubicación que realmente analice la consulta y devuelva los resultados, que generalmente no es un comportamiento listo para usar para los directorios LDAP. Por lo general, debe tener un servicio web de tipo proxy para manejar eso para aceptar URL HTTP, consultar un directorio y luego devolver los resultados, por ejemplo, Directory Server Gateway.

El RFC no especifica cómo se deben formatear los datos devueltos … podrían ser páginas web, o JSON, o XML, o lo que sea. Dependerá de la implementación de su servicio web. Del mismo modo, el comportamiento de actualización no se especifica. En teoría, PUT, PATCH y DELETE deberían funcionar, pero nuevamente depende de la implementación.

También notará que no he dicho nada sobre la autenticación. Se aplican los mecanismos HTTP normales y, una vez más, los detalles dependen de la implementación del servicio web.