DirectoryServices.AccountManagement „alte“ Passwort bestätigt noch nach Passwortänderung

Question

Nachdem ein Benutzer das Kennwort in Active Directory zurückzusetzen, wenn der Benutzer sich mit ihrem alten Passwort einzuloggen versucht, der folgende Code validiert als True:

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

Wir Zurücksetzen des Passworts mit dem folgenden Code:

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

Das Passwort-Reset funktioniert gut und der Benutzer mit dem neuen Passwort einloggen kann, aber ihr altes Passwort soll nicht noch bestätigen.

Wenn die oben ValidateCredentials für das alte Passwort funktionieren, werden wir die Anmeldeinformationen an einen Web-Service-Aufruf zuweisen, die dann mit einem „401: Unauthorized“ schlägt fehl. Fehler

Wer gesehen so etwas wie das?

Answer 1

I fount die Antwort Hier

Von dem Link ...

"Aber was zählt, ist, dass ContextOption tut nicht die Verwendung von Kerberos gewährleisten nur. Es stellt sich heraus, dass unter bestimmten Situationen (wie wenn Sie AD anstatt lokale angeben, und Sie haben eine ausreichend up to date-Server), wählt der Code, egal zu verhandeln, was. In diesem Sinne Angabe Sealing wahrscheinlich bedeutet, dass es Kerberos verwenden, aber nicht notwendigerweise ausschließlich. die Flagge, die wirklich mehrere Schichten darunter bestattet zählt. unter den Abdeckungen Dieses Verfahren endet ein LdapConnection Festlegung, für die Verbindung der Netzwerkidentifikationsdaten einstellen, dass Einstellung AuthType (die tatsächliche flag, das von Bedeutung ist!) und schließlich die bind () Methode aufrufen. die LdapConnection.Bind () Methode eine authentifizierte Verbindung herstellt zu einer des AD-Servers der angegebenen Anmeldeinformationen. das Problem ist, dass, wenn PrincipalContext.ValidateCredentials diesen Anruf einrichtet (in Ihrem Szenario), es immer die AuthType setzt = aushandeln. in diesem Fall Kerberos funktioniert in Tatsache erhalten verwendet, und andernfalls endet, aber das System fällt auf NTLM zurück. "

Answer 2

Dieses Problem ist nicht auf-Code verwendet, aber der Täter über hören ist das Active Directory ...

Bitte beachten Sie http://support.microsoft.com/kb/906305 Lösung. ..

Answer 3

This Works - Siehe SOLUTION unten -. Bitte lassen Sie mich wissen, wenn Sie dies hilfreich wie unser Geschäft auf geteilt ist, ob dies eine OK-Lösung

Das folgende ist eine Lösung für den Active Directory Altes Kennwort erlauben, nachdem sie geändert zu arbeiten. Ich würde sehr gerne Feedback über die Akzeptanz dieser Lösung, da sie die Change während der Anmeldung Authentifizierung verwendet. Dies ist eine seltsame Sache zu tun, aber es funktioniert. Derzeit unser Geschäft ist diese Lösung nicht mit so wenn jemand kann mir sagen, ob sie es nutzen oder nicht geschätzt würde.

Danke Ch

Active Directory und Alte Passwörter Rückkehr Gültig (15 Minuten + - Stunde). Dies geschieht, wenn SetPassword oder Change aufgerufen werden.

Geschichte:

Ich finde, dass dies ein „Feature“ von AD genannt und ist von Entwurf in AD gebaut, so dass, wenn ein Benutzer Passwort ändert es eine Art Gnadenfrist ist, dass alle Ressourcen, diese Passwörter zu übertragen auf den neu man erlaubt .

Ein Beispiel für AD, die das Konzept unterstützt, die AD das neueste Passwort kennt, ist, dass ein Login-Passwort auf einem PC zu ändern - in diesem Fall der Computer nicht das alte Passwort anmelden können. Während ich die Antwort auf diese Frage nicht (hatte anders als Microsoft auf diese Arbeit zu bekommen) habe es meine Meinung ist, dass dies nicht so einfach ist, wie es als das PC beteiligt erscheinen und es hat Passwörter auf sie zu.

Ein Beispiel zeigt, wie Passwortänderungen in AD für einen Zeitraum zuletzt tun kann sein:

