El blog de Lluis Franco : LDAP

HowTo: Obtener TODOS los usuarios de un grupo del Directorio Activo

lfranco — Mon, 30 Nov 2009 16:58:36 GMT

Siguiendo con el tema de las últimas entradas, vamos a ver cómo obtener TODOS los usuarios que pertenecen a un grupo del directorio activo. Y cuando digo TODOS los usuarios, me refiero a TODOS (por algo lo he puesto en mayúsculas :-D). Es decir, dentro de un grupo podemos tener otros grupos, que a su vez contengan otros grupos y así succesivamente... y nuestro objetivo es obtener todos los usuarios de forma recursiva.

Para obtener los datos de estos usuarios vamos a crear una clase, para ir almacenando las propiedades que deseamos obtener de cada usuario. Y una función que obtenga los usuarios de un grupo, y se llame a sí misma de forma recursiva en caso que este grupo contenga otros grupos.

El código de la clase:

public class ADUser

    public byte[] Sid { get; set; }

    public string Name { get; set; }

    public string DistinguishedName { get; set; }

    public string SAMAccountName { get; set; }

    public int RoleType { get; set; }

    public ADUser(byte[] sid, string name,

        string distinguishedName, string sAMAccountName)

        Sid = sid;

        Name = name;

        DistinguishedName = distinguishedName;

        SAMAccountName = sAMAccountName;

    public string sIDtoString()

        SecurityIdentifier sid = new SecurityIdentifier(Sid, 0);

        return sid.ToString();

Y el método que devuelve todos los usuarios de un grupo de forma recursiva:

namespace Alpha.Code

    public class SecurityContextEx

        public static string getDomainName()

            return IPGlobalProperties.GetIPGlobalProperties().DomainName;

        public static string getLDAPDomainName(string domainName)

            StringBuilder sb = new StringBuilder();

            string[] dcItems = domainName.Split(".".ToCharArray());

            sb.Append("LDAP://");

            foreach (string item in dcItems)

                sb.AppendFormat("DC={0},", item);

            return sb.ToString().Substring(0, sb.ToString().Length - 1);

        public static List<ADUser> GetUsersInGroup(string group)

            List<ADUser> users = new List<ADUser>();

            string ldapDomainName = SecurityContext.getLDAPDomainName(SecurityContext.getDomainName());

            string domainName = ldapDomainName.Replace("LDAP://", string.Empty);

            List<string> groupMemebers = new List<string>();

            DirectoryEntry de = new DirectoryEntry(ldapDomainName);

            DirectorySearcher ds = new DirectorySearcher(de, "(objectClass=person)");

            ds.Filter = "(&(objectClass=group)(cn=" + group + "))";

            foreach (SearchResult result in ds.FindAll())

                var dir = result.GetDirectoryEntry();

                var list = dir.Invoke("Members");

                IEnumerable entries = (IEnumerable)list;

                foreach (var entry in entries)

                    DirectoryEntry member = new DirectoryEntry(entry);

                    if (member.SchemaClassName == "group")

                        List<ADUser> usersInGroup =

                            GetUsersInGroup(member.Properties["name"][0].ToString());

                        foreach (ADUser aduser in usersInGroup)

                            if (!users.ToDictionary(u => u.Name).ContainsKey(aduser.Name))

                                users.Add(aduser);

                    else

                        ADUser aduser = new ADUser(

                            (byte[])member.Properties["objectSid"][0],

                            member.Properties["name"][0].ToString(),

                            member.Properties["distinguishedName"][0].ToString(),

                            member.Properties["sAMAccountName"][0].ToString());

                        users.Add(aduser);

            return users;

Aparte de la función GetUsersInGroup, también existen un par de métodos de apoyo para averiguar el nombre de nuestro dominio, que creo recordar que he publicado con anterioridad, pero por si acaso os los he publicado también.

Si deseamos obtener los usuarios de un grupo en particular, basta con usarlo de este modo:

List<ADUser> users = SecurityContextEx.GetUsersInGroup("My users");

Nota: En ocasiones, puede resultar una buena práctica para la administración de la seguridad de nuestras aplicaciones, crear un grupo en el directorio activo con el mismo nombre de la aplicación. Y de este modo conceder acceso a todos los miembros de dicho grupo a nuestra aplicación. En este caso todavía resultaría más sencillo mostrar todos los usuarios a los que hemos concedido acceso:

List<ADUser> users = SecurityContextEx.GetUsersInGroup(Application.ProductName);

Espero que os haya gustado,

Un saludo desde las frías tierras de Andorra :-)

Y después de la nevada de ayer, esta vez más frías que nunca…

Noviembre 2009

** crossposting desde el blog de Lluís Franco en geeks.ms **

HowTo: Agrupando grupos :-)

lfranco — Thu, 26 Nov 2009 11:53:51 GMT

Una entrada rápida, no como la de ayer. Aunque el tema está bastante relacionado ya que ambos tratan de Active Directory e identidades.

Hoy vamos a ver una forma sencilla de obtener todos los grupos a los que pertenece un usuario, y agruparlos por su nombre de dominio. Y todo esto mediante una sola sentencia LINQ to objects. A ver quién es el guapo o guapa que me dice que LINQ to objects no es una maravilla!

El resultado que vamos a obtener es el siguiente (algunos nombres se han omitido por razones obvias :-P):

