Quantcast
Channel: Ask the Network & AD Support Team
Viewing all articles
Browse latest Browse all 186

アカウント ロックアウト トラブルシューティング (第一回) –アカウント ロックアウトの仕組みと主な要因

$
0
0

 

こんにちは、Windows プラット フォーム サポートの進藤です。

 

セキュリティの向上の一環として、ユーザーが連続してパスワードの入力に失敗した場合に、アカウントをロックアウトさせる設定をされている方は多くいらっしゃるかと思います。

しかしながら、実際にアカウント ロックアウトの設定を行ってみたところ、ユーザーが入力ミスをしていない (少なくともユーザーからはそのように申告をうけている) にも関わらず、アカウントがロックアウトされてしまい、お困りの管理者の方もいらっしゃるのではないでしょうか。

今回はアカウント ロックアウトのトラブルシューティングの方法を3回に分けて解説します。

第一回  アカウント ロックアウトの仕組みと主な要因 (本稿)
第二回  アカウント ロックアウトの調査方法
第三回  アカウント ロックアウトの調査に役立つツール

また、今回のテーマはドメイン コントローラーの監査ログにログオン失敗のイベントが記録される場合の調査にも役立ちますので、参考にしていただければと思います。

 

1. アカウント ロックアウトの設定

Active Directory ではグループ ポリシーの中に、ユーザーが一定回数以上認証に失敗した場合に、そのユーザーのアカウントをロックアウトさせるための設定があります。

※Default Domain Policy で設定を行います。既定では無効となっています。

アカウント ロックアウトのポリシー

[コンピューターの構成] -[ポリシー] – [Windows の設定] – [セキュリティの設定] – [アカウント ポリシー] – [アカウント ロックアウトのポリシー]

001_accountlockout_policy

パスワードのポリシー

[コンピューターの構成] -[ポリシー] – [Windows の設定] – [セキュリティの設定] – [アカウント ポリシー] – [パスワードのポリシー]

002_password_policy

 

2. アカウント ロックアウトの仕組み

アカウントがロックアウトされる仕組みについて理解していただくために、アカウントのロックアウトに至るまでのフローを説明します。

(1) ユーザーがログオンを試みると、まずは、ログオン先のドメイン コントローラー (以下、DC と省略) で認証が行われて、パスワードが異なることが検出されます。

(2) 誤ったパスワードで認証を受けた DC は、パスワードが直近で変更されていたとしても最新のパスワード情報を持つはずの PDC エミュレーターの DC (PDCE) に対して、そのユーザーのパスワードの情報を確認します。

(3) PDCE で保持しているパスワードとも異なる場合は、PDCE と DC 上でそのユーザーの認証失敗回数 (badPwdCount) を 1 つ上げ、認証に失敗した旨の応答を返します。

(4) 上記の認証失敗が繰り返されて badPwdCount がロックアウトのしきい値を超えると、そのアカウントをロックアウトします。

(5) アカウントをロックアウトしたという情報は、その DC が所属するサイトの DC へ緊急的に複製されます。
また、サイト外の DC へは、サイト間の複製スケジュールに従い複製されます。

- 参考資料
下記の資料の「How Domain Controllers Verify Passwords」の項に、誤ったパスワードが使用された時の認証の流れについて説明しています。

  Account Lockout and Password Concepts

  https://technet.microsoft.com/en-us/library/cc780271(v=WS.10).aspx

 

3. アカウント ロックアウトが発生する主な要因

アカウント ロックアウトが発生する原因の中から、これまでにお問い合わせの多いものを以下に紹介します。

<アカウント ロックの主な原因>
(1) ドメインとローカルに同じ名前のユーザー アカウントが存在している環境で、ローカル ユーザーで作業を行ったところ、内部的にドメイン コントローラーに認証する処理が行われて、ドメインのユーザー アカウントがロック アウトした

(2) サービス、タスク、アプリケーションなどに設定されている起動アカウントのパスワードに不正なパスワードが設定されていた

(3) 資格情報マネージャーに不正なパスワードの資格情報が登録されていた (資格情報マネージャーの設定は [スタート] – [管理ツール] – [コントロール パネル] – [ユーザー アカウント] の中にあります)

(4) コンソール ログオンやリモート デスクトップ接続でログオフせずにセッションが残っている状態のまま、パスワードの変更を行った (残留セッションは net session コマンドによる確認することが可能です)

(5) ネットワーク ドライブの割り当てを行っている状態で、パスワード変更を行った

(6) 普段利用している業務用のコンピューター以外にもモバイル端末などでドメインのユーザーを使用しており、モバイル端末や管理サーバーなどに不正なパスワードが登録されていた (この場合は普段利用しているコンピューターをシャットダウンしていても アカウントがロックアウトすることがあります)

