c# - existe - system.directoryservices nuget

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 usando la clase PrincipalContext. Me gustaría que mi aplicación se autenticara en el Dominio usando contextos Sellados y SSL. Para hacer esto, tengo que usar el siguiente constructor de PrincipalContext (enlace a la página de MSDN) :

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

Específicamente, estoy usando el constructor así:

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

MSDN dice sobre "contenedor":

El contenedor en la tienda para usar como la raíz del contexto. Todas las consultas se realizan en esta raíz y todas las inserciones se realizan en este contenedor. Para los tipos de contexto Domain and ApplicationDirectory, este parámetro es el nombre completo (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, logré descubrir el problema:

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

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

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

ACTUALIZAR:

Aunque debo aclarar que después de más experimentos, encontré que cualquier consulta derivada de este objeto PrincipalContext tiene lugar encriptado 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 pone extraño ...

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

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 a los que pertenece el usuario, pero sucede en forma clara (no encriptada). 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);

Descubrí 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 aquí está la parte extraña. 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.

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