Groups under:
- Group name: Todos
- Group name: LOCAL
Groups under: BUILTIN
- Group name: Usuarios
- Group name: Administradores
Groups under: PRIMARY_DOMAIN_NAME
- Group name: xxx1
- Group name: xxx2
- Group name: xxx3
- Group name: xxx4
- Group name: xxxN
Groups under: NT AUTHORITY
- Group name: INTERACTIVE
- Group name: Usuarios autentificados

Y el código resultante es un método extensor para la clase WindowsIdentity, con dos funciones auxiliares en forma de métodos extensores de la clase NTAccount:

using System;

using System.Collections.Generic;

using System.DirectoryServices;

using System.DirectoryServices.ActiveDirectory;

using System.Linq;

using System.Net.NetworkInformation;

using System.Runtime.InteropServices;

using System.Security.Principal;

using System.Text;

namespace Alpha.Code

    public static class SecurityExtensions

        public static IOrderedEnumerable<IGrouping <string, NTAccount>>

            GetGroupsUnderDomains(this WindowsIdentity identity)

            var groups =

                        from grIdentity in identity.Groups

                        where grIdentity.IsValidTargetType(typeof(NTAccount))

                        select grIdentity.Translate(typeof(NTAccount)) as NTAccount into ntAccounts

                        let domainName = ntAccounts.GetDomainName()

                        let groupName = ntAccounts.GetAccountName()

                        orderby domainName

                        group ntAccounts by domainName into domainGroups

                        orderby domainGroups.Key

                        select domainGroups;

            return groups;

        public static string GetDomainName(this NTAccount account)

            string[] split = account.Value.Split('\\');

            return split.Length == 1 ? string.Empty : split[0];

        public static string GetAccountName(this NTAccount account)

            string[] split = account.Value.Split('\\');

            return split[split.Length - 1];

Para probarlo y ver el resultado:

var groups = WindowsIdentity.GetCurrent().GetGroupsUnderDomains();

foreach (var dg in groups)

    Console.WriteLine(string.Format("Groups under: {0}", dg.Key));

    foreach (var g in dg)

        Console.WriteLine(string.Format("  - Group name: {0}", g.GetAccountName()));

Un saludo desde las frías tierras de Andorra :-)

Noviembre 2009

** crossposting desde el blog de Lluís Franco en geeks.ms **

How To: ¿Como saber si el usuario actual es administrador del dominio?

lfranco — Wed, 25 Nov 2009 18:03:00 GMT

Nota: Es una pregunta que me encuentro de forma recurrente en los foros de desarrollo, así que lo apunto aquí para tener una referencia.

El escenario

Cuando desarrollamos una aplicación de escritorio, puede ser interesante saber a qué grupos pertenece el usuario que está ejecutando nuestra aplicación, para mostrar / ocultar / permitir / revocar ciertas acciones, u opciones. Por ejemplo, yo acostumbro a tener un botón en la barra de estado de mis aplicaciones que permite cambiar la cadena de conexión, y evidentemente, solo está visible cuando el usuario pertenece al grupo “Administradores del dominio”.

IsInRole

Para ello, el objeto WindowsPrincipal dispone de un método IsInRole, que nos dirà si un usuario pertenece a un grupo determinado. Genial, además este método tiene varias sobrecargas, de modo que podemos usarlo pasando el RID, SID, el nombre e incluso una constante basada en la enumeración WindowsBuiltIOnRole:

Nombre de miembro	Descripción
AccountOperator	Los operadores de cuentas administran las cuentas de los usuarios de un equipo o dominio.
Administrator	Los administradores tienen acceso completo y sin restricciones al equipo o dominio.
BackupOperator	Los operadores de copia de seguridad pueden reemplazar las restricciones de seguridad con el único propósito de hacer copias de seguridad de los archivos o de restaurarlas.
Guest	Los invitados tienen más restricciones que los usuarios.
PowerUser	Los usuarios avanzados poseen la mayoría de los permisos administrativos, con algunas restricciones. De este modo, los usuarios avanzados pueden ejecutar aplicaciones heredadas, además de aplicaciones certificadas.
PrintOperator	Los operadores de impresión pueden tomar el control de una impresora.
Replicator	Los replicadores permiten la duplicación de archivos en un dominio.
SystemOperator	Los operadores del sistema administran un equipo en particular.
User	Los usuarios no pueden realizar cambios accidentales o intencionados en todo el sistema. En consecuencia, pueden ejecutar aplicaciones certificadas, pero no la mayoría de las aplicaciones heredadas.

De modo que para saber si nuestro usuario es administrador local, basta con hacer esto:

WindowsPrincipal wp = new WindowsPrincipal(WindowsIdentity.GetCurrent());

return wp.IsInRole(WindowsBuiltInRole.Administrator);

Sencillo, verdad? A partir del usuario que ejecuta nuestra aplicación (válido también en caso de impersonación), creamos un objeto Principal e invocamos al método pasándole el grupo contra el que deseamos validar.

El problema de esta enumeración es que como su nombre indica, sólo contempla los grupos locales. Así que si queremos saber si pertenece a un grupo del dominio parece que tendremos que buscar el SID del grupo, o el nombre, y hardcodearlo ‘a mano’ en nuestra aplicación.

