Active Directoryでアカウントロック元を特定する手順｜4740・4771・4776の見方まで解説

Active Directoryでアカウントロック元を特定したいなら、最初に見るべきは PDCエミュレーター上の Security ログの Event ID 4740 です。PDCエミュレーターは誤パスワード時の照会先であり、アカウントロック処理も担当します。4740 には Caller Computer Name が入り、ここが端末名や中継サーバー名を掴む最短の手掛かりになります。そこが空欄、または別のドメインコントローラー名しか出ない場合は、同時刻の 4771・4776・4625 を突き合わせると、かなりの確率で発生源まで絞れます。 (Microsoft Learn)

この記事では、Active Directoryでアカウントロック元を特定する手順を、監査設定の確認から実際の切り分け、詰まりやすいポイント、調査後の戻し方まで、迷わず進められる形で整理します。

Active Directoryでアカウントロック元を特定する最短ルート

まず押さえたいのは、4740 は「ロックされた事実」、4771 は Kerberos の失敗元 IP、4776 は NTLM の失敗元端末名、4625 はログオン失敗が起きたマシン側の詳細、という役割分担です。ロック元特定で迷うのは、1つのイベントだけで完結しないからです。4740 を起点にして、必要なら 4771・4776・4625 を時刻でつなぐ、という順番で見ると判断しやすくなります。 (Microsoft Learn)

イベントID	どこで見るか	何が分かるか	注目項目
4740	PDC優先のDCの Security ログ	ロック発生そのもの	Caller Computer Name
4771	DCの Security ログ	Kerberos 認証失敗の送信元IP	Client Address, Failure Code
4776	DCの Security ログ	NTLM 認証失敗の送信元端末名	Source Workstation, Error Code
4625	失敗を記録したサーバー/端末の Security ログ	ログオン失敗の種類と送信元	Workstation Name, Source Network Address, Logon Type

実務では、4740で端末名が取れればその端末を調べる、4740で別DC名ならそのDCの 4771/4776 を追う、4740が空欄なら 4625 や Netlogon ログで補完する、という流れが最も再現性があります。PDC側で別DC名が見えるときは、その別DCが直前の認証を受けていた可能性が高い、と考えると次の一手が決まりやすくなります。 (Microsoft Learn)

事前に確認したい設定と前提条件

監査設定が不足していると、Active Directoryでアカウントロック元を特定しようとしても途中で手掛かりが途切れます。設定場所は通常、コンピューターの構成 > Windows の設定 > セキュリティ設定 > 高度な監査ポリシーの構成 > システム監査ポリシー です。少なくとも 4740 を出す Audit User Account Management、NTLM を追う Audit Credential Validation、Kerberos を追う Audit Kerberos Authentication Service、4625 を追う Audit Account Lockout / Audit Logon を確認しておくと、切り分けが大幅に楽になります。 (Microsoft Learn)

監査サブカテゴリ	主な用途	主なイベント
User Account Management	ロック/解除の把握	4740, 4767
Credential Validation	NTLM 経路の失敗元追跡	4776
Kerberos Authentication Service	Kerberos 経路の失敗元追跡	4771
Account Lockout	ロック済みアカウントの失敗確認	4625
Logon	失敗ログオン全般の詳細確認	4625

高度な監査と基本監査を混在させない のも重要です。Microsoft は、基本監査ポリシーと高度な監査ポリシーを併用すると予期しない結果になり得るため、Force audit policy subcategory settings … to override audit policy category settings を有効にして競合を防ぐよう案内しています。イベントが出たり出なかったりする環境では、ここが原因になりやすいです。 (Microsoft Learn)

有効状態は auditpol で確認できます。名前単位でサブカテゴリを照会できるので、GPO の設定値ではなく 実際に効いている監査 を見たいときに便利です。 (Microsoft Learn)

auditpol /get /subcategory:"User Account Management"
auditpol /get /subcategory:"Credential Validation"
auditpol /get /subcategory:"Kerberos Authentication Service"
auditpol /get /subcategory:"Account Lockout"
auditpol /get /subcategory:"Logon"

Active Directoryでアカウントロック元を特定する手順

PDCエミュレーターを特定する

