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

Question

Après la réinitialisation d'un mot de passe de l'utilisateur 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

Le nouveau 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.

Quand les ValidateCredentials ci-dessus fonctionne pour l'ancien mot de passe, nous attribuons les informations d'identification à un appel de service Web qui échoue avec un « 401: Non autorisé ». Erreur

vu quelque chose de quelqu'un comme ça?

Answer 1

Je Fount la réponse ici

À partir du lien ...

"Cependant, ce qui compte est que ContextOption fait pas assurer l'utilisation de Kerberos. Il se trouve que, dans certaines situations (comme si vous spécifiez AD plutôt que local, et vous avez suffisamment jusqu'à serveur date), le code choisit de ne négociez peu importe. en ce sens, la spécification d'étanchéité signifie probablement qu'il utilisera Kerberos, mais pas nécessairement exclusivement. le drapeau qui compte vraiment est burried plusieurs couches sous cette. sous les couvertures , cette méthode finit par établir un LdapConnection, fixant les informations d'identification de réseau pour la connexion, la mise que AuthType (le drapeau réel qui compte!), et enfin appeler la méthode méthode bind (). le LdapConnection.Bind () établit une connexion authentifiée l'un des serveurs AD en utilisant les informations d'identification spécifiées. le problème est que lorsque PrincipalContext.ValidateCredentials met en place cet appel (dans votre scénario), il toujours définit la auth = négociez. dans ce cas, Kerberos fait dans fait obtenir utilisé, et finit par échouer, mais le système retombe à NTLM. "

Answer 2

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

http://support.microsoft.com/kb/906305 pour la solution. ..

Answer 3

Travaux - Voir ci-dessous SOLUTION -. S'il vous plaît laissez-moi savoir si vous trouvez cela utile que notre boutique est divisée si cette solution est OK

Ce qui suit est une solution à Active Directory permettant de travailler ancien mot de passe après avoir été changé. Je aimerais beaucoup des commentaires sur l'acceptation de cette solution car il utilise le ChangePassword pendant la Authentification de connexion. Ceci est une chose étrange à faire, mais cela fonctionne. Actuellement, notre magasin n'utilise pas cette solution, donc si quelqu'un peut me dire si elles utilisent ou non qui 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é.

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 pour transférer vers la nouvelle .

Un exemple de la MA qui soutient le concept que 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 pour vous connecter. Bien que je n'ai pas la réponse à cette (autre que Microsoft a dû obtenir ce travail), il est de mon avis que ce n'est pas aussi simple que cela puisse paraître que le PC est impliqué et il a des mots de passe sur elle aussi.

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 la boîte de sécurité Windows puis, cliquez sur OK case apparaît, cliquez sur OK et vous êtes connecté. Maintenant Changer votre mot de passe pour l'utilisateur que vous avez utilisé à distance dans la boîte avec (différent de votre utilisateur Kirkman ??), et connexion fermeture de session à nouveau avec l'ancien mot de passe (dans les délais de 15 minutes à une heure + -). Le ancien mot de passe que vous avez passé la zone de sécurité Windows et la boîte OK. Lorsque vous cliquez sur OK il sera alors échouer. Si vous recommencez à partir de Remote Desktop et essayez un mauvais mot de passe vous sera arrêté à la boîte de sécurité Windows avec le message « La tentative d'ouverture de session a échoué ». Après le délai expire, vous ne serez pas passé la zone de sécurité Windows avec l'ancien mot de passe. (Assurez-vous de partir Remote Desktop chaque fois pas changer d'utilisateur qui agissent comme prévu, qui montre également que le PC impliqué en quelque sorte). Au moins, il ne le login utilisateur - mais cela montre que (ce qui semble être AD) à un certain niveau permet anciens mots de passe pour authentifier à un certain niveau

.

La recherche: J'ai trouvé beaucoup de références à ce problème et une seule solution potentielle à ce point, je ne l'ai pas été en mesure de déterminer si nous pouvons la mettre en oeuvre (ce qui est la référence à appeler strictement via Kerberos et non NTLM qui n'est pas aussi simple qu'il peut apparaissent en fonction de la documentation et mes recherches). J'ai trouvé beaucoup de liens à la façon d'interagir avec AD dans .NET mais pas Manuel AD réelle.

SOLUTION SOLUTION SOLUTION - Lisez cette partie si vous voulez que la SOLUTION !!! SOLution Présent: J'ai trouvé (par accident lors des essais) que l'appel ChangePassword à AD ne permettra pas au OldPassword passé à réussir à changer le mot de passe du nouveau mot de passe. Je suis d'avis que ce test qui fonctionne est pas réellement connu comme je l'ai trouvé aucune référence à leur utilisation. J'ai pas vraiment trouvé de solution à ce problème. Un matin, à 3h00, je compris que je pouvais exploiter cette utilisation de ChangePassword pour fournir une solution à ce problème -. Au moins un travail autour, nous pouvons utiliser immédiatement jusqu'à ce que nous pouvons déterminer une meilleure approche

D'abord, je vérifie que tout est valide et AD retourne que le mot de passe est valide. Puis un appel à ChangePassword (nom d'utilisateur, ancienmotdepasse, newpassword) avec le ancienmotdepasse et newpassword comme mot de passe fourni par l'utilisateur (à la fois le même) est fait. Je sais que l'un des deux (peut-être trois, mais pas lesviolation de la politique épée, il arrête les résultats de réussir) se produiront. Soit le OldPassword est bon et nous ne parvenons pas à cause de la politique de mot de passe n'est pas remplie (histoire, nouveau mot de passe ne peut pas être l'un des mots de passe N derniers) ou nous ne parvenons pas parce que l'ancien mot de passe est incorrect (les deux sont retournés comme une erreur d'exception avec le texte dans le message). Nous vérifions cette dernière condition et si le ancienmotdepasse est pas valide, nous ne laissons pas le journal de l'utilisateur dans.

Future: Peut-être un second ensemble d'yeux vous aidera.
Je pense que la solution est dans Impersonation ou Kerberos. Je n'ai pas eu du succès en savoir assez sur l'une de ces solutions comme. Il est évident que AD peut faire la différence entre les anciens mots de passe parce que le ChangePassword fait. Ce que nous faisons est au cœur de la sécurité afin de ne pas tout est ouvert (comme la possibilité de voir l'histoire de mot de passe dans AD, je ne l'ai pas trouvé un moyen d'y accéder).

Answer 4

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

Marc

Answer 5

Je suppose que vous êtes ValidateCredentials sur une machine exécute client. Si tel est le cas, alors il a l'ancienne (avec succès) mises en cache de mot de passe. Ceci est fait pour permettre aux utilisateurs de se connecter si Active Directory est déconnecté ou inaccessible. Prend un certain propagation des changements de temps.

Si vous voulez contourner ce problème, vous devez authentifier auprès du serveur au service du Webservice au moment de l'authentification au lieu de l'ordinateur client local.