Feo verdad? Pues la verdad es que si, muy feo… vamos a investigar un poco más, a ver si encontramos otra forma.

Nota: Por motivos de rendimiento, para determinar la función del usuario se recomienda utilizar la sobrecarga de IsInRole(SecurityIdentifier) como sobrecarga preferible.

WellKnownSidType

Existe una enumeración llamada WellKnownSidType, que devuelve los identificadores de seguridad más utilizados, vamos a darle un vistazo:

Member name	Description
NullSid	Indicates a null SID.
WorldSid	Indicates a SID that matches everyone.
LocalSid	Indicates a local SID.
CreatorOwnerSid	Indicates a SID that matches the owner or creator of an object.
CreatorGroupSid	Indicates a SID that matches the creator group of an object.
CreatorOwnerServerSid	Indicates a creator owner server SID.
CreatorGroupServerSid	Indicates a creator group server SID.
NTAuthoritySid	Indicates a SID for the Windows NT authority.
DialupSid	Indicates a SID for a dial-up account.
NetworkSid	Indicates a SID for a network account. This SID is added to the process of a token when it logs on across a network.
BatchSid	Indicates a SID for a batch process. This SID is added to the process of a token when it logs on as a batch job.
InteractiveSid	Indicates a SID for an interactive account. This SID is added to the process of a token when it logs on interactively.
ServiceSid	Indicates a SID for a service. This SID is added to the process of a token when it logs on as a service.
AnonymousSid	Indicates a SID for the anonymous account.
ProxySid	Indicates a proxy SID.
EnterpriseControllersSid	Indicates a SID for an enterprise controller.
SelfSid	Indicates a SID for self.
AuthenticatedUserSid	Indicates a SID for an authenticated user.
RestrictedCodeSid	Indicates a SID for restricted code.
TerminalServerSid	Indicates a SID that matches a terminal server account.
RemoteLogonIdSid	Indicates a SID that matches remote logons.
LogonIdsSid	Indicates a SID that matches logon IDs.
LocalSystemSid	Indicates a SID that matches the local system.
LocalServiceSid	Indicates a SID that matches a local service.
NetworkServiceSid	Indicates a SID that matches a network service.
BuiltinDomainSid	Indicates a SID that matches the domain account.
BuiltinAdministratorsSid	Indicates a SID that matches the administrator account.
BuiltinUsersSid	Indicates a SID that matches built-in user accounts.
BuiltinGuestsSid	Indicates a SID that matches the guest account.
BuiltinPowerUsersSid	Indicates a SID that matches the power users group.
BuiltinAccountOperatorsSid	Indicates a SID that matches the account operators account.
BuiltinSystemOperatorsSid	Indicates a SID that matches the system operators group.
BuiltinPrintOperatorsSid	Indicates a SID that matches the print operators group.
BuiltinBackupOperatorsSid	Indicates a SID that matches the backup operators group.
BuiltinReplicatorSid	Indicates a SID that matches the replicator account.
BuiltinPreWindows2000CompatibleAccessSid	Indicates a SID that matches pre-Windows 2000 compatible accounts.
BuiltinRemoteDesktopUsersSid	Indicates a SID that matches remote desktop users.
BuiltinNetworkConfigurationOperatorsSid	Indicates a SID that matches the network operators group.
AccountAdministratorSid	Indicates a SID that matches the account administrators group.
AccountGuestSid	Indicates a SID that matches the account guest group.
AccountKrbtgtSid	Indicates a SID that matches the account Kerberos target group.
AccountDomainAdminsSid	Indicates a SID that matches the account domain administrator group.
AccountDomainUsersSid	Indicates a SID that matches the account domain users group.
AccountDomainGuestsSid	Indicates a SID that matches the account domain guests group.
AccountComputersSid	Indicates a SID that matches the account computer group.
AccountControllersSid	Indicates a SID that matches the account controller group.
AccountCertAdminsSid	Indicates a SID that matches the certificate administrators group.
AccountSchemaAdminsSid	Indicates a SID that matches the schema administrators group.
AccountEnterpriseAdminsSid	Indicates a SID that matches the enterprise administrators group.
AccountPolicyAdminsSid	Indicates a SID that matches the policy administrators group.
AccountRasAndIasServersSid	Indicates a SID that matches the RAS and IAS server account.
NtlmAuthenticationSid	Indicates a SID present when the Microsoft NTLM authentication package authenticated the client.
DigestAuthenticationSid	Indicates a SID present when the Microsoft Digest authentication package authenticated the client.
SChannelAuthenticationSid	Indicates a SID present when the Secure Channel (SSL/TLS) authentication package authenticated the client.
ThisOrganizationSid	Indicates a SID present when the user authenticated from within the forest or across a trust that does not have the selective authentication option enabled. If this SID is present, then OtherOrganizationSid cannot be present.
OtherOrganizationSid	Indicates a SID present when the user authenticated across a forest with the selective authentication option enabled. If this SID is present, then ThisOrganizationSid cannot be present.
BuiltinIncomingForestTrustBuildersSid	Indicates a SID that allows a user to create incoming forest trusts. It is added to the token of users who are a member of the Incoming Forest Trust Builders built-in group in the root domain of the forest.
BuiltinPerformanceMonitoringUsersSid	Indicates a SID that matches the group of users that have remote access to schedule logging of performance counters on this computer.
BuiltinPerformanceLoggingUsersSid	Indicates a SID that matches the group of users that have remote access to monitor the computer.
BuiltinAuthorizationAccessSid	Indicates a SID that matches the Windows Authorization Access group.
WinBuiltinTerminalServerLicenseServersSid	Indicates a SID is present in a server that can issue Terminal Server licenses.
MaxDefined	Indicates the maximum defined SID in the WellKnownSidType enumeration.

