Services Active Directory: PrincipalContext - Quel est le nom distinctif d'un objet "conteneur"?

Question

J'essaie actuellement de m'authentifier via les services Active Directory en utilisant la classe PrincipalContext. Je voudrais que mon application s'authentifie auprès du domaine en utilisant des contextes Sealed et SSL. Pour ce faire, je dois utiliser the following constructor of PrincipalContext (link to MSDN page):

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

Plus précisément, j'utilise le constructeur comme si:

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

MSDN dit à propos de "conteneur":

Le conteneur sur le magasin à utiliser comme la racine du contexte. Toutes les requêtes sont exécutées sous cette racine et toutes les insertions sont effectuées dans ce conteneur . Pour Domain et les types de contexte ApplicationDirectory, ce paramètre est le (DN) distingué d'un objet conteneur.

Quel est le DN d'un objet conteneur? Comment puis-je savoir quel est mon objet conteneur? Puis-je interroger le serveur Active Directory (ou LDAP) pour cela?

Answer 1

Eh bien, je suis parvenu à comprendre la question:

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

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

En spécifiant les ContextOptions dans la méthode ValidateCredentials (au lieu de dans le constructeur), cela m'a permis d'éviter d'avoir à spécifier un DN pour un conteneur objet.

MISE À JOUR:

Bien que je dois préciser que, après l'expérimentation plus loin, je trouve que toutes les requêtes provenant de cet objet PrincipalContext a lieu l'ONU crypté.

Apparemment, lorsque ContextOptions est défini dans ValidateCredentials, ces options sont uniquement utilisées pour cet appel spécifique de ValidateCredentials. Mais voici où cela devient étrange ...

Donc, je voulais que mes requêtes sur le serveur AD soient cryptées. Exemple requête:

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

Le code ci-dessus obtient une liste de tous les groupes que l'utilisateur appartient, mais il arrive en clair (non chiffré). Donc, après beaucoup de tripoter, j'ai découvert que le DN n'a jamais besoin d'être réglé. J'ai trouvé que je pouvais définir l'objet conteneur (DN) à null. Et cela fonctionne bien. Le définir sur une chaîne vide ("") entraîne une exception de type inconnu, donc ne pensez pas que vous pouvez lui donner une chaîne vide.

Et voici la partie étrange. Vous pensez que la définition de l'option SecureSocketLayer dans PrincipalContext signifierait que vous n'avez pas à le définir explicitement lorsque vous utilisez VerifyCredentials. Mais j'ai trouvé que si je ne l'avais pas défini dans la partie VerifyCredentials, l'authentification échouerait, mais les requêtes (comme dans l'exemple pour les groupes) sont toujours cryptées.Peut-être que je ne comprends pas encore complètement l'authentification et les requêtes AD, mais cela me semble un comportement étrange.