Creo que me estoy aficionando a las series de posts no de la tele, ya que acabo de terminar la serie de artículos acerca de cómo acceder a la caché de Internet Explorer y ya estoy planteándome una nueva, sobre acceder al directorio activo mediante una aplicación realizada con C#. Esta serie, al igual que la anterior intentará ser lo más directa y práctica posible, y del mismo modo al final de la serie publicaré el código completo del ejemplo para su descarga.
El motivo...
...de esta serie es porque tanto en los foros como en los grupos de notícias, es muy común encontrar preguntas muy variadas acerca de cómo acceder a LDAP desde una aplicación .NET. Así que me he planteado empezar una serie de posts en los que mostraremos varios ejemplos: Mostrar información del usuario actual de Windows, averiguar los grupos a los que pertenece, validar credenciales contra un dominio para saber si son correctas, impersonar nuestra aplicación para que se ejecute con las credenciales de otro usuario, buscar usuarios o grupos en LDAP, extraer la lista de propiedades del objeto usuario, etc.
¿LDAP o Directorio Activo?
Antes de empezar quiero hacer una aclaración: ¿Es lo mismo LDAP que Directorio Activo? No, no es lo mismo.
LDAP es el acrónimo de (Lightweight Directory Access Protocol) que es es un protocolo a nivel de aplicación que permite el acceso a un servicio de directorio ordenado y distribuido para buscar diversa información en un entorno de red. Habitualmente se utiliza para acceder a la información almacenada de usuarios, grupos y equipos de una organizació y existen muchas implementaciones de este protocolo, desde Microsoft hasta Novell pasando por Red Hat, iPlanet u OpenLDAP.
El directorio Activo o AD es la implementación de LDAP realizada por Microsoft en su família Windows Server. Al igual que LDAP permite acceder a distintos tipos de objetos almacenados que representan los elementos de la organización. Cada uno de estos objetos tendrá atributos que permiten identificarlos en modo unívoco (por ejemplo, los usuarios tendrán campo "nombre", campo "email", etc..., las impresoras de red tendrán campo "nombre", campo "fabricante", campo "modelo", campo "usuarios que pueden acceder", etc). Toda esta información queda almacenada en Active Directory replicándose de forma automática entre todos los servidores que controlan el acceso al dominio.
Situaciones cotidianas
Nosotros los desarrolladores, como creadores de aplicaciones que deben coexistir en un entorno corporativo, cada vez nos encontramos en más ocasiones en las que nuestra aplicación debe utilizar los usuarios y grupos del AD de la empresa, en lugar de almacenar una base de datos propia de usuarios y grupos. Incluso me atrevería a decir que la frontera entre una aplicación madura, de uso corporativo, y que se integre con otras aplicaciones y servicios, a veces estriba en detalles como éste.
Hoy en día cada vez más empresas disponen de la figura del administrador del AD, que gestiona todos los datos de los empleados de la misma, de modo que ¿para que van a mantener otra base de datos con los usuarios de una aplicación, si éstos ya existen en el AD? Incluso puede ser peor ¿os imagináis cuántas aplicaciones funcionan de este modo? ¿Debemos mantener X bases de datos de usuarios por X aplicaciones? Esto puede ser el caos... ¡imaginaos la de datos duplicados que existen y lo difícil que resulta mantenerlos!
Gracias al .NET framework, hoy en día podemos integrar nuestras aplicaciones con el AD de la empresa, de forma que podamos aprovechar la ventaja de contar con un repositorio centralizado. De este modo podremos dejar en manos del administrador del AD la creación de usuarios, grupos y cómo se relacionan entre ellos, y nosotros encargarnos de lo que realimente nos importa: La aplicación.
En el próximo post empezaremos a construir nuestra aplicación de ejemplo, y para ello contaremos con la ayuda del namespace System.Security.Principal y de System.DirectoryServices... hasta entonces!