BINGO!!! Parece que tenemos el SID del grupo de admnistradores del dominio (lo he marcado en rojo en la tabla anterior).

Ahora vamos a generar el SID del grupo de adminstradores del dominio y ya podemos volver a probar el método IsInRole:

WindowsPrincipal wp = new WindowsPrincipal(WindowsIdentity.GetCurrent());

SecurityIdentifier sid = new SecurityIdentifier(WellKnownSidType.AccountDomainAdminsSid, null);

return wp.IsInRole(sid);

Ops! Nuestro gozo en un pozo… se necesita informar el segundo argumento del constructor para el SID del grupo:

DomainSid

¿Y que kkgrnn$# representa que es este identificador? Pues según pone en la ayuda del constructor, debe proporcionarse el SID del dominio para que el constructor pueda devolver algunos identificadores de WellKnownSidType, entre los cuales está el de los administradores del dominio.

Dicho de otro modo, o sabemos el SID de nuestro dominio o todo lo anterior no vale para nada… :-(

¿Y cómo podemos saber el SID de dominio? Después de buscar un ratito, lo único que he encontrado es una utilidad de consola llamada PsGetSid, que forma parte de las PSTools del inefable Mark Russinovich. Basta descargar esta utilidad y ejecutarla desde la consola de este modo para saber el SID de nuestro dominio (el nombre de dominio en formato “microsoft.com” o “net.volvo.com”):

Sin embargo, me niego a tener que hacer esto para saber el identificador del dominio. Así que vamos a probar si podemos recuperar esta propiedad del esquema de AD mediante un DirectoryEntry. Para ello utilizaremos la clase Domain:

Domain d = Domain.GetDomain(new

    DirectoryContext(DirectoryContextType.Domain, getDomainName()));

using (DirectoryEntry de = d.GetDirectoryEntry())

    byte[] domSid = (byte[])de.Properties["objectSid"].Value;

    string sdomainSid = sIDtoString(domSid);

    Console.WriteLine(sdomainSid);

Nota: Aquí necesitaremos dos funciones de apoyo, la primera nos devuelve el nombre del domino, y la segunda transforma el array de bits del SID en su representación textual:

public static string getDomainName()

    return IPGlobalProperties.GetIPGlobalProperties().DomainName;

public static string sIDtoString(byte[] sidBinary)

    SecurityIdentifier sid = new SecurityIdentifier(sidBinary, 0);

    return sid.ToString();

A todo esto el valor de la variable sdomainSid es el esperado!!! :-D

Poniéndolo todo junto

Al igual que el alegre bandolero, también soy un fanático de los métodos extensores, así que vamos a encapsular todo esto en un método que extienda la clase WindowsIdentity. Aquí va todo el código junto:

using System.DirectoryServices;

using System.DirectoryServices.ActiveDirectory;

using System.Net.NetworkInformation;

using System.Security.Principal;

namespace Alpha.Code

    public static class SecurityExtensions

        public static bool IsDomainAdmin (this WindowsIdentity identity)

            Domain d = Domain.GetDomain(new

                DirectoryContext(DirectoryContextType.Domain, getDomainName()));

            using (DirectoryEntry de = d.GetDirectoryEntry())

                byte[] bdomSid = (byte[])de.Properties["objectSid"].Value;

                string sdomainSid = sIDtoString(bdomSid);

                WindowsPrincipal wp = new WindowsPrincipal(identity);

                SecurityIdentifier dsid = new SecurityIdentifier(sdomainSid);

                SecurityIdentifier dasid = new SecurityIdentifier(

                    WellKnownSidType.AccountDomainAdminsSid, dsid);

                return wp.IsInRole(dasid);

        public static string getDomainName()

            return IPGlobalProperties.GetIPGlobalProperties().DomainName;

        public static string sIDtoString(byte[] sidBinary)

            SecurityIdentifier sid = new SecurityIdentifier(sidBinary, 0);

            return sid.ToString();

Y la forma de usarlo es tan sencilla como esto:

if (WindowsIdentity.GetCurrent().IsDomainAdmin())

    //Acciones a realizar si el usuario es administrador de dominio...

Un saludo desde las frías tierras de Andorra :-)

Noviembre 2009

** crossposting desde el blog de Lluís Franco en geeks.ms **

J*der que susto!

lfranco — Fri, 06 Feb 2009 19:57:00 GMT

Viernes por la tarde, toda la oficina para nosotros.

Hoy tenemos planificada la actualización del domino principal 2003 a 2003 R2, algo trivial y que en teoría no debe llevarnos demasiado tiempo. De hecho no sería necesario que nos quedásemos más de uno pero hemos pensado en acabar pronto con esto e ir todos a tomar una cerveza :-P

Vamos al lío.

Procedemos a actualizar el esquema con el conocido adprep /forestprep y a continuación vamos a lanzar el asistente de instalación de Windows Server 2003 R2, cuando de pronto aparece un mensaje de error que nos impide continuar:

