¿Por qué las empresas no utilizan LDAP como repositorio central para usuarios que no sean usuarios?

Question

En cada una de las grandes empresas para las que trabajé usaban LDAP como una forma de acceder al repositorio central de información de usuario, pero muy pocas han tomado medidas para extender el esquema para incluir objectClasses que no se derivan de inetOrgPerson.

El Active Directory de Microsoft ofrece extensas extensiones de esquema pero muy pocos productos comerciales aprovechan las capacidades de LDAP.

¿Es porque la mayoría de los desarrolladores de LDAP no saben cómo modelar más allá de los usuarios? ¿Encuentra valor en él pero no lo ha pensado profundamente? Lo he probado y encontré problemas de rendimiento? ¿Algo más? L

Answer 1

Hemos trabajado para algunas empresas con 65 millones de registros LDAP y ninguno de los registros era para personas.

Los datos eran una variedad de artículos sobre todo para los dispositivos que incluyen: * DHCP DNS * * direcciones MAC * Ubicación * SN * Marca * Modelo * etc ....

- jim

Answer 2

Creo que es debido a A) la complejidad de trabajar con LDAP (mucho más alto que SQL) y B) el hecho de que su producto estaría atado completamente a él. Es decir, no tendría mercado fuera de las grandes organizaciones que ejecutan LDAP. Por menos dinero y esfuerzo, podría construir una aplicación que funcione en cualquier lugar.

Ahora, interno aplicaciones escritas específicamente para la organización que necesitan acceso a otros datos LDAP son una historia diferente. Pero obviamente escuchará menos sobre ellos porque no se comercializan comercialmente. LDAP

Answer 3

• Siempre he pensado que era demasiado alto nivel de los administradores de red y demasiado bajo nivel para los desarrolladores de software. Ninguno de los dos parece sentirse cómodo con eso.
• Existe la percepción de que, dado que casi todas las aplicaciones empresariales usarán una base de datos relacional, la adición de una fuente de datos adicional reduce la disponibilidad y la confiabilidad de la aplicación.
• La barrera para crear esquemas personalizados en LDAP sigue siendo alta. En los servidores LDAP, debe colocar el archivo de esquema en el directorio de esquema, generalmente con privilegios de administrador o raíz y reiniciar el servidor LDAP; mientras que los ORM actuales pueden crear, actualizar o verificar esquemas de bases de datos relacionales cuando se inicia la aplicación.

Answer 4

personalmente creo que es porque LDAP es un directorio , no una base de datos. Los directorios son buenos para buscar personas y sus datos asociados, pero no son particularmente buenos para rastrear datos altamente relacionales, que es como se ve el resto de nuestros datos. De hecho, nuestro uso de LDAP es en realidad un front-end para datos de "personas", combinando muchas secuencias de datos en una única vista de directorio. Todavía tenemos los datos de "personas" en las bases de datos de back-end junto con el resto de nuestros datos institucionales y solo hemos elegido LDAP (en nuestro caso ADAM) como front-end para permitir una búsqueda conveniente de los datos "personas" fusionadas. Ahora que nos estamos moviendo a los servicios web como medio para acceder a estos datos, no estoy seguro de que tenga sentido continuar por la ruta LDAP (excepto para admitir los servicios existentes que no se han actualizado).

Answer 5

Pensé que LDAP estaba altamente optimizado para lecturas rápidas y frecuentes. No creo que escalarían por sistemas transaccionales.

El modelo relacional y su expresión en SQL es algo poderoso. No creo que sea suplantado fácilmente por LDAP o las bases de datos de objetos.