DirectoryServices.AccountManagement mot de passe « vieux » valide encore après le mot de passe changement

Question

Après la réinitialisation d'un mot de passe utilisateurs dans Active Directory, si l'utilisateur tente de se connecter en utilisant leur ancien mot de passe, le code suivant valide comme vrai:

Dim up As UserPrincipal = GetAdUser(objContext, arg_strBA, arg_strUsername) 

If up IsNot Nothing Then 

    Dim valid As Boolean = up.Context.ValidateCredentials(
    up.UserPrincipalName, arg_strPassword, ContextOptions.Negotiate) 


    If (valid) Then strReturn = up.SamAccountName 

End If 

nous remettre à zéro le mot de passe en utilisant le code suivant:

Dim objUser As New DirectoryEntry(arg_strLDAPPath) 

If Not objUser Is Nothing Then 
    objUser.AuthenticationType = AuthenticationTypes.Secure 


    objUser.Invoke("SetPassword", arg_strNewPW) 
    objUser.CommitChanges() 
end if 

la remise à zéro le mot de passe fonctionne très bien et l'utilisateur peut se connecter avec leur nouveau mot de passe, mais leur ancien mot de passe ne doit pas valider encore. Lorsque le ValidateCredentials ci-dessus fonctionne pour l'ancien mot de passe, nous attribuons les informations d'identification à un appel de service Web, qui échoue ensuite avec une erreur «401: non autorisé».

Quelqu'un at-il vu quelque chose comme ça?

Merci Dirk

Answer 1

Je Fount la réponse Here

À partir du lien ...

« Cependant, ce qui compte est que ContextOption ne pas assurer l'utilisation de Kerberos. Il se trouve que dans certaines situations (comme si vous spécifiez AD plutôt que local, et que vous avez un serveur suffisamment à jour), le code choisit de faire Négocier quoi qu'il arrive.En ce sens, spécifier Sealing signifie probablement qu'il utilisera Kerberos, mais pas nécessairement exclusivement. Le drapeau qui compte vraiment est enterré sous plusieurs couches, sous cette couverture, cette méthode finit par établir un LdapCo. nnection, en définissant les informations d'identification réseau pour la connexion, en définissant AuthType (l'indicateur réel qui compte!) et enfin en appelant la méthode Bind(). La méthode LdapConnection.Bind() établit une connexion authentifiée à l'un des serveurs AD à l'aide des informations d'identification spécifiées. Le problème est que lorsque PrincipalContext.ValidateCredentials configure cet appel (dans votre scénario), définit toujours le AuthType = Négocier. Dans ce cas, Kerberos s'utilise et échoue, mais le système revient à NTLM. "

Answer 2

Avez-vous pris le jusqu'à 15 minutes de temps en compte que AD afin de propager les modifications de ce genre à travers le réseau ??

Marc

Answer 3

Je suppose que vous êtes ValidateCredentials sur une machine exécute client. Si tel est le cas, l'ancien mot de passe (réussi) est mis en cache. Ceci est fait pour permettre aux utilisateurs de se connecter si Active Directory est hors ligne ou inaccessible. La propagation des changements prend du temps. Si vous voulez contourner ce problème, vous devez vous authentifier auprès du serveur desservant Webservice au moment de l'authentification au lieu de l'ordinateur client local.

Answer 4

Cela fonctionne - Voir SOLUTION ci-dessous - S'il vous plaît laissez-moi savoir si vous trouvez cela utile que notre magasin est divisé Voici une solution à Active Directory permettant à l'ancien mot de passe de fonctionner après avoir été modifié J'aimerais beaucoup avoir des commentaires sur l'acceptation de cette solution car elle utilise ChangePassword lors de l'authentification de connexion C'est une chose étrange à faire, mais cela fonctionne. Actuellement, notre boutique n'utilise pas cette solution, donc si quelqu'un peut me dire si elles l'utilisent ou non, ce serait apprécié.

Merci Ch

Active Directory et anciens mots de passe valides retour (15 minutes + - heure). Cela se produit lorsque SetPassword ou ChangePassword sont invoqués.

Histoire:

Je trouve que ce qu'on appelle une « fonction » de la MA et par la conception intégrée dans AD de sorte que lorsqu'un utilisateur modifie les mots de passe il y a une sorte de période de grâce qui permet à toutes les ressources en utilisant les mots de passe transférer sur le nouveau. Un exemple d'AD qui supporte le concept qu'AD connaît le dernier mot de passe est celui de changer un mot de passe de connexion sur un PC - dans ce cas, l'ordinateur ne permettra pas à l'ancien mot de passe de se connecter. Bien que je n'ai pas la réponse à cette question (autre que Microsoft a dû faire fonctionner cela), je suis d'avis que ce n'est pas aussi simple que cela puisse paraître car le PC est impliqué et il a aussi des mots de passe.

Un exemple montrant comment les changements de mot de passe dans AD ne durent pendant une période de temps peut être:

Utilisation de Bureau à distance à partir d'un PC Windows 7 à une boîte Windows Server 2008 R2. Connectez-vous à partir de Windows Security Box, puis cliquez sur OK, cliquez sur OK et vous êtes connecté. Maintenant Modifier votre mot de passe pour l'utilisateur que vous avez utilisé à distance dans la boîte avec (différent de votre utilisateur Kirkman ??), déconnexion et connexion encore avec ancien mot de passe (dans un délai de 15 minutes à une heure + -). L'ancien mot de passe vous passera la boîte de sécurité Windows et à la boîte OK. Lorsque vous cliquez sur OK, il échouera. Si vous démarrez à partir de Remote Desktop et essayez un mot de passe incorrect, vous serez arrêté dans la boîte de sécurité Windows avec le message "La tentative d'ouverture de session a échoué". Une fois la limite de temps expirée, vous ne dépasserez pas la boîte de sécurité Windows avec l'ancien mot de passe. (Assurez-vous de démarrer à partir du Bureau à distance à chaque fois de ne PAS changer d'utilisateur qui agira comme prévu ce qui montre également que le PC est impliqué d'une manière ou d'une autre). Au moins, il ne se connecte pas à l'utilisateur - mais cela montre que (ce qui semble être AD) à un certain niveau permet aux anciens mots de passe de s'authentifier à un certain niveau. J'ai trouvé de nombreuses références à ce problème et seulement une solution potentielle que jusqu'à présent je n'ai pas pu déterminer si nous pouvons l'implémenter (c'est la référence à l'appel strictement via Kerberos et non NTLM qui n'est pas aussi simple que cela puisse paraître selon la documentation et mes recherches). J'ai trouvé beaucoup de liens sur la façon d'interagir avec AD dans .NET mais pas de manuel AD réel.

SOLUTION SOLUTION SOLUTION - Lisez cette partie si vous voulez la solution SOlution !!! Présente: J'ai trouvé (par hasard lors d'un test) que l'appel ChangePassword à AD ne permettra pas à l'ancien mot de passe qui lui est passé de changer le mot de passe pour le nouveau mot de passe. Je suis d'avis que ce test qui fonctionne n'est pas connu car je n'ai trouvé aucune référence à son utilisation. En fait, je n'ai trouvé aucune solution à ce problème. Un matin à 3h00 du matin, j'ai réalisé que je pourrais exploiter cette utilisation de ChangePassword pour fournir une solution à ce problème - au moins une solution de contournement que nous pouvons utiliser immédiatement jusqu'à ce que nous puissions déterminer une meilleure approche.