PDCエミュレーターは netdom query fsmo で確認できます。PowerShell を使うなら Get-ADDomain の PDCEmulator プロパティでも確認可能です。ロックアウト処理は PDC エミュレーターで行われるため、複数DCがある環境でも 最初の確認先はここ です。 (Microsoft Learn)

netdom query fsmo

Get-ADDomain | Select-Object PDCEmulator

Event ID 4740 を確認する

PDCエミュレーターで イベント ビューアー > Windows ログ > Security を開き、4740 でフィルターします。見るべき項目は次の3つです。

• Account That Was Locked Out: どのアカウントがロックされたか
• Caller Computer Name: どこから失敗が来たか
• TimeCreated: ほかのイベントと突き合わせる基準時刻

ここでありがちなのが、Subject 側を犯人だと思ってしまうこと です。4740 は通常 SYSTEM によって発火するイベントなので、Subject\Security ID や Subject\Account Name が DC のコンピューターアカウントでも、そこを追っても原因にはたどり着きません。見るべきは Caller Computer Name です。 (Microsoft Learn)

PowerShell で見たいなら、Get-WinEvent と FilterHashtable で 4740 を絞り、XML から TargetUserName と CallerComputerName を抜く形が扱いやすいです。 (Microsoft Learn)

$user = 'taro'

Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4740
  StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
  $xml  = [xml]$_.ToXml()
  $data = @{}
  $xml.Event.EventData.Data | ForEach-Object { $data[$_.Name] = $_.'#text' }

  [pscustomobject]@{
    TimeCreated = $_.TimeCreated
    DC          = $_.MachineName
    User        = $data['TargetUserName']
    Caller      = $data['CallerComputerName']
  }
} | Where-Object User -eq $user |
    Sort-Object TimeCreated -Descending

この時点で Caller に PC名やサーバー名が出れば、そのマシンが次の調査先 です。Caller が 別のドメインコントローラー名 なら、PDCでロック処理はされたものの、直前の認証はその別DCで受けていた可能性が高いため、その DC の同時刻ログを追います。 (Microsoft Learn)

4771・4776・4625 を同時刻で突き合わせる

4740 だけで発生源が特定できないときは、同じ時刻帯の前後1〜2分 を目安に 4771・4776・4625 を見ます。イベントごとに役割が違うので、全部を同じ意味で見ないことが大切です。 (Microsoft Learn)

イベントID	どんなときに有効か	見るポイント	判断のしかた
4771	Kerberos で失敗していそうなとき	Client Address, Failure Code	送信元IPを取りたいときに有効
4776	NTLM で失敗していそうなとき	Source Workstation, Error Code	端末名を取りたいときに有効
4625	失敗がどのマシンで起きたか知りたいとき	Workstation Name, Source Network Address, Logon Type	サービス、タスク、RDP などの性質を読むのに有効

4771 は Kerberos の TGT 発行失敗で、DC にしか出ません。Client Address に送信元IPが出るので、端末名より IP で追いたいとき に強いイベントです。Failure Code 0x18 は wrong password を意味します。 (Microsoft Learn)

4776 は NTLM の資格情報検証イベントで、ドメインアカウントなら DC に出ます。このイベントの強みは Source Workstation に 認証を投げた端末名 が出ることです。逆に、どのサーバーに向けた認証だったかは分かりません。Error Code 0xC000006A は bad password、0xC0000234 は account locked です。 (Microsoft Learn)

4625 はログオン失敗全般で出るイベントで、失敗したログオンを受けたコンピューター側 に記録されます。共有アクセスのようなネットワークログオンならリソースをホストするサーバー、対話型ログオンならログオン先の端末に出ます。Workstation Name、Source Network Address、Logon Type を見ると、端末起点なのか、サーバー側のサービスやタスクなのかが読めます。 (Microsoft Learn)

4625 の Logon Type で見るべきポイント

4625 は「失敗した」ことだけでなく、どういう種類の失敗か を読むイベントです。特に Logon Type は、調査の当たり先を決めるのに役立ちます。 (Microsoft Learn)