Otra aplicacion requiere que este equipo se reinicie. Bla, bla, bla...

Uhm... vaya, esto no debería pasar pero bueno, por si acaso vamos a reiniciar y volvemos a probar. Reiniciamos el equipo (menos mal que a esta hora ya no hay nadie trabajando, probamos otra vez y... lo mismo. Ups! Volvemos a reiniciar otra vez mientras se forman las primeras gotas de sudor y nada. Otra vez lo mismo.

Uy, uy, uy...

...

Mierda.

El pánico empieza a apoderarse de nosotros mientras empiezo a pensar que este mensaje ya lo he visto con anterioridad, aunque sin embargo no apareció en las pruebas de pre-producción. Intento recordar cuándo vi este mensaje y cómo lo resolví, pero no me acuerdo :-S

De pronto tengo una inspiración divina: Creo que ya se que pasa, y busco en en la kb de http://support.microsoft.com/ por incidencias con Microsoft Windows Installer. Afortunadamente no pasan ni dos minutos y ya he encontrado una entrada que tiene muy buena pinta.

El problema es que Microsoft Windows Installer determina que la entrada de registro PendingFileRenameOperations no está vacía, con lo que antes de iniciar cualquier instalación hay que revisar y limpiar (o renombrar) esta clave de registro.

Abro el registro, busco la clave y “oh sorpresa! oh dolor! oh campos de soledad, mustios collados...”, un fichero de la instalación del anvitirus. Pues nada, a la hoguera con él :-)

La solución consiste en:

Cambiar manualmente el nombre de la entrada de registro PendingFileRenameOperations. Para ello, siga estos pasos:
1. Haga clic en inicio y, a continuación, haga clic en Ejecutar .
2. En el cuadro Abrir , escriba regedit y, a continuación, haga clic en ACEPTAR para iniciar el Editor del registro.
3. En el Editor de Registro, busque y haga clic en la siguiente subclave del registro:
  
  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager
4. En el nombre en el panel derecho del editor del registro, cambiar el nombre del PendingFileRenameOperations entrada del registro.
Compruebe que la siguiente subclave del registro está vacía:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
Compruebe que la siguiente subclave del registro está vacía:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx
Cierre el Editor del Registro y ejecutar de nuevo el programa de instalación (en nuestro caso Windows 2003 R2).

Diez minutos después ya hemos terminado y ahora escribo esta entrada por si a alguien le sucede lo mismo. Aunque el susto se lo llevará igual :-)

Saludos y buen fin de semana,

** crossposting desde el blog de Lluís Franco en geeks.ms **

HowTo: LDAP, obtener propiedades de la clase user

lfranco — Wed, 16 Jul 2008 16:23:42 GMT

Hace poco publicaba una actualización del método getUserLDAProperties de la clase LDAPservices. Esta función se encarga de recuperar todas las propiedades de la clase 'user' definidas en el esquema del AD de la organización.

La verdad es que dicha corrección no me terminaba de satisfacer. Así que después de bucear un poco por el modelo de objetos del namespace System.DirectoryServices.ActiveDirectory he encontrado un método más elegante, y que además permite acceder a más propiedades opcionales (algo que la anterior versión no permitía).

Os dejo aquí el código y en cuando tenga un minuto actualizo el código fuente de LDAPServices en skydrive.

public static List<string>

    getUserLDAPProperties(string LDAPURL)

    List<string> properties =new List<string>();

    ActiveDirectorySchema objADSchema = ActiveDirectorySchema.GetCurrentSchema();

    ActiveDirectorySchemaClass objADUserSchema;

    ActiveDirectorySchemaPropertyCollection objADPropertiesCollection;

    objADUserSchema = objADSchema.FindClass("user");

    objADPropertiesCollection = objADUserSchema.MandatoryProperties;

    foreach (ActiveDirectorySchemaProperty objADSchemaProperty in objADPropertiesCollection)

        properties.Add(objADSchemaProperty.Name);

    objADPropertiesCollection = objADUserSchema.OptionalProperties;

    foreach (ActiveDirectorySchemaProperty objADSchemaProperty in objADPropertiesCollection)

        properties.Add(objADSchemaProperty.Name);

    return (from p in properties orderby p select p).ToList();

Nos vemos!

** crossposting desde el blog de Lluís Franco en geeks.ms **

Corrección función getUserLDAPProperties

lfranco — Thu, 10 Jul 2008 09:01:18 GMT

Corrección aplicable al post:

http://geeks.ms/blogs/lfranco/archive/2008/07/08/accediendo-al-directorio-activo-de-la-organizaci-243-n-desde-net-iv.aspx

Ayer estuve revisando una de las funciones de la librería LDAPservices, que se encarga de devolver los nombres de las propiedades del objeto usuario dentro del AD. Hoy os publico una corrección, ya que observé que la función no devolvía correctamente todos los nombres de propiedades.

Este bug es producido porque en la función se utiliza un objeto DirectorySearcher para devolver todos los objetos de tipo usuario en el AD, a continuación lee los nombres de las propiedades del primer usuario encontrado y los inserta en una colección. A continuación la función no continúa procesando el resto de usuarios, ya que deberían tener las mismas propiedades, no? Pues no. Para mi sorpresa resulta que sólo se devuelven aquellas propiedades del usuario que han sido informadas:

