第一回 ではアカウント ロックアウトの仕組みと主な要因について解説しました。しかしながら、誤ったパスワードは、ユーザーが普段使用しているクライアントに設定されているとは限りません。第二回目の本稿では、誤ったパスワードを設定しているコンピューターを特定するための方法について解説します。
アカウント ロックアウトの調査の流れ
アカウントロックアウトの調査は、次の順番に作業を進めます。
STEP1: 監査ログの有効化
STEP2: 認証元の特定
STEP3: 原因の特定
STEP1: 監査ログの有効化
ドメイン コントローラー全台で下記の監査の設定 (成功と失敗の両方) を有効にして、どのコンピューターから誤った認証が行われているか確認します。
「アカウント ログオン イベントの監査」
「アカウント管理の監査」
「ログオン イベントの監査」
[Tips] 監査ログの適用先
ドメインのグループ ポリシーで設定する場合は、Default Domain Controllers Policy などに設定します。 |
[Tips] 監査を有効にすることによる影響
監査の有効化による影響としては、セキュリティ ログに書き込まれるイベントの数が増えることが挙げられます。セキュリテイログなどのイベントビューアーに記録される各ログは、最大サイズを超えると古いログが消去されるため、環境によっては数時間しか取得できないといった場合があるかもしれません。その場合は、「オブジェクト アクセスの監査」や「プロセス追跡の監査」などの非常に多数のイベントが記録される監査が有効になっていないか確認します。もしも「オブジェクト アクセスの監査」や「プロセス追跡の監査」が有効になっている場合は、アカウントロックアウトの調査のために無効化することも検討してみてください。 |
[Tips] アカウント ロックアウトに関わるイベント ID
Windows Server 2008 以降のドメイン コントローラーでは、アカウント ロックアウトに関連するイベントとして、下記の ID のイベントが記録されます。 ID 4740 ユーザー アカウント ロックアウト |
STEP2: 認証元の特定
アカウント ロックアウトが発生したら、ドメイン コントローラーのセキュリティ ログより、対象のユーザー アカウントがアカウント ロックアウトしたことを示す ID 4740 のイベントを確認します。
ID 4740 のイベント
成功の監査,2014/10/29 7:22:40,Microsoft-Windows-Security-Auditing,4740,ユーザー アカウント管理,”ユーザー アカウントがロックアウトされました。サブジェクト: ロックアウトされたアカウント: |
続いて、「アカウント ロックアウトが発生した時刻より以前のイベント」を確認し、対象のユーザー アカウントが誤ったパスワードを送信したことを示すイベントを確認します。
例えば、Kerberos 認証の場合は下記のような ID 4771 のイベントが記録されます。
ID 4771 のイベント
2015/02/02 09:49:33,Microsoft-Windows-Security-Auditing,4771,Kerberos 認証サービス,”Kerberos 事前認証に失敗しました。アカウント情報: サービス情報: ネットワーク情報: 追加情報: |
NTLM 認証の場合は、下記のような ID 4776 のイベントが記録されます。
ID 4776 のイベント
ログの名前: Security |
上記のイベント ログの中に記録されている送信元を確認し、誤ったパスワードを送信しているコンピューターを特定します。
※ 認証要求が失敗する場合には PDC エミュレーターの役割を持つドメイン コントローラーにも問い合わせるため、同じ認証要求の処理の過程で PDC エミュレーターにおいても失敗の監査が記録されます。その際、PDC エミュレーター側に記録されるイベントログの説明部分に記録されるクライアント アドレスは、認証要求を転送してきたドメイン コントローラとなります。
STEP3: 原因の特定
特定したコンピューターの用途 (サーバー、クライアント) を確認し、思い当たるアプリケーションなどが無いか確認します。具体的な確認方法は 第一回 をご覧ください。もしも、アカウント ロックアウトの原因を特定できない場合は、原因と考えられるアプリケーションを一つずつアンインストールを行い、現象が発生しなくなるかどうか確認する方法が有効です。
第三回 ではアカウントロックアウトの調査に役立つツールを紹介します。
「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」