Mit Remote Desktop von einem Windows 7-PC mit einer Windows Server 2008 R2-Box. Melde dich von der Windows Security Box dann das, klicken Sie auf OK Feld angezeigt wird, klicken Sie auf OK und Sie sind angemeldet. Jetzt ist Ihr Passwort für den Benutzer ändern Sie Remote in die Box verwendet, um mit (abweichend von Ihrem Kirkman Benutzer ??), Aus- und Einbuchen wieder mit dem alten Passwort (innerhalb Zeitraum 15 Minuten bis eine Stunde + -). Das alte Passwort wird Sie vorbei an der Windows Security Box und auf die OK-Box erhalten. Wenn Sie auf OK klicken, wird es dann nicht. Wenn Sie über von Remote Desktop starten und ein falsches Kennwort versuchen, werden Sie mit der Meldung an der Windows Security Box gestoppt werden „Der Versuch, Fehler bei der Anmeldung“. Nach Ablauf der Frist erhalten Sie nicht über die Windows Security-Box mit dem alten Passwort. (Vergewissern Sie sich von Remote Desktop jedes Mal starten NICHT Benutzer wechseln, die wie erwartet wirkt das zeigt auch, dass der PC in Beteiligten irgendwie). Zumindest hat es die Benutzeranmeldung nicht - aber das tut zeigen, dass (was AD zu sein scheint) auf einer bestimmten Ebene ermöglicht alte Passwörter bis zu einem gewissen Niveau zu authentifizieren

.

Forschung: Ich habe viele Hinweise auf dieses Problem und nur eine mögliche Lösung gefunden, dass ich zu diesem Zeitpunkt nicht in der Lage zu bestimmen, ob wir es umsetzen können (dies ist die Referenz ist streng über Kerberos zu rufen und nicht die NTLM, die als es nicht so einfach ist, kann erscheinen nach der Dokumentation und meine Forschung). Ich habe viele Links gefunden, wie mit AD in .NET, aber kein tatsächlichen AD-Handbuch zu interagieren.

Lösung Lösung Lösung - Lesen Sie diesen Teil, wenn Sie die Lösung Lösung wollen !!! Vorhanden: Ich habe festgestellt (durch Zufall während des Tests), dass der Change Aufruf AD wird nicht der OldPassword erlaubt es bestand erfolgreich das Passwort auf das neue Passwort zu ändern. Es ist meine Meinung, dass dieser Test, das funktioniert nicht wirklich bekannt, da ich nicht jede Bezugnahme auf sie gefunden haben, verwendet werden. Ich habe eigentlich keine Lösung für dieses Problem gefunden. Ein Morgens um 3.00 Uhr wurde mir klar, dass ich diese Verwendung von Change ausnutzen könnte eine Lösung für dieses Problem schaffen -. Zumindest eine Behelfslösung können wir sofort verwenden, bis wir einen besseren Ansatz bestimmen

Zuerst habe ich überprüfen, ob alles gültig ist und AD zurück, dass das Passwort gültig ist. Dann ein Anruf an Change (Benutzername, oldpassword, newpassword) mit dem oldpassword und newpassword als Passwort durch den Benutzer zur Verfügung gestellt (beide derselben) erfolgt. Ich weiß, dass eine von zwei (vielleicht drei, aber die pasVerletzung Schwert Politik hält es aus folgenden) Ergebnisse passieren wird. Entweder die OldPassword ist gut und wir scheitern, weil die Kennwortrichtlinie nicht erfüllt ist (Geschichte, kann neues Passwort nicht eines der letzten N Passwörter sein) oder wir scheitern, weil das alte Passwort nicht korrekt ist (beide zurückgegeben als Ausnahmefehler mit Text in Meldung). Wir prüfen für diese letzte Bedingung und wenn die oldpassword nicht gültig ist, wir lassen den Anwender nicht Anmeldung.

Future: Vielleicht wird ein zweiter Satz von Augen helfen.
Ich denke, die Lösung in Identitätswechsel oder Kerberos ist. Ich habe Erfolg gehabt, herauszufinden, genug, um auf eine dieser als Lösungen. Es ist offensichtlich, dass AD zwischen alten Passwörter unterscheiden kann, weil die Change es tut. Was wir tun, im Mittelpunkt der Sicherheit ist also nicht alles offen ist (wie die Fähigkeit, Passwort Geschichte in AD zu sehen, ich habe keine Möglichkeit, den Zugriff auf sie zu finden).

Answer 4

Haben Sie nehmen die bis zu 15 Minuten Zeit zu berücksichtigen, dass AD Änderungen zu propagieren erfordert wie die im gesamten Netzwerk ??

Marc

Answer 5

Ich nehme an, Sie sind ValidateCredentials auf einem Client-Rechner ausgeführt wird. Wenn das der Fall ist, dann hat es die alte (erfolgreiche) Passwort gecached. Dies geschieht, damit Benutzer anmelden, wenn das Active Directory offline oder nicht erreichbar ist. Propagierung von Änderungen dauert einige Zeit.

Wenn Sie dies umgehen möchten, können Sie mit dem Server authentifizieren soll den Webservice zum Zeitpunkt der Authentifizierung anstelle der lokalen Client-Rechner dienen.