public static List<string>

    getUserLDAPProperties(string LDAPURL)

    List<string> properties =new List<string>();

    DirectoryEntry entries = new DirectoryEntry(LDAPURL);

    DirectorySearcher searcher = new DirectorySearcher(

        entries, "(&(objectCategory=person)(objectClass=user))");

try

        foreach (SearchResult result in searcher.FindAll())

            foreach (string property in

                result.GetDirectoryEntry().Properties.PropertyNames)

                properties.Add(property);

            break;

    catch (Exception ex)

        throw ex;

    return properties;

Para solucionar este bug, hay que procesar las propiedades de todos los usuarios, quedando el código de la función así como sigue:

foreach (SearchResult result in searcher.FindAll())

    foreach (string property in

        result.GetDirectoryEntry().Properties.PropertyNames)

        if(!properties.Contains(property)) properties.Add(property);

Como veis, se suprime el break que terminaba el bucle y se añade una condición para que se agreguen a la colección sólo aquellos nombres de propiedad que no se han agregado previamente.

Saludos y happy coding!!!

** crossposting desde el blog de Lluís Franco en geeks.ms **

Accediendo al directorio activo de la organización desde .NET (IV)

lfranco — Tue, 08 Jul 2008 12:27:24 GMT

Buscar

Hoy vamos a buscar. Buscar elementos en el AD dentro de nuestra organización, y como lo más habitual es buscar usuarios o grupos he creado algunas funciones para facilitar esta tarea dentro de la clase LDAPServices (os dejo para vosotros ampliarlas para buscar equipos, por ejemplo).

También veremos cómo extraer los nombres de las propiedades de un objetos del AD, ya que en ocasiones queremos filtrar o devolver el valor de una propiedad de un objeto y no sabemos cómo se llama esta propiedad. Por ejemplo, para devolver el teléfono de un usuario en el AD hay que preguntar por el valor de la propiedad 'telephoneNumber'.

Tal vez más adelante (si tengo tiempo) lo ampliemos un poco. Me gustaría realizar un post acerca de cómo realizar un mapeador de propiedades para asignar los valores de las propiedades de objetos LDAP a objetos de nuestra aplicación. Esto podría ser muy útil por ejemplo, para importar los valores de nuestros usuarios de AD a una tabla de empleados.

Antes de empezar quiero comentaros que para poder realizar todo esto va a ser necesario agregar una referencia a System.DirectoryServices a nuestro proyecto. Pero vamos ya con estos nuevos métodos de LDAPServices:

getLDAPFilterString - Devuelve una cadena de consulta en formato LDAP query, que permite filtrar los objetos que deseamos devolver. Esta función filtra aquellos carácteres no deseados para evitar posible inyección de código LDAP por parte de un usuario (aunque es muy mejorable, estoy seguro que mi JoseMariCariño sería capaz de sacar información de aquí, casi me apuesto algo).

public enum LDAPFilterType

    UsersAndGroups,

    OnlyUsers,

    OnlyGroups

public static string

    getLDAPFilterString(LDAPFilterType Type, string Filter)

    Filter = Filter.Replace("&","");

    Filter = Filter.Replace("|","");

    Filter = Filter.Replace("*", "");

    string FilterByName = "(samAccountName=*{0}*)";

    string f = string.Empty;

    switch (Type)

        case LDAPFilterType.OnlyUsers:

            f = "(&(objectCategory=person)(objectClass=user){0})";

            break;

        case LDAPFilterType.OnlyGroups:

            f = "(&(objectCategory=Group){0})";

            break;

        case LDAPFilterType.UsersAndGroups:

            f = "(|(&(objectCategory=person)(objectClass=user){0})(&(objectCategory=Group){0}))";

            break;

    if (Filter == string.Empty)

        return string.Format(f, string.Empty);

    else

        return string.Format(f, string.Format(FilterByName, Filter));

getItemsInLDAP - Basándose en el método anterior, realiza la consulta al AD y devuelve una lista con los objetos coincidentes. Su funcionamiento se basa en un objeto DirectoryEntry, que apunta al AD que se le ha pasado como aergumento. Y en un objeto DirectorySearcher, que es el que realmente se encarga de buscar las entradas coincidentes con el filtro en el DirectoryEntry.

public static List<string>

    getItemsInLDAP(string LDAPURL, LDAPFilterType type, string criteria)

    List<string> items = new List<string>();

    DirectoryEntry entries = new DirectoryEntry(LDAPURL);

    string filter = getLDAPFilterString(type, criteria);

    DirectorySearcher searcher = new DirectorySearcher(

        entries, filter);

try

        foreach (SearchResult result in searcher.FindAll())

            items.Add((string)result.Properties["samAccountName"][0]);

    catch (Exception ex)

        throw ex;

    return items;

Para probar esta funcionalidad basta con tener un TextBox en el que introducir el criterio de búsqueda y un ComboBox en el que especificar que objetos deseamos buscar. Así cómo un CommandButon para lanzar la consulta y un ListBox en el que mostrar los resultados:

El código es muy sencillo. Basta con asignar el valor devuelto por la función getItemsInLDAP al DataSource de la lista.

private void cmbSearch_Click(object sender, EventArgs e)

