6

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 が古いパスワードに対して機能する場合、資格情報を Web サービス呼び出しに割り当てているため、"401: Unauthorized" エラーで失敗します。

このようなものを見た人はいますか？

4

5 に答える 5

5

この問題はコードとは関係ありませんが、原因は Active Directory にあります...

解決策については、 http://support.microsoft.com/kb/906305を参照してください...

于 2012-02-06T10:33:22.437 に答える
1

これは機能します - 以下の解決策を参照してください - 当店はこれが問題ない解決策であるかどうかについて意見が分かれているため、これが役立つと思われる場合はお知らせください。

以下は、変更後に古いパスワードが機能することを Active Directory に許可するソリューションです。ログイン認証中に ChangePassword を使用するため、このソリューションの受け入れに関するフィードバックをお待ちしています。これは奇妙なことですが、うまくいきます。現在、当店ではこのソリューションを使用していないので、使用しているかどうか教えていただけると助かります。

ありがとうございます

Active Directory と古いパスワードが有効を返す (15 分から +- 時間)。これは、SetPassword または ChangePassword が呼び出されたときに発生します。

歴史：

これは AD の「機能」と呼ばれ、設計上 AD に組み込まれているため、ユーザーがパスワードを変更すると、それらのパスワードを使用するすべてのリソースが新しいパスワードに移行できる一種の猶予期間が設けられます。

AD が最新のパスワードを知っているという概念をサポートする AD の一例は、PC でログイン パスワードを変更することです。この場合、コンピュータは古いパスワードでのログインを許可しません。私はこれに対する答えを持っていませんが (Microsoft がこれを機能させる必要があったことを除いて)、これは PC が関与していてパスワードも設定されているため、見た目ほど単純ではないと私は考えています。

AD でのパスワード変更が一定期間続く方法を示す一例は次のとおりです。

Windows 7 PC から Windows Server 2008 R2 ボックスへのリモート デスクトップの使用。Windows セキュリティ ボックスからログインし、[OK] をクリックします。ボックスが表示されます。[OK] をクリックすると、ログインが完了します。リモートに使用したユーザーのパスワードをボックスに変更し (Kirkman ユーザーとは異なります ??)、ログアウトしてログインします。再び古いパスワードを使用します (時間枠内で 15 分から 1 時間 +-)。古いパスワードを使用すると、Windows セキュリティ ボックスを通過して OK ボックスに移動できます。[OK] をクリックすると、失敗します。リモート デスクトップからやり直して間違ったパスワードを試すと、Windows セキュリティ ボックスで「ログオンに失敗しました」というメッセージが表示されて停止します。期限が切れると、古いパスワードでは Windows セキュリティ ボックスを通過できなくなります。（PCが何らかの形で関与していることも示す期待どおりに動作するユーザーを切り替えるのではなく、毎回リモートデスクトップから開始してください）。少なくともユーザーのログインは行いませんが、これは (AD のように見えるもの) あるレベルで古いパスワードをあるレベルで認証できることを示しています。

調査: この問題に関する多くの参考文献を見つけましたが、現時点で実装できるかどうかを判断できなかった 1 つの潜在的な解決策しか見つかりませんでした (これは、NTLM ではなく Kerberos を介して厳密に呼び出すことへの言及であり、それほど単純ではありません)。ドキュメントと私の調査によると表示される場合があります）。.NET で AD を操作する方法へのリンクは多数見つかりましたが、実際の AD マニュアルは見つかりませんでした。

ソリューション ソリューション ソリューション - ソリューション ソリューションが必要な場合は、この部分をお読みください!!! 現在: (テスト中に偶然に) AD への ChangePassword 呼び出しでは、渡された OldPassword がパスワードを新しいパスワードに変更できないことがわかりました。私の意見では、このテストが使用されていることへの言及が見つからないため、実際には知られていません。私は実際にこの問題の解決策を見つけていません。ある朝の午前 3 時に、この ChangePassword の使用法を利用して、この問題の解決策を提供できることに気付きました。少なくとも、より良いアプローチを決定できるまで、すぐに使用できる回避策です。

まず、すべてが有効であることを確認すると、AD はパスワードが有効であることを返します。次に、ユーザーによって提供されたパスワードとして oldpassword と newpassword を使用した ChangePassword (ユーザー名、oldpassword、newpassword) の呼び出し (どちらも同じ) が実行されます。2 つの結果のうちの 1 つ (おそらく 3 つですが、パスワード ポリシー違反により成功が妨げられます) が発生することはわかっています。OldPassword が適切で、パスワード ポリシーが満たされていないために失敗するか (履歴、新しいパスワードは最後の N 個のパスワードのいずれかではない)、または古いパスワードが正しくないために失敗します (両方とも、メッセージ内のテキストと共に例外エラーとして返されます)。この最後の条件を確認し、oldpassword が有効でない場合、ユーザーはログインできません。

将来: 2 番目の眼が役立つかもしれません。
解決策は、偽装または Kerberos にあると思います。私は解決策としてこれらのいずれかについて十分に見つけることに成功していません. ChangePassword がそれを行うため、AD が古いパスワードを区別できることは明らかです。私たちが行っていることはセキュリティの中心であるため、すべてが公開されているわけではありません (AD でパスワード履歴を表示する機能など、アクセスする方法が見つかりませんでした)。

于 2011-07-01T17:59:19.130 に答える
1

ここで答えを見つけました

リンクから...

「しかし、重要なのは ContextOption がそうではないということです。Kerberos のみを使用するようにしてください。特定の状況 (ローカルではなく AD を指定していて、十分に最新のサーバーを使用している場合など) では、コードは何があっても Negotiate を実行することを選択します。その意味で、Sealing を指定することは、おそらく Kerberos を使用することを意味しますが、必ずしも排他的ではありません。本当に重要な旗は、その下に何層も埋もれています。内部では、このメソッドは最終的に LdapConnection を確立し、接続用のネットワーク Credentials を設定し、その AuthType (重要な実際のフラグ!) を設定し、最後に Bind() メソッドを呼び出します。LdapConnection.Bind() メソッドは、指定された資格情報を使用して AD サーバーの 1 つへの認証済み接続を確立します。問題は、(シナリオで) PrincipalContext.ValidateCredentials がこの呼び出しを設定すると、常にAuthType = Negotiate を設定します。この場合、実際には Kerberos が使用され、最終的には失敗しますが、システムは NTLM にフォールバックします。」

于 2009-04-16T22:13:41.947 に答える
0

AD がそのような変更をネットワーク全体に伝播するのに必要な最大 15 分の時間を考慮に入れましたか??

マルク

于 2009-04-16T15:43:37.143 に答える
0

ValidateCredentials がクライアント マシンで実行されていると仮定します。その場合は、古い (成功した) パスワードがキャッシュされています。これは、Active Directory がオフラインまたは到達不能の場合にユーザーがログインできるようにするために行われます。変更の反映には時間がかかります。

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

于 2009-04-16T15:45:55.967 に答える