Je vérifie d'abord que tout est valide et que AD renvoie que le mot de passe est valide. Ensuite, un appel à ChangePassword (nom d'utilisateur, ancien mot de passe, nouveau mot de passe) avec l'ancien mot de passe et le nouveau mot de passe comme mot de passe fourni par l'utilisateur (les deux identiques) est fait. Je sais que l'un des deux (peut-être trois, mais la violation de la politique de mot de passe l'empêche de réussir) les résultats se produiront. L'ancien mot de passe est bon et nous échouons parce que la politique de mot de passe n'est pas remplie (historique, nouveau mot de passe ne peut pas être l'un des N derniers mots de passe) ou nous échouons parce que l'ancien mot de passe est incorrect.Nous vérifions cette dernière condition et si l'ancien mot de passe n'est pas valide, nous ne laissons pas l'utilisateur se connecter.

Avenir: Peut-être qu'un deuxième ensemble d'yeux aidera.
Je pense que la solution est dans Impersonation ou Kerberos. Je n'ai pas réussi à en savoir assez sur l'une ou l'autre de ces solutions. Il est évident que AD peut différencier les anciens mots de passe parce que le ChangePassword le fait. Ce que nous faisons est au cœur de la sécurité, donc tout n'est pas ouvert (comme la possibilité de voir l'historique des mots de passe dans AD, je n'ai pas trouvé le moyen d'y accéder).

Answer 5

Cette question n'a rien à voir code, mais le coupable est le plus entendre Active Directory ...

S'il vous plaît se référer http://support.microsoft.com/kb/906305 pour solution ...