try

        string dcName = LDAPServices.getLDAPDomainName(txtDomain.Text);

        List<string> items = LDAPServices.getItemsInLDAP(dcName,

            (LDAPServices.LDAPFilterType) cmbType.SelectedIndex, txtCriteria.Text);

        lstItems.DataSource = items;

    catch (Exception ex)

        MessageBox.Show(ex.Message,

             Application.ProductName,

             MessageBoxButtons.OK,

             MessageBoxIcon.Exclamation);

getUserLDAPProperties - Devuelve una lista de cadenas con los nombres de las propiedades de un objeto User dentro del AD. Cabe observar que el esquema del AD es variable, con lo que las propiedades devueltas pueden cambiar. Por ejemplo, productos que se integran fuertemente con AD como Exchange agregan propiedades a los objetos usuario y grupo.

public static List<string>

    getUserLDAPProperties(string LDAPURL)

    List<string> properties =new List<string>();

    DirectoryEntry entries = new DirectoryEntry(LDAPURL);

    DirectorySearcher searcher = new DirectorySearcher(

        entries, "(&(objectCategory=person)(objectClass=user))");

try

        foreach (SearchResult result in searcher.FindAll())

            foreach (string property in

                result.GetDirectoryEntry().Properties.PropertyNames)

                properties.Add(property);

            break;

    catch (Exception ex)

        throw ex;

    return properties;

De este modo podemos saber las propiedades de un objeto dentro de nuestro AD. Esto es más importante de lo que parece, ya que cuando buscamos elementos dentro del AD, no se devuelven todas las propiedades de forma predeterminada. Para agregar el valor de una propiedad a los resultados de la búsqueda ésta debe añadirse explícitamente mediante la colección PropertiesToLoad:

searcher.PropertiesToLoad.Add("telephoneNumber");

Y luego comprobar si existe valor devuelto, ya que es posible que no exista o no devuelva valor:

if (r.Properties("telephoneNumber").Count > 0)

//

Y hasta aquí el cuarto capítulo de esta serie. Espero que os sea útil, recordar que en esta ocasión el código completo lo publiqué en el post anterior.

Nos vemos pronto!
Un saludo desde Andorra,

** crossposting desde el blog de Lluís Franco en geeks.ms **

Accediendo al directorio activo de la organización desde .NET (III)

lfranco — Fri, 04 Jul 2008 15:45:18 GMT

En vista a que bastante gente me ha pedido si puedo publicar ya el código del proyecto de ejemplo, he decidido publicarlo ahora en lugar de esperar al último post de la serie. En caso que se realicen variaciones en el código, las publicaré posteriormente.

Aquí lo teneis, publicado en skydrive (*):

(*) En ocasiones, al realizar cross-posting a otros blogs desde el original de geeks.ms, tal vez no aparezca correctamente el enlace a skydrive. Si es así, os recomiendo que visitéis el post original en geeks.ms y realicéis la descarga desde éste.

En el post anterior, os dije que en el siguiente (este post) mostraríamos cómo realizar la suplantación (Impersonate) de usuario de Windows para ejecutar nuestra aplicación con otras credenciales. Sin embargo, como ésto ya lo mostré en otro post de una serie anterior, lo doy por explicado y así avanzamos un poco más.

System.Net.NetworkInformation

Antes de entrar al trapo, un pequeño apunte. Apuntaros este espacio de nombres, que hemos utilizado para obtener algunos datos básicos para el proyecto, y que contiene un montón de métodos que devuelven información muy interesante sobre el tráfico y estadísticas de red.

LDAPServices

Vamos a ir comentando algunas de los métodos que proporciona esta clase. Como os comenté son todos estáticos, por lo que no es necesario instanciar un objeto para invocarlos. Empecemos:

sIDtoString - Trabajando con el AD constantemente vamos a encontrarnos con los llamados SID (identificadores de seguridad). Este método se encarga de transformar un SID (array de bytes) en una cadena de texto que pueda ser mostrada al usuario.

public static string

    sIDtoString(byte[] sidBinary)

    SecurityIdentifier sid = new SecurityIdentifier(sidBinary, 0);

    return sid.ToString();

getNTAccountName - Devuelve el nombre del objeto dentro del AD a partir de su SID. Por ejemplo, a partir de un identificador de seguridad como {S-1-5-12-7623811015-3361044348-030300820-1013} retorna un string con formato: 'DOMINIO\NombreObjeto'.

public static string

    getNTAccountName(string wksid)

    SecurityIdentifier sid = new SecurityIdentifier(wksid);

    NTAccount account = (NTAccount)sid.Translate(typeof(NTAccount));

    return account.Value;

getADUserMemberOf - Devuelve un diccionario con los grupos a los que pertenece un usuario. Espera un argumento de tipo token de seguridad (habitualmente utilizaremos el WindowsIdentity.GetCurrent().Token) y el diccionario genérico devuelto es de tipo <string, IdentityReference>.

public static Dictionary<string, IdentityReference>

    getADUserMemberOf(IntPtr logonToken)

    Dictionary<string, IdentityReference> groups =

        new Dictionary<string, IdentityReference>();

    WindowsIdentity user = new WindowsIdentity(logonToken);

    IdentityReferenceCollection irc = user.Groups;

    foreach (IdentityReference ir in irc)

        groups.Add(getNTAccountName(ir.Value), ir);

    return groups;

