Active Directoryアカウントロックアウトの原因をPowerShellとイベントID 4740で30秒で特定。解除コマンド、GPOの2026年推奨値、Entra ID Smart Lockoutとのハイブリッド設計まで、ヘルプデスクで明日から使える実践ガイド。
最終更新: 2026年6月12日
Active Directoryアカウントロックアウトの根本原因を突き止めるには、まずPDCエミュレータのセキュリティイベントログでイベントID 4740を確認し、Caller Computer Nameを特定するのが最短ルートだ。私の現場では、ロックアウトの8割が「古いキャッシュ資格情報を持ったデバイス」――マップされたネットワークドライブ、スマホのExchange ActiveSync、スケジュールタスク、保存されたRDP接続――から来ている。本記事ではPowerShellで原因デバイスを30秒で特定し、ロックアウトを解除し、再発を防ぐためのGroup Policy設計までを、ヘルプデスクで明日から使える形でまとめた。「ADアカウントロックアウト 原因 調査」で検索してたどり着いたなら、これ1本で完結する。
Search-ADAccount -LockedOutとUnlock-ADAccountで、GUI(ADUC)を開かずに一括解除できる。Active Directoryのアカウントロックアウトは、ドメイン内で連続して規定回数のパスワード認証に失敗するとトリガーされる。閾値はDefault Domain Policy（厳密にはアカウントポリシーが効くのはドメインルートのGPOだけだ。これはGroup Policyを長年触ってきた人間としては何度言っても伝わらない仕様で、子OUにアカウントポリシーをリンクしても無視される）で決まる。
ロックアウトの状態管理は、ドメイン内のすべてのDCに即座にレプリケーションされる緊急レプリケーション (urgent replication)として扱われる。そして「ロックアウト発生」というイベントは、PDCエミュレータのFSMOロールを持つDCに集約される。これが、調査をPDCから始めるべき理由だ。
ややこしいのは、badPwdCount属性自体は各DCがローカルに持ち、レプリケートされない点。だから「あるDCで5回失敗、別のDCで5回失敗」のように分散して発生したとき、合算ではなく、最終的にPDCに照会するロジックで判定される。Microsoft LearnのAccount lockout troubleshooting toolsの解説が、このあたりの仕組みを正確に書いている数少ない一次情報だ。
ヘルプデスク観点での結論はシンプルで、「ユーザーから『ロックアウトされた』と言われたら、最初にPDCを見ろ。他のDCのログを掻き集める前に」――これだけ覚えてもらえばいい。
PDCエミュレータは1ドメインに1つしかない。まず誰がPDCかを確認する。PowerShellで一発だ。
# PDCエミュレータFSMOロールを持つDCを取得
Get-ADDomain | Select-Object -ExpandProperty PDCEmulatorこれで返ってきたサーバ名にリモート接続して、セキュリティイベントログを開く。イベントID 4740が「ユーザーアカウントがロックアウトされました」の正規イベントだ。GUIで眺めてもいいが、対象ユーザーで絞り込むならPowerShellが圧倒的に速い。
# 対象ユーザーのロックアウトイベント（過去24時間）を取得
$targetUser = "tanaka.taro"
$pdc = (Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName $pdc -FilterHashtable @{
LogName = 'Security'
ID = 4740
StartTime = (Get-Date).AddHours(-24)
} | Where-Object { $_.Properties[0].Value -eq $targetUser } |
Select-Object TimeCreated,
@{N='LockedUser'; E={$_.Properties[0].Value}},
@{N='CallerComputer'; E={$_.Properties[1].Value}}結果に表示されるCallerComputerが、ロックを引き起こしたデバイスのNetBIOS名だ。ここに名前が入っていればほぼ勝ち。あとはそのデバイスで何が起きているかを潰せばいい。
1件ずつイベントを見ていくのは現場では遅すぎる。私はヘルプデスクのtier-1に以下のスクリプトを「ロックアウト調査の標準ツール」として配っている。コメントを多めにつけてあるので、PowerShellに不慣れなメンバーでも改造しやすい。
# =====================================================================
# Get-LockoutSource.ps1
# 指定ユーザーのアカウントロックアウト原因を、全DCのEvent 4740から収集
# tier-1向けに、結果はテーブル形式で標準出力に表示する
# =====================================================================
param(
[Parameter(Mandatory=$true)]
[string]$SamAccountName, # 調査対象のサインインID
[int]$Hours = 72 # 何時間遡るか（デフォルト3日）
)
# すべてのドメインコントローラを取得（PDCだけでなく念のため全DCを舐める）
$dcs = Get-ADDomainController -Filter * | Select-Object -ExpandProperty HostName
# 検索条件のハッシュテーブル（XPathより圧倒的に速い）
$filter = @{
LogName = 'Security'
ID = 4740
StartTime = (Get-Date).AddHours(-$Hours)
}
$results = foreach ($dc in $dcs) {
try {
Get-WinEvent -ComputerName $dc -FilterHashtable $filter -ErrorAction Stop |
Where-Object { $_.Properties[0].Value -eq $SamAccountName } |
ForEach-Object {
[PSCustomObject]@{
Time = $_.TimeCreated
DC = $dc
LockedUser = $_.Properties[0].Value
CallerComputer = $_.Properties[1].Value
}
}
} catch {
# 該当ログが無いDCは黙ってスキップ（権限不足や接続不可のケースもここに来る）
Write-Verbose "$dc : $_"
}
}
# 時系列で並べて表示
$results | Sort-Object Time -Descending | Format-Table -AutoSizeこれを.\Get-LockoutSource.ps1 -SamAccountName tanaka.taroと叩けば、ロックを引き起こした全デバイスが時系列で出る。CallerComputerが同じ名前を繰り返しているなら、犯人デバイスは確定だ。
PowerShell初心者がいる職場なら、Microsoft Entra ID SSPRの導入と組み合わせて、そもそもユーザー自身が解除できる動線を作っておくのが最も賢い。ヘルプデスク工数は別記事のとおり最大40%減らせる。
15年このネタを追いかけてきた経験から、ロックアウトの発生源を頻度順に並べる。CallerComputerが分かったあと、そのデバイス内で何を疑うかの優先順位リストだ。
ユーザーがパスワードを変えた直後、古い資格情報を握ったままのnet useマッピングが裏で再接続を試み続ける。cmdkey /listで資格情報マネージャの中身を確認し、cmdkey /delete:<target>で消す。
iPhone / Androidのメールアプリに残った古いパスワード。これがCallerComputer欄が「(空)」になる代表的な原因。Exchange OnlineのMobile Device Mailbox Policyでデバイスを特定する。
古いパスワードのまま走っているサービスアカウント系のスケジュールタスク。schtasks /query /v /fo LISTで「実行ユーザー」がロックアウト対象アカウントになっているものを探す。
mstscの「資格情報を保存する」にチェックが入ったまま放置されたRDPショートカット。cmdkey /listにTERMSRV/...で出てくる。
古いパスワードのまま設定されたWindowsサービス。services.mscの「ログオン」タブを開けば一目だが、台数があるならGet-WmiObject Win32_Serviceで一括チェック。
社内Webアプリ（古いSharePointオンプレ等）に保存された資格情報。Edgeならedge://settings/passwordsで削除。
古いPEAP-MSCHAPv2のキャッシュ。これは特に企業Wi-Fiでよく起きる。Windows 11のVPNトラブルシューティング記事で扱ったAlways On VPNの構成でもキャッシュは独立して残るので注意。
原因調査と並行して、ユーザーは仕事を再開したい。解除そのものは1コマンドだ。
# 単一ユーザーを解除
Unlock-ADAccount -Identity tanaka.taro
# 現在ロックされている全アカウントを取得
Search-ADAccount -LockedOut
# 全ロックアウトを一括解除（緊急対応時のみ、原因不明のまま濫用しないこと）
Search-ADAccount -LockedOut | Unlock-ADAccountADUCのGUIから「アカウントのロック解除」チェックボックスを操作する古いやり方は、もうやめていい。リモートワーク前提の現場ではPowerShell一択だ。
Group Policyについて私の意見を言わせてもらうと、「アカウントロックアウトのしきい値ゼロ（無効）」は2026年の今、もうあり得ない。NIST SP 800-63B改訂後も、Microsoftは依然としてロックアウトの実装を推奨している。CIS Benchmarkも同様だ。
具体的な推奨値は以下のとおり。Default Domain Policyの「コンピューターの構成 → ポリシー → Windowsの設定 → セキュリティの設定 → アカウントポリシー → アカウントロックアウトのポリシー」で設定する。
| 設定項目 | Microsoft推奨 (2026) | CIS Level 1 | 従来のデフォルト |
|---|---|---|---|
| アカウントのロックアウトのしきい値 | 10回 | 5回 | 0回（無効） |
| ロックアウト期間 | 10分 | 15分 | 30分 |
| ロックアウトカウンタのリセット | 10分 | 15分 | 30分 |
| 管理者アカウントのロックアウトを許可 | 有効 | 有効 | 無効 |
「管理者アカウントのロックアウトを許可」はWindows Server 2022 23H2で追加された設定で、ビルトインAdministratorもロックアウト対象にできる。これを使わない手はない。攻撃者がもっとも狙うのがビルトイン管理者なのに、それを永久にロックアウト不可にしている運用は、もはや時代錯誤だ。
GPO適用後は必ずgpupdate /forceとgpresult /h report.htmlで実際に効いているか確認すること。「効いているはず」で運用していると、必ず後で痛い目を見る。
ハイブリッド環境でよく混乱する論点。Entra ID Smart LockoutはオンプレADのロックアウトと別系統で動作する。Entra側は機械学習でブルートフォース攻撃と正規ユーザーのタイプミスを区別し、不審なIPからの試行のみカウントを進める仕組みだ。
デフォルト値はしきい値10回、期間60秒。これはMicrosoftのEntra ID Smart Lockout公式ドキュメントで公開されている。問題は、ハイブリッドでパスワードハッシュ同期 (PHS)またはパススルー認証 (PTA)を使っている場合、オンプレADにも認証失敗が伝播することだ。
つまりEntra側で攻撃を吸収しているつもりが、オンプレ側でロックアウトを連発する事態が起きる。私の現場では、両者の閾値を以下のように揃えている。
これと組み合わせてBitLocker回復キーをEntra IDで一元管理するように構成しておくと、デバイス紛失時の対応も含めて認証まわりが一本化される。
調査・解除がスムーズになったら、次は「そもそも起きにくくする」フェーズ。ここでGroup Policyとパスワード設定オブジェクト (PSO) の出番だ。
ロックアウト調査の前提として、以下の監査が有効になっている必要がある。Group Policyの「詳細な監査ポリシーの構成」で設定する。
SIEM（Microsoft Sentinel等）に流していれば、しきい値超過の前段階でアラートが上がるようにしておく。「ロックアウトされてから対応」では遅い。
Windows Server 2008から使えるPSOは、いまだに使われていない現場が多い。サービスアカウントは「ロックアウト期間を短く / しきい値を高く」する例外運用に最適だ。
# PSOを作成（サービスアカウント用、ロックアウトを緩める例）
New-ADFineGrainedPasswordPolicy `
-Name "ServiceAccount-PSO" `
-Precedence 10 `
-ComplexityEnabled $true `
-LockoutThreshold 20 `
-LockoutDuration "00:05:00" `
-LockoutObservationWindow "00:05:00" `
-MinPasswordLength 24 `
-PasswordHistoryCount 24
# サービスアカウント用のADグループに紐付け
Add-ADFineGrainedPasswordPolicySubject `
-Identity "ServiceAccount-PSO" `
-Subjects "SVC_Accounts"PSOはGPOよりもユーザー/グループ単位の制御がきめ細かい。ヘルプデスクが頻繁にロックアウト解除を頼まれているサービスアカウントがあるなら、まずPSOで例外を作るのが正解だ。Outlook起動時のロック連鎖が疑われるケースは、Outlookフリーズトラブルの対処法もあわせて確認すると切り分けが早い。
PDCエミュレータのDCで、セキュリティイベントログのイベントID 4740を確認します。Caller Computer Name欄に発生源デバイスのNetBIOS名が記録されています。空欄の場合はExchange ActiveSyncやレガシー認証経由の可能性が高いです。
PowerShellでUnlock-ADAccount -Identity <ユーザー名>を実行します。GUIのADUCを開くより速く、リモート作業にも適しています。複数の場合はSearch-ADAccount -LockedOut | Unlock-ADAccountで一括処理できます。
PDCエミュレータのGet-WinEvent -FilterHashtable @{LogName='Security'; ID=4740}で取得できます。SIEMに連携している環境ではKQLクエリで横断検索するのが一般的です。長期保管が必要ならWindows Event Forwardingで集約サーバに転送するのが定石。
2026年現在、Microsoftは「10回失敗 / 10分ロックアウト / 10分でカウンタリセット」を最小推奨値としています。CIS Benchmarkはより厳格な「5回 / 15分 / 15分」を推奨。組織のリスク許容度と利便性のバランスで決めますが、しきい値ゼロ（無効）はもはや許容されません。
独立して動作します。ハイブリッド環境でパスワードハッシュ同期またはパススルー認証を使っている場合、Entra側の失敗がオンプレに伝播してオンプレ側のロックアウトを引き起こすため、両者の閾値を整合させる必要があります。Conditional Accessでレガシー認証をブロックしておくのが前提です。
Microsoft Entra ID のSSPR（セルフサービスパスワードリセット）でヘルプデスクのパスワードリセットチケットを大幅削減。2026年必須の認証方法ポリシー移行、パスワードライトバック構成、PowerShell監視まで、導入から運用を実践的に解説します。