Servicios de Active Directory: PrincipalContext - ¿Cuál es el DN de un objeto "contenedor"?

Question

Actualmente estoy intentando autenticarme a través de los Servicios de Active Directory utilizando la clase PrincipalContext. Me gustaría que mi aplicación se autenticara en el Dominio usando contextos Sellados y SSL. Con el fin de hacer esto, tengo que usar the following constructor of PrincipalContext (link to MSDN page):

public PrincipalContext(
    ContextType contextType, 
    string name, 
    string container, 
    ContextOptions options 
) 

Específicamente, estoy usando el constructor como tan:

PrincipalContext domainContext = new PrincipalContext(
    ContextType.Domain, 
    domain, 
    container, 
    ContextOptions.Sealing | ContextOptions.SecureSocketLayer); 

MSDN dice acerca de "contenedor":

El contenedor en la tienda para usar como la raíz del contexto. Todas las consultas se realizan bajo esta raíz y todas las inserciones se realizan en este contenedor . Para Domain y ApplicationDirectory tipos de contexto, este parámetro es el nombre distinguido (DN) de un objeto contenedor.

¿Cuál es el DN de un objeto contenedor? ¿Cómo averiguo cuál es mi objeto contenedor? ¿Puedo consultar el servidor de Active Directory (o LDAP) para esto?

Answer 1

Bueno, me las arreglé para averiguar el tema:

PrincipalContext domainContext = new PrincipalContext(ContextType.Domain,domain); 

domainContext.ValidateCredentials(userName, password, 
    ContextOptions.Negotiate | ContextOptions.SecureSocketLayer); 

Al especificar los ContextOptions en el método ValidateCredentials (en lugar de en el constructor), esto me permitió evitar tener que especificar un DN para un contenedor objeto.

UPDATE:

Aunque hay que aclarar que después de la experimentación adicional, he encontrado que cualquier consulta derivados de este objeto PrincipalContext tiene lugar cifrada por la ONU.

Aparentemente, cuando ContextOptions se establece en ValidateCredentials, esas opciones solo se usan para esa llamada específica de ValidateCredentials. Pero aquí es donde se vuelve extraño ...

Por lo tanto, quería que mis consultas al servidor de AD tuvieran lugar cifradas también. Ejemplo de consulta:

UserPrincipal p = UserPrincipal.FindByIdentity(
    domainContext, IdentityType.SamAccountName, userName); 
var groups = p.GetGroups(); 
foreach (GroupPrincipal g in groups) { /* do something */ } 

El código anterior obtiene una lista de todos los grupos que pertenece el usuario, pero sucede en el claro (sin cifrar). Así que después de mucho toquetear, descubrí que el DN nunca necesita ser configurado.

PrincipalContext domainContext = new PrincipalContext(ContextType.Domain,domain, 
    null,ContextOptions.Negotiate | ContextOptions.SecureSocketLayer); 

Encontré que podía establecer el objeto contenedor (DN) como nulo. Y esto funciona bien Establecerlo en una cadena vacía ("") da como resultado una excepción de algún tipo desconocido, así que no piense que puede darle una cadena vacía.

Y esta es la parte rara. Pensarías que establecer la opción SecureSocketLayer en PrincipalContext significaría que no tienes que establecerlo explícitamente cuando usas VerifyCredentials. Pero descubrí que si no lo configuraba en la parte VerifyCredentials, la autenticación fallaría, pero las consultas (como en el ejemplo de los Grupos) aún se realizan encriptadas.

Quizás aún no entiendo por completo la autenticación de AD y las consultas, pero eso me parece un comportamiento extraño.