(*) Al ir escribiendo el artículo me he dado cuenta de que esta función podría ser optimizada, aprovechando algunas de las nuevas características de C# 3.0, incorporadas en Visual Studio 2008. De modo que podría ser re-escrita del siguiente modo ¡en tan sólo 3 líneas!

public static Dictionary<string, IdentityReference>

    getADUserMemberOf2(IntPtr logonToken)

    WindowsIdentity user = new WindowsIdentity(logonToken);

    var groups = from g in user.Groups select g;

    return groups.ToDictionary(p => getNTAccountName(p.Value));

¿Menudo cambio, verdad? Observar el uso de:

Inferencia de tipos (var)
Palabras clave de consulta (from, in, select)
Expresiones lambda en la llamada al método extensor ToDictionary (p => getNTAccountName(p.Value))

La verdad es que en cuanto empiezas a usar estas mejoras te 'enganchan'. No sabeis la cara de bobo que se me queda cuando a veces abro el editor de VB6.0 (si, habéis oído bien) para realizar alguna modificación en aplicaciones que todavía no se han migrado a .NET (y lo que les queda... :-P).

Hasta aquí algunos de los métodos que contiene la clase LDAPServices. En el próximo post veremos cómo obtener la lista de propiedades de un objeto user dentro del directorio activo, así cómo realizar búsquedas de objetos dentro del directorio.

No vemos pronto,

** crossposting desde el blog de Lluís Franco en geeks.ms **

Accediendo al directorio activo de la organización desde .NET (II)

lfranco — Mon, 30 Jun 2008 13:53:07 GMT

En el post anterior vimos que en ocasiones nuestra aplicación deberá acceder a los datos que contiene el directorio activo de nuestra organización, ya sea para buscar elementos, validar credenciales, etc.

Hoy nos centraremos en los objetos del framework que nos permiten realizar esto, empezando por el objeto WindowsIdentity, que nos acompaña desde la versión 1.0 del framework, y que representa un usuario de Windows.

WindowsIdentity

Representa un usuario de Windows. Dispone de un método GetCurrent() que devuelve una referencia al usuario de Windows que está ejecutando la aplicación y que por defecto será el usuario actual de Windows.

En nuestro ejercicio vamos a utilizar este objeto para mostrar en la barra de estado algo de información sobre el usuario actual. El nombre y token, así como el contexto de suplantación y diversa información cómo si está autenticado, es de sistema, etc.

El código es muy sencillo y para usarlo sólo debemos tener en cuenta haber importado el espacio de nombres System.Security.Principal:

private void RefreshUserInformation()

    WindowsIdentity user = WindowsIdentity.GetCurrent();

    lblUser.Text = string.Format("User: {0}", user.Name);

    lblToken.Text = string.Format("Token: {0}", user.Token.ToString());

    lblImpersonating.Text = string.Format("Impersonating: {0}", user.ImpersonationLevel.ToString());

    lblIsAnonymous.Text = string.Format("Is Anonymous: {0}", user.IsAnonymous.ToString());

    lblIsAuthenticated.Text = string.Format("Is Authenticated: {0}", user.IsAuthenticated.ToString());

    lblIsGuest.Text = string.Format("Is Guest: {0}", user.IsGuest.ToString());

    lblIsSystem.Text = string.Format("Is System: {0}", user.IsSystem.ToString());

    if (sec.ImpersonationContext == null)

        cmdImpersonateApplicationAsUser.Enabled = true;

        lblUser.ForeColor = Color.Black;

        lblImpersonating.ForeColor = Color.Black;

    else

        cmdImpersonateApplicationAsUser.Enabled = false;

        lblUser.ForeColor = Color.Red;

        lblImpersonating.ForeColor = Color.Red;

    cmdUndoImpersonation.Enabled = !cmdImpersonateApplicationAsUser.Enabled;

Lo único a destacar es que en caso de que exista suplantación (ImpersonationContext distinto de nulo), mostraremos algunos campos en color rojo, para destacar que este usuario es distinto del que inició sesión en Windows.

LDAPServices

En este proyecto he creado una clase que proporciona una serie de funcionalidades comunes, su nombre es LDAPServices y encapsula una serie de métodos estáticos, para facilitar el trabajo con LDAP. En los próximos posts detallaremos el uso de estos métodos:

SecurityContext

También aparece la clase llamada SecurityContext que ya hemos visto en la serie de posts sobre acceder a la caché de IE, que encapsula toda la lógica necesaria para impersonar nuestra aplicación y que se ejecute con otras credenciales de usuario de Windows.

Esta clase expone una propiedad de tipo WindowsImpersonationContext que devuelve información sobre si está realizando suplantación, y que en caso afirmativo permite terminarla mediante el método Undo(). También expone dos métodos LogonUser y ImpersonateUser, que permiten respectivamente validar unas credenciales de usuario contra un dominio y empezar un contexto de suplantación.

En el próximo post veremos cómo realizar esta suplantación y cómo recabar más información del usuario actual (por ejemplo a que grupos de Windows pertenece el usuario actual).

Hasta entonces!

** crossposting desde el blog de Lluís Franco en geeks.ms **

Accediendo al directorio activo de la organización desde .NET (I)

lfranco — Wed, 11 Jun 2008 18:16:35 GMT

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!

** crossposting desde el blog de Lluís Franco en geeks.ms **