(7) ユーザーによる人為的な入力ミス

 

※ (1) のドメインとローカルで同じユーザーアカウントを使用している場合の動作について

例えば、フォルダーにドメイン ユーザーのアクセス権を付与する際、ユーザーを検索するためにドメイン コントローラーに対して認証が行われます。ドメイン ユーザーでログオンしている場合は、ドメイン ユーザーの資格情報を使用して認証が試みられるため、BadPwdCount が増加することはありません。一方、ローカル ユーザーでログオンしている場合は、ローカル ユーザーの資格情報を使用して認証が試みられます。ローカル ユーザーでの認証要求は、それを受け取ったサーバー上では、自身のローカル アカウントに同名のアカウントが存在していないか確認し、もし存在していれば、自身のローカル アカウントとして認証を試みます。ドメイン コントローラーでは、ローカル アカウントを持たないため、自身のドメインのアカウントとしてその認証動作を試みるため、結果として同名のドメイン ユーザーが、存在していれば、そのドメイン ユーザーとして認証処理が行われます。この時に、ドメイン ユーザーと異なるパスワードが設定されている場合は、認証に失敗して、BadPwdCount が増加します。この、ローカル ユーザーよりドメイン コントローラーへ認証が行われた際に認証が失敗して BadPwdCount が増加することは想定される動作となります。

本現象の回避策としては、以下のいずれかの方法となります。

(1) ローカル ユーザーを使用せず、ドメイン ユーザーでログオンを行う
(2) ドメインに存在しないユーザーでローカルにログオンする

この動作は、いろいろと情報が記載されているため、少々わかりにくいかもしれませんが、以下のサポート技術情報に記載しています。

  Network access validation algorithms and examples for Windows Server 2003, Windows XP, and Windows 2000

  http://support.microsoft.com/kb/103390/en-us

 

※ (3) の資格情報マネージャーについて

資格情報マネージャーは、ユーザーとパスワードをローカルに保存する機能です。[Windows 資格情報] にファイル サーバーに関する資格情報が登録されている場合は、[資格情報コンテナーから削除] をクリックして、資格情報を削除して現象が解消するか確認します。また、システムログに下記のようなイベントが記録される場合があります。

———-
ソース :Microsoft-Windows-Security-Kerberos
イベントID :14資格情報マネージャーに保存されているパスワードが無効です。このコンピューターまたは別のコンピューターで、パスワードを変更した可能性があります。このエラーを解決するには、コントロール パネルの資格情報マネージャーを開いて、資格情報 CONTOSO\User01 のパスワードを再入力してください。
———-

なお、システム アカウントに古い資格情報が登録されていることが原因となっている場合があります。Windows OS 上では、通常のユーザー アカウントの他に、システム アカウントやサービスを起動するためのサービス アカウント (SYSTEM や NETWORK SERVICE) がなどが存在します。通常、システム アカウントに資格情報が登録されることはありませんが、もしも何等かのアプリケーション等により登録されている場合は、その資格情報が使用されることがあります。そのため、下記の手順で、システム アカウントに問題となっているユーザーの資格情報が登録されているか確認することも必要です。もしも登録されている場合は、その資格情報の削除を行い現象が解消するかどうか確認します。

– 手順
1. 以下の URL より、PsTools をダウンロードします。

  PsExec

  https://technet.microsoft.com/ja-jp/sysinternals/bb897553.aspx

2. PsTools.zip を展開後、PsExec.exe を取り出します。

3. 対象のクライアントの任意のフォルダーに PsExec.exe を配置します。

4. 対象のクライアントに管理者権限を持つユーザーでログオンします。

5. [コマンド プロンプト] を管理者として実行します。

6. cd コマンドで PsExec.exe を保存したフォルダーに移動します。

7. 以下のコマンドを実行します。※ ライセンス同意の画面が表示された場合、[Agree] をクリックします。

psexec.exe -s cmd

8. [コマンド プロンプト] のカレント ディレクトリが、”C:\Windows\system32″ となっていることを確認します。

9. 以下のコマンドを実行し、資格情報の登録状況を確認します。

cmdkey /list

登録されている場合は、下記のように表示されます。
———————————
現在保存されている資格情報:

ターゲット: Domain:target=sample
種類: ドメイン パスワード
ユーザー: User01
———————————

10. “9.” に情報が登録されていた場合、以下のコマンドで削除します。

cmdkey /delete:<ターゲット名>

上記の例の場合は、次のように指定します。
cmdkey /delete:Domain:target=sample

 

コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。


Viewing all articles
Browse latest Browse all 186

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>