La réponse courte: Lorsque le paramètre path du constructeur DirectoryEntry contient un nom de domaine non valide l'objet DirectoryEntry sera (après une recherche infructueuse pour le domaine non valide dans le forrest) tenter une chute en arrière en laissant tomber la partie de domaine le paramètre username et tentez la connexion en utilisant le nom d'utilisateur ordinaire (sAMAccountName).
La longue réponse: Si le nom de domaine spécifié dans le paramètre username est invalide, mais l'utilisateur existe dans le domaine spécifié dans le paramètre path l'utilisateur sera authentifié (par l'utilisation de la fallback). Toutefois, si l'utilisateur existe dans un autre domaine de la forêt que celui spécifié dans le paramètre path, l'authentification ne réussira que si la partie domaine du paramètre username est incluse et correcte.
Il existe quatre façons de spécifier le paramètre nom d'utilisateur lorsqu'ils traitent avec des objets DirectoryEntry-:
- nom distinctif (CN = Nom d'utilisateur, CN = Users, DC = domain, DC = local)
- NT Nom du compte (DOMAIN \ Nom d'utilisateur)
- claire et simple Nom/samAccountName (nom d'utilisateur)
- Nom d'utilisateur principal (généralement [email protected])
Permettez-moi d'illustrer par un exemple:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.DirectoryServices;
namespace DirectoryTest
{
class Program
{
private static Int32 counter = 1;
static void Main(string[] args)
{
TestConnection();
}
private static void TestConnection()
{
String domainOne = "LDAP://DC=domain,DC=one";
String domainOneName = "DOMAINONE";
String domainOneUser = "onetest";
String domainOnePass = "testingONE!";
String domainTwo = "LDAP://DC=domain,DC=two";
String domainTwoName = "DOMAINTWO";
String domainTwoUser = "twotest";
String domainTwoPass = "testingTWO!";
String invalidDomain = "INVALIDDOMAIN";
// 1) This works because it's the correct NT Account Name in the same domain:
Connect(domainOne, domainOneName + "\\" + domainOneUser, domainOnePass);
// 2) This works because username can be supplied without the domain part
// (plain username = sAMAccountName):
Connect(domainOne, domainOneUser, domainOnePass);
// 3) This works because there's a fall back in DirectoryEntry to drop the domain part
// and attempt connection using the plain username (sAMAccountName) in (in this case)
// the forrest root domain:
Connect(domainOne, invalidDomain + "\\" + domainOneUser, domainOnePass);
// 4) This works because the forrest is searched for a domain matching domainTwoName:
Connect(domainOne, domainTwoName + "\\" + domainTwoUser, domainTwoPass);
// 5) This fails because domainTwoUser is not in the forrest root (domainOne)
// and because no domain was specified other domains are not searched:
Connect(domainOne, domainTwoUser, domainTwoPass);
// 6) This fails as well because the fallback of dropping the domain name and using
// the plain username fails (there's no domainTwoUser in domainOne):
Connect(domainOne, invalidDomain + "\\" + domainTwoUser, domainTwoPass);
// 7) This fails because there's no domainTwoUser in domainOneName:
Connect(domainOne, domainOneName + "\\" + domainTwoUser, domainTwoPass);
// 8) This works because there's a domainTwoUser in domainTwoName:
Connect(domainTwo, domainTwoName + "\\" + domainTwoUser, domainTwoPass);
// 9) This works because of the fallback to using plain username when connecting
// to domainTwo with an invalid domain name but using domainTwoUser/Pass:
Connect(domainTwo, invalidDomain + "\\" + domainTwoUser, domainTwoPass);
}
private static void Connect(String path, String username, String password)
{
Console.WriteLine(
"{0}) Path: {1} User: {2} Pass: {3}",
counter, path, username, password);
DirectoryEntry de = new DirectoryEntry(path, username, password);
try
{
de.RefreshCache();
Console.WriteLine("{0} = {1}", username, "Autenticated");
}
catch (Exception ex)
{
Console.WriteLine("{0} ({1})", ex.Message, username);
}
Console.WriteLine();
counter++;
}
}
}
Dans l'exemple ci-dessus domain.one est le domaine racine de forêt et domain.two est la même que forrest domain.one (mais un autre arbre naturellement).
Pour répondre à votre question: l'authentification toujours échouera si l'utilisateur pas dans le domaine que nous vous connectez et non ou un nom de domaine non valide est spécifié dans le paramètre username.
Merci l'homme, c'est une réponse étonnamment détaillée et j'apprécie la clarté –
vous avez mentionné le cas "User Principal Name" (pré[email protected] comme format), mais il n'y a pas de test pour cela. se comporterait-il de la même manière, donc le "@ domain.local", s'il n'est pas valide, provoquerait un repli dans les cas 3) et 9)? – dlatikay