DirectoryServices.AccountManagement「古い」パスワードは、まだパスワードの変更後に検証します

StackOverflow https://stackoverflow.com/questions/756726

質問

Active Directoryでユーザーのパスワードをリセットした後、ユーザーは自分の古いパスワードを使ってログインしようとすると、次のコードは、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

私たちは、次のコードを使用してパスワードをリセットされます：

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

パスワードのリセットが正常に動作し、ユーザーが自分の新しいパスワードでログインすることができますが、その古いパスワードがまだ検証してはいけません。

上記ValidateCredentialsは、古いパスワードのために働く場合は、

、我々はその後、「401：未承認」で失敗したWebサービスの呼び出しに資格情報を割り当てている。エラー

このような誰も見て何？

役に立ちましたか？

解決 3

私はここで答えを源泉の

のリンクから...

は、「しかし、何をカウントすることContextOptionはのの唯一のKerberosの使用を保証するものではないということである。これは、特定の状況下（のようなあなたがADを指定するのではなくローカル、そしてあなたが十分を持っている場合ことが判明します日付サーバ）まで、コードはその意味で、シーリングを指定すると、おそらくそれはKerberosを使用することを意味しますが、必ずしもそうではない排他的にどのような。どんなにネゴシエート行うことを選択した。本当に重要フラグがその下にいくつかの層を埋め込まれた部分です。カバーの下に、この方法はAuthTypeディレクティブ（重要実際のフラグ！）、そして最後にバインド（）メソッドを呼び出す。LdapConnection.Bind（）メソッドは、認証済みの接続を確立することを設定し、接続のためのネットワーク資格情報を設定し、LdapConnectionを確立して終わります指定された資格情報を使用してADサーバの1。問題はPrincipalContext.ValidateCredentialsは（あなたのシナリオで）この呼を設定するとき、それはの常にのAuthTypeは=ネゴシエート設定していること。この場合、Kerberosはでないです事実取得使用、および失敗してしまうが、システムがバックNTLMに落ちる。 "

他のヒント

この問題は、コードに関連するが聞く以上の犯人は、Active Directoryでされていません...

解決のために http://support.microsoft.com/kb/906305 してご覧ください。 ..

この作品 - 以下のソリューションを参照してください - 当店は、これはOKソリューションであるかどうかに分割されてますが、これは参考場合は私に知らせてください。

。

以下は、古いパスワードが変更された後に作業できるようにActive Directoryへのソリューションです。私は非常にそれがログイン認証の際のChangePasswordを使用して、このソリューションの受け入れにフィードバックしたいと思います。これは、行うには奇妙なことですが、それは動作します。誰もが理解されるであろうと、彼らはそれを使用しているなら、私に教えたりすることはできませんので、もし現在当店はこのソリューションを使用していません。

ありがとう Chの

Active Directoryおよび旧パスワードを返す有効（+ 15分 - 時間）。 SetPasswordのかのChangePasswordが呼び出される場合に発生します。

歴史ます：

私は、ユーザーがパスワードを変更したときにこれらのパスワードを使用して、すべてのリソースを新しいものにオーバー転送することができます猶予期間のようなものがあるように、これはADの「機能」と呼ばれ、設計によってADに組み込まれていることがわかります。

ADは、最新のパスワードを知っているという概念をサポートしているADの一例は、PC上のログインパスワードを変更することである - この場合、コンピュータは古いパスワードがログインすることはできません。私はこの答えはありませんが、PCが関与していると表示されることがあり、それはあまりにもそれにパスワードを持っているとして、これはのように単純ではないというのが私の意見です（マイクロソフト以外のこの作業を取得する必要がありました）。

ADでパスワードの変更が期間の最後の操作を行う方法を示す一つの例は次のようになります。

