Je vois un comportement étrange ici à l'aide de Lorsque je validai les informations d'identification par rapport au domaine principal, Toutefois, si je valide un utilisateur dans le sous-domaine, Je travaille maintenant autour de cela en ce moment en faisant Un autre contournement que j'ai regardé est en passant le nom d'utilisateur à travers comme Dans chaque version de cette fonction, la chaîne de nom d'utilisateur peut être dans l'une des
une variété de formats différents. Pour une liste complète de l'acceptable
Types de formats, voir la documentation ADS_NAME_TYPE_ENUMUM. P>
BlockQuote> ... dont cette forme de nom d'utilisateur est répertoriée. Mais cela cause Le code pertinent est: p> PrincipalContext.validateCredentials code>. La configuration est deux domaines Active Directory dans la configuration parent / enfant (donc nous avons le domaine principal
company.com code> et sous-domaine
développement.company.com code>).
ValidateCredentials Code> se comporte comme prévu, retournant VRAI pour de bonnes paires d'utilisateurs / passes et de faux pour autre chose. p>
validateCredentials code> renvoie true pour un bon nom d'utilisateur / mot de passe et des utilisateurs invalides. Si je fournis un utilisateur valide avec un mot de passe invalide, il renvoie correctement false. P>
userprincipal.findbycid () code> L'utilisateur existe, puis appelant
validateCredentials code> - mais j'aimerais comprendre ce qui se passe. P>
Domaine \ Nom d'utilisateur Code> comme Entrée MSDN pour
ValidateCréentielles code> états
: p>
validateCréentials code> pour toujours retourner vrai, quelle que soit la combinaison de nom d'utilisateur et de mot de passe je passe. P>
bool authenticated = false;
// Various options tried for ContextOptions, [etc] inc. explicit username/password to bind to AD with -- no luck.
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, domain, null, ContextOptions.Negotiate, null, null))
{
log(pc.ConnectedServer + " => " + pc.UserName + " => " + pc.Name + " => " + pc.Container);
using (var user = UserPrincipal.FindByIdentity(pc, IdentityType.SamAccountName, username))
{
if (user != null)
{
log(user.DistinguishedName + "; " + user.DisplayName);
authenticated = pc.ValidateCredentials(username, password);
} else {
log("User not found");
// Debug only -- is FindByIdentity() needed. This should always return
// false, but doesn't.
authenticated = pc.ValidateCredentials(username, password);
}
}
}
return authenticated;
3 Réponses :
pourrait-il être lié à Ceci : P>
La méthode validateCredentials se lie au serveur spécifié dans le constructeur. Si les paramètres du nom d'utilisateur et du mot de passe sont NULL, le Les informations d'identification spécifiées dans le constructeur sont validées.
si non les informations d'identification ont été spécifiées dans le constructeur et le nom d'utilisateur et Les paramètres de mot de passe sont NULL, cette méthode valide la valeur par défaut. Critiques pour le principal actuel Strong>. P> blockQuote>
Non ... comme il s'est avéré, le compte invité de niveau de domaine a été activé; Si je le désactive, les validateCendentials font la bonne chose. (Et comme c'est typique, après la majeure partie de la journée, essayant de trouver la réponse, 20 minutes après avoir posté cela, je trouve la réponse).
Une certaine quantité de googling plus tard (pas que j'ai été dans Google toute la journée en essayant de le trouver quand même), j'ai Mettre simplement, si le compte invité est activé dans le domaine, ValidateCredentials retournera true pour un utilisateur inconnu. Je viens de vérifier l'état de l'utilisateur invité dans le développement.comPany.com, et assurez-vous que le compte est activé. Si j'ai le compte invité désactivé, ValidateCredentials renvoie correctement False. P>
Ceci est un gotcha assez fondamental, je ne suis pas sûr que je tiens à ce comportement ... la pitié n'est pas explicitement mentionnée sur MSDN. P>
Wow ... c'est une manquue facile qui aurait pu être un gros trou de sécurité. Merci d'avoir répondu!
5 ans et le cas est toujours le même. A été surpris de voir PrincipalContext.validateCréentials ("bla", "bla", contextoption.negotiate) code> pour retourner
vrai code>.
J'ai utilisé échantillon code: strong> p> < Pré> xxx pré> p> contextoption.simplebind code> drapeau avec
validateCredentials code> il a résolu mon problème ..
J'ai deux domaines. Je peux utiliser l'adresse IP pour mon domaine pour appeler Valider les informations d'identification, et elle réussit si je viens de transmettre le nom d'utilisateur ou le mot de passe des utilisateurs de l'un ou l'autre domaine. Je suis un peu surpris que je n'ai pas à fournir cette information supplémentaire, et un peu confus, alors comment je vérifie que je valide le bon utilisateur du bon domaine. (Ne serait-il pas possible que chacun ait dit un jsmith?)