Logon Type	まず疑う対象	典型例
3	ネットワーク経由の認証	共有アクセス、サーバー経由の接続
4	バッチ実行	スケジュールタスク
5	サービス実行	Windows サービス、サービスアカウント
7	ロック解除	端末のアンロック
10	リモート対話	RDP / Terminal Services

たとえば Logon Type 5 なら、ユーザーの操作より サービスの実行アカウント を先に疑うべきです。Logon Type 4 ならタスク スケジューラ、10 なら RDP 系、3 ならサーバーやアプリを経由したネットワーク認証を先に見る、という順で進めると無駄が減ります。Microsoft も 4625 の監視で 4-Batch と 5-Service の使われ方 を注視するよう案内しています。 (Microsoft Learn)

Caller Computer Name が空欄なら Netlogon ログを使う

4740 の Caller Computer Name が取れない、または 4771/4776/4625 でも中継先しか見えないときは、Netlogon デバッグログ を一時的に有効にします。Microsoft は Netlogon ログを、認証・DCロケーター・アカウントロックアウトなどの調査 に使う方法として案内しています。ログは %windir%\debug\netlogon.log に書かれます。 (Microsoft Learn)

nltest /dbflag:2080ffff

Windows Server 2012 R2 以降では、通常はそのまま有効になりますが、ログに新規書き込みが出ない場合は Netlogon サービスの再起動が必要なことがあります。調査が終わったら、必ず無効化します。 (Microsoft Learn)

nltest /dbflag:0x0

複数DCにまたがるロックアウトなら、LockoutStatus.exe が「どのDCが関与したか」を把握する近道になります。Netlogon ログの解析には NLParse.exe も使えます。なお、ALockout.dll はクライアント側で誤資格情報を送るプロセスの特定に役立ちますが、ネットワークアプリや Exchange を載せたサーバーでは使わない ほうが安全です。 (Microsoft Learn)

失敗しやすいポイント

4740 の Subject を追ってしまう のは典型的な遠回りです。4740 は通常 SYSTEM 起点なので、DC01$ や SYSTEM が見えても、それは発火主体であってロック元ではありません。まず見るべきは Caller Computer Name です。 (Microsoft Learn)

4625 の 0xC0000234 を見て「このマシンが犯人だ」と即断する のも危険です。4625 の Status 0xC0000234 は「すでにアカウントがロックされている」状態の失敗として出ることがあり、4776 でも同じコードは account locked を意味します。つまり、最初の誤パスワード入力地点ではなく、ロック後に再試行した地点 が見えているだけのことがあります。 (Microsoft Learn)

監査ポリシーが足りないのにイベントだけ追おうとする のも詰まりやすいです。高度な監査を使うなら基本監査と混在させず、Force setting を有効にして、auditpol で実効状態まで確認したほうが確実です。 (Microsoft Learn)

ロックアウトしきい値を変えてごまかす のは最後の手段です。Microsoft は、しきい値には DoS 的な副作用があり、さらに アプリが再試行回数をうまく制御できずにロックアウトを誘発する こともあると説明しています。まずやるべきは、しきい値変更ではなく、誤資格情報を送っている元を止めることです。 (Microsoft Learn)

原因を直した後の確認と戻し方

原因候補を修正したら、すぐ全端末で試すのではなく、対象アカウントを解除して、疑わしい端末やサービスを1つずつ再接続 します。再発が止まった時点の変更が、そのまま原因である可能性が高いからです。解除自体は 4767 でも確認できます。 (Microsoft Learn)

一時的に有効化した Netlogon ログ は調査後に必ず止めます。監査設定も、調査のためだけに広げたなら元に戻してください。逆に、4740・4771・4776・4625 が平常時の運用監査として妥当なら、そこだけは継続して残すと再発時に強いです。 (Microsoft Learn)

最後にやるべきことは3つです。

• PDCエミュレーターを確認する
• 4740 の Caller Computer Name を確認する
• 不明なら 4771・4776・4625、必要なら Netlogon ログまで掘る

この順番を守れば、Active Directory のアカウントロック元特定はかなりの確率で迷わず進められます。特に、4740 だけで終わらせず、4771・4776・4625 を時刻でつなぐ ことが、最短で原因に届くコツです。 (Microsoft Learn)