のWindows Server 2008 R2のボックスにWindows 7のPCからリモートデスクトップを使用します。 Windowsセキュリティボックスからログイン、その後、OKボックスをクリックして表示され、[OK]をクリックして、あなたがログインしている。今、あなたはへのリモート（ごカークマンユーザー??異なる）、ログアウトして、ログインしてボックスに使用するユーザーのパスワードを変更しますもう一度、古いパスワードを使用して（期間内15分時間+に - ）。古いパスワードは、Windowsのセキュリティボックスを過ぎてして、[OK]ボックスにあなたを取得します。 [OK]をクリックすると、それは、失敗します。あなたは、リモートデスクトップからやり直すと悪いパスワードを試す場合は、「ログオンの試みが失敗しました」のメッセージでWindowsセキュリティボックスで停止されます。制限時間が満了した後、あなたは、古いパスワードを使用して、Windowsセキュリティボックスを過ぎて取得することはできません。 （期待通りにも何らかの形で関与でPCことを示して行動するユーザーを切り替えないリモートデスクトップから毎回起動することを確認してください）。少なくともそれは、ユーザのログインしません - しかし、これは（何がADのように見える）ことを示していいくつかのレベルで、古いパスワードは、いくつかのレベルに認証することができます。

。

研究： 私は、Kerberos、それがかもしれないほど簡単ではありませんではないNTLMを経由して厳密に呼び出すには、この時点まで、私たちはこれを基準である（それを実装できるかどうかを決定することができていないことは、この問題への多くの参照と一つだけの潜在的解決策を発見しましたドキュメントと私の研究）に応じて表示されます。私は.NETのADが、実際のADマニュアルと対話する方法に多くのリンクを発見した。

ソリューションソリューションソリューション - あなたはソリューションソリューションをしたい場合は、この部分を読んで！ 現在： 私は、ADへのChangePasswordコールがOldPasswordが新しいパスワードにパスワードを変更することに成功し、それに渡されることができないことを（テスト中の事故により）を発見しました。それは私がそれへの参照が使用されて見つかっていないような作業を行います。このテストは、実際に知られていない私の意見です。私は実際にこの問題への解決策を見つけていません。ある朝、午前3時に私は、この問題に対する解決策を提供するためのChangePasswordのこの使用悪用する可能性がありますことに気づいた - 。少なくとも仕事の周りに私たちはより良いアプローチを決定することができるまで、我々はすぐに使用することができます。

まず、私はすべてが有効であり、ADは、パスワードが有効であることを返すことを確認してください。次に、ユーザー（両方とも同じ）によって提供されたパスワードなどoldpasswordと新パスワードとのChangePasswordへの呼び出し（ユーザ名、oldpassword、新パスワード）が行われます。私は2つの（おそらく3の1が、PASを知っています剣のポリシー違反は、結果がどうなる）続くからそれを停止します。どちらのOldPasswordは良好であり、私たちは、パスワードポリシーを満たしていないため（の歴史を、新しいパスワードが最後のNのパスワードのいずれかをすることはできません）失敗するか、または古いパスワードが（両方ともメッセージのテキストで例外エラーとして返さ）間違っているので、我々は失敗します。我々は、この最後の条件をチェックしoldpasswordが有効でない場合、我々は、ユーザーログをさせてくださいます。

未来： 多分目の第2のセットが役立ちます。
私は解決策は、偽装またはKerberosであると思います。私は解決策として、これらのいずれかに十分なを見つけることに成功していませんでした。のChangePasswordはそれをしないので、ADは、古いパスワードを区別できることは明らかです。私たちがやっていることは（ADでパスワードの履歴を表示する機能のように、私はそれにアクセスする方法を発見していない）ので、すべてがオープンしていないセキュリティの心臓部です。

あなたはADネットワーク全体でそのような変更を伝播するために必要であることを考慮に入れた時間の最大15分かかりました？

マルク

私はあなたがValidateCredentialsは、クライアントマシン上で実行していると仮定します。その場合は、それは古い（成功した）パスワードをキャッシュしています。これは、Active Directoryがオフラインまたは到達不能である場合にログインするユーザーを有効にするために行われます。変更を伝播するいくつかの時間がかかります。

あなたはこれを回避したい場合は、代わりにローカルのクライアントマシンの認証時にWebサービスを提供するサーバーで認証する必要があります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top