MENU

LsaSrvイベント40960・Kerberos 0xc0000234（ldap/DC）でアカウントロックアウトする原因と対処法

Active Directory

Windows Server／Active Directory 環境で、LsaSrv イベント 40960「ldap/＜DC名＞」への Kerberos 認証が 0xc0000234 で失敗し、ユーザーやサービスアカウントがロックアウトする――。本記事では、ロックされたアカウント・発生源端末・失敗している認証の種類を、DC の監査ログから最短で特定する手順と再発防止策をまとめます。

日程Fit。無料・登録不要。「いつ空いてる？」を、ひとつのリンクで。リンクを送って、○△×でかんたん日程調整。無料で日程を作る。
目次

現象：LsaSrv（LSASS）イベント 40960 と Kerberos 0xc0000234 の意味

イベント ビューアーの System ログに、ソース LsaSrv（Local Security Authority / LSASS）として次のような記録が出ることがあります。

項目例読み替え
イベントLsaSrv 40960LSASS が「特定のサービス」に対する認証でエラーを検知
対象サービスldap/dcname.domainDC 上の LDAP（Active Directory）サービスを Kerberos で利用しようとした
失敗コード0xc0000234アカウントがロックアウト状態（STATUS_ACCOUNT_LOCKED_OUT）

重要なのは、40960 は「どのユーザー（資格情報）で失敗したか」を直接は示さないことです。40960 は“症状”であり、原因特定はドメイン コントローラー（DC）の Security ログを軸に進めるのが最短です。

なぜ「ldap/＜DC名＞」が出るのか：SPN と LDAP 認証の関係

ldap/＜DC名＞ は、DC 上で稼働する LDAP（Active Directory のディレクトリ参照）を Kerberos で使うときのサービス プリンシパル名（SPN）です。

  • クライアント（端末やサーバー、アプリ）は、DC の LDAP にアクセスする前に Kerberos で 「ldap/＜DC名＞」宛てのサービス チケットを取得します。
  • そのときに使う資格情報が古い／誤っている／ロックアウトしていると、LSASS が 40960 を記録しやすくなります。

つまり、40960 が出ているときに多い実態は次のどちらかです。

  • AD 連携アプリやサービス（監視、バックアップ、グループウェア、ID 連携、MDM、プロキシ等）が、LDAP 参照（バインド）を古いパスワードで繰り返している
  • Windows 自身の仕組み（サービス、タスク、共有フォルダ再接続、資格情報キャッシュ）が、AD へ認証を投げ続けている

「ログオンに失敗している」というより、“LDAP を使う何か”が失敗しているケースが多い点がポイントです。

40960 だけでは断定できないこと

よくある誤解として、40960 の画面だけで「ロックされたアカウント」や「発生源 PC」を確定しようとしてしまうことがあります。しかし 40960 からは、次の情報が欠けがちです。

  • どのアカウントがロックされたか（表示されない／複数候補があり得る）
  • どこからロックアウトが積み上がったか（端末名や IP が出ないことがある）
  • 何をしようとして失敗したか（LDAP のどの操作か、どのプロセスかは分からない）

結論として、「ldap/＜DC名＞（AD の LDAP サービス）」への認証を、何かが古い／誤った資格情報で繰り返しており、その結果アカウントがロックアウトしている状況です。確実に詰めるには、DC の監査ログ（4740/4771/4776 など）を使って「誰が・どこから」を特定します。

最短で原因を特定する全体フロー

  1. ロックアウト条件（何回でロックされるか）と、PDC エミュレーター（PDC 役割保持 DC）を把握する
  2. DC 側で失敗系の監査を有効化し、Security ログに証跡を残す
  3. ロックアウト再発時に 4740 で「ロックされたアカウント」を確定する
  4. 4771/4776 と突き合わせて「発生源（端末名・IP）」を特定する
  5. 発生源マシン側で「古い資格情報を投げている仕組み」（サービス／タスク／共有再接続／ツール等）を潰す

事前確認：ロックアウト条件と PDC エミュレーターを確認する

ロックアウト調査は「何回失敗したらロックされる設定か」を把握していないと、時系列が読みづらくなります。まずはドメインのロックアウト条件を確認しましょう。

  • Account lockout threshold（しきい値）：何回失敗でロックするか
  • Account lockout duration（ロック継続時間）：自動解除までの時間
  • Reset account lockout counter after（カウンタ リセット時間）：失敗回数がリセットされるまで

PowerShell での確認例（RSAT/AD モジュールがある端末で実行）：

Get-ADDefaultDomainPasswordPolicy | 
  Select-Object LockoutThreshold, LockoutDuration, LockoutObservationWindow

また、アカウントによってはFine-Grained Password Policy（きめ細かなパスワード ポリシー）が適用され、既定ポリシーとロックアウト条件が違う場合があります。対象ユーザーに適用される実効ポリシーを確認するなら次が確実です。

Get-ADUserResultantPasswordPolicy -Identity <ユーザー名> |
  Select-Object LockoutThreshold, LockoutDuration, LockoutObservationWindow

次に、PDC エミュレーター（PDC 役割保持 DC）を確認します。パスワードやロックアウトの追跡では、PDC が“中心”になる場面が多いからです。

Get-ADDomain | Select-Object PDCEmulator

DC 側で監査ログを有効化する（失敗の痕跡を残す）

「どのアカウントが、どこから失敗させられているか」を特定するには、DC の Security ログに必要なイベントが残るように監査設定を整えます。推奨は、従来の監査ポリシーではなく詳細監査ポリシー（Advanced Audit Policy）で統一することです。

最低限、次のサブカテゴリを“失敗”中心に有効化すると追跡が一気に楽になります。

カテゴリサブカテゴリ（例）推奨主に拾えるイベント目的
Account LogonKerberos Authentication Service失敗4768/4771 などKerberos の認証失敗（誰が・どこから）を追う
Account LogonCredential Validation失敗4776 などNTLM 系の失敗（誤パスワード等）を追う
Account ManagementUser Account Management成功4740 などアカウント ロックアウト発生を確定する
Logon/LogoffLogon失敗4625 など（DC/発生源側）ログオン失敗の付随情報を取る

監査設定の反映確認は、DC で次を実行します。

gpupdate /force
auditpol /get /category:*

補足：従来の監査ポリシーと詳細監査ポリシーが混在すると、期待したイベントが出ないことがあります。詳細監査ポリシーを使う場合は、GPO のセキュリティ オプションにある「監査: 監査ポリシーのサブカテゴリ設定を強制…」（英語 UI では “Force audit policy subcategory settings …”）を有効化し、ポリシーの解釈を統一するとトラブルが減ります。

まず確定すべきは「ロックされたアカウント」：イベント 4740 を見る

ロックアウトが発生したら、DC の Security ログで 4740（アカウントがロックアウトされた）を探します。ここで「対象アカウント（Target Account）」が確定します。

  • Target Account Name：ロックされたアカウント名
  • Target Domain Name：ドメイン名
  • Caller Computer Name：失敗を投げた端末／サーバー名（手がかり）

イベント 40960 の画面ではアカウントが見えなくても、4740 を見れば「実際にロックされたのは誰か」がはっきりします。まずここを押さえるのが最重要です。

次に「発生源（端末／サーバー／IP）」を特定する：4740/4771/4776 の突き合わせ

4740 の Caller Computer Name がそのまま原因端末になることも多いのですが、常に当たるとは限りません。より確実にするために、同じ時間帯の次のイベントを組み合わせます。

イベント ID何が起きた見るべき項目分かること注意点
4740アカウントがロックアウトされたTarget Account Name / Caller Computer Nameロック対象アカウント、（手がかりとしての）呼び出し元呼び出し元が“中継サーバー”の場合もある
4771Kerberos 事前認証の失敗Account Name / Client Address / Failure CodeKerberos 失敗を投げた IP、失敗理由の分類ロックアウト後は別コードになる場合がある
4776NTLM 認証の失敗Account Name / WorkstationNTLM で失敗した場合の発生源Kerberos では出ない（環境により出たり出なかったり）

実務的には、次の順序で見ると迷いません。

  1. 4740 で Target Account Name を確定
  2. 同じ時刻（前後 5〜15 分）で 4771/4776 を検索し、同一アカウントの失敗を拾う
  3. 4771 の Client Address（IP） と、4740 の Caller Computer Name が一致するか確認
  4. 一致しない／空欄の場合は「中継サーバー」や「アプリ経由」を疑い、発生源側のログに降りる

LockoutStatus.exe で「どの DC に失敗が積まれているか」を掴む

複数 DC がある環境だと、失敗が発生する DC と 4740 が記録される DC が一致しないことがあります。そんなとき便利なのが LockoutStatus.exe（Account Lockout Status）です。

  • 対象アカウントの Bad Pwd Count（不正パスワード回数）が増えている DCを見つける
  • その DC の Security ログを優先的に調べる

「どの DC のログを掘ればいいか」が分かるだけで、調査スピードが一段上がります。

PowerShell でのログ抽出例（現場で使える形）

GUI で追うのが難しいときは、PowerShell で“名前付きフィールド”を抜くのが確実です。イベントの XML をパースして Data 要素を取り出すと、環境差に強い抽出ができます。

function Get-EventDataValue {
  param(
    [Parameter(Mandatory)] [System.Diagnostics.Eventing.Reader.EventRecord] $Event,
    [Parameter(Mandatory)] [string] $Name
  )
  $xml = [xml]$Event.ToXml()
  ($xml.Event.EventData.Data | Where-Object { $_.Name -eq $Name } | Select-Object -First 1).'#text'
}

# 直近24時間のロックアウト（4740）
$since = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4740; StartTime=$since } |
  ForEach-Object {
    [PSCustomObject]@{
      TimeCreated       = $_.TimeCreated
      TargetUserName    = Get-EventDataValue -Event $_ -Name 'TargetUserName'
      TargetDomainName  = Get-EventDataValue -Event $_ -Name 'TargetDomainName'
      CallerComputer    = Get-EventDataValue -Event $_ -Name 'CallerComputerName'
    }
  } | Sort-Object TimeCreated -Descending

特定ユーザーの Kerberos 失敗（4771）から IP を拾う例：

$user = '<ユーザー名>'
$since = (Get-Date).AddHours(-24)

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4771; StartTime=$since } |
Where-Object { (Get-EventDataValue -Event $_ -Name 'TargetUserName') -eq $user } |
ForEach-Object {
[PSCustomObject]@{
TimeCreated   = $*.TimeCreated
UserName      = Get-EventDataValue -Event $* -Name 'TargetUserName'
ClientAddress = Get-EventDataValue -Event $_ -Name 'IpAddress'
FailureCode   = Get-EventDataValue -Event $_ -Name 'FailureCode'
PreAuthType   = Get-EventDataValue -Event $_ -Name 'PreAuthType'
}
} | Sort-Object TimeCreated -Descending

ポイントは、4740（誰がロックされた）と、4771/4776（どこから失敗した）を時間で突き合わせることです。これで「ロック対象」「発生源」がほぼ揃います。

発生源マシン側で原因を潰す：古い資格情報を投げる“仕組み”チェックリスト

発生源（端末／サーバー名、または IP）が特定できたら、次はその機器の中でどの仕組みが古いパスワードを投げているのかを潰します。ここを外すと、ロックアウトは再発します。

よくある原因確認ポイント確認コマンド／場所対処のコツ
資格情報マネージャー（保存済み資格情報）古いドメイン資格情報が残るコントロール パネル → 資格情報マネージャー / cmdkey /list該当ターゲットを削除して再入力させる
共有フォルダの自動再接続（ネットワーク ドライブ）再起動・ログオン時に古い資格情報で接続し直すnet use / エクスプローラーの「ネットワーク ドライブ」永続接続を解除し、再マップ時に更新
Windows サービスの実行アカウントサービス アカウントのパスワード更新漏れservices.msc → 対象サービス → 「ログオン」パスワード変更後は必ずサービス側も更新（再起動含む）
タスク スケジューラ「最上位の特権で実行」「パスワードを保存」タスクで古いままtaskschd.msc / PowerShell で Principal を検索実行ユーザーの更新、または gMSA 化を検討
IIS アプリケーション プール／Web アプリアプリ プールの ID、アプリ側の LDAP バインド資格情報IIS マネージャー → アプリ プール → 詳細設定AD 参照に使うアカウントは専用化し、変更手順をドキュメント化
サードパーティ製（監視／バックアップ／同期／SSO 等）LDAP 接続先が DC で、古い Bind パスワードを保持各製品の接続設定、構成ファイル、サービス設定「AD 連携設定」の棚卸しを定期運用に組み込む
ネットワーク機器（複合機、NAS、Linux/UNIX、VPN 等）LDAP 認証／AD 参照が定期実行され、失敗すると高速で回数が積む機器側ログ、認証設定（Bind DN/Password）ロックアウトが速い場合は機器が原因のことが多い

発生源が Windows サーバーの場合、まずは「そのアカウントを使っているサービス／タスクが存在するか」を機械的に洗うと早いです。

# サービスで使われている実行アカウントを検索
Get-CimInstance Win32_Service |
  Where-Object { $_.StartName -match 'DOMAIN\\\\<ユーザー名>' } |
  Select-Object Name, DisplayName, StartName, State

# スケジュール タスクで使われている実行アカウントを検索
Get-ScheduledTask |
  Where-Object { $_.Principal.UserId -match 'DOMAIN\\\\<ユーザー名>' } |
  Select-Object TaskName, TaskPath, @{n='RunAs';e={$_.Principal.UserId}}

つまずきやすいポイント：Caller Computer Name が“本当の端末”とは限らない

4740 の Caller Computer Name が、実際の利用者端末ではなくファイル サーバーやアプリ サーバーになることがあります。これは、端末が直接 DC に投げているのではなく、次のように“中継”されるためです。

  • 端末 → ファイル サーバー（共有アクセス）→ DC（資格情報検証）
  • 端末 → 業務アプリ サーバー → DC（LDAP バインド）

この場合、DC では「中継サーバー」までしか見えないので、中継サーバー側の Security ログで追加情報を取ります。具体的には、ログオン失敗（4625）や、明示的資格情報の使用（4648）などが手がかりになります。

実務でのコツは次の通りです。

  • DC で「発生源がサーバー」と分かったら、そのサーバーの Security ログも同時に追う（時間を合わせる）
  • サーバー側で監査を有効化するなら、まずは Logon の失敗を有効化して様子を見る
  • イベントが流れすぎる場合は、対象アカウント名でフィルタする運用（PowerShell/WEF/SIEM）に切り替える

「何の認証（何をしようとしている）？」を切り分ける考え方

40960 の文字列だけを見ると「LDAP にログオン？」と混乱しがちですが、実態はLDAP（AD 参照）を使う処理が Kerberos でチケットを取りに行っているだけ、というケースが大半です。切り分けは次の観点で行うと整理できます。

観点見るもの判断の例
認証方式DC の 4771（Kerberos）/ 4776（NTLM）4771 が多いなら Kerberos 主体、4776 が出るなら NTLM が混在
接続先サービス40960 の ldap/＜DC名＞“AD に問い合わせる何か”が動いている（アプリ、同期、検索、認可）
発生源の種類Caller Computer Name / Client Address端末ならユーザー操作系、サーバーや機器なら常駐処理・定期処理を疑う
発生タイミングロックアウト発生時刻、間隔一定間隔ならタスク/監視、起動直後ならサービス、深夜帯ならバッチを疑う

「何をしようとしているか」を最短で知りたいなら、発生源マシン側のログ（4625/4648）や、稼働しているサービス・タスク・アプリの設定をセットで見るのが近道です。DC 側の 40960/4740/4771 は“入口”、発生源側で“本体”を突き止めます。

再発防止：ロックアウトを減らす運用と設計

原因を潰しても、パスワード変更や構成変更のたびに同じ事故が起きる環境だと、またどこかでロックアウトが再発します。再発を減らすための実践ポイントをまとめます。

サービス アカウントを「人のアカウント」で回さない

  • 可能なら gMSA（グループ管理サービス アカウント）を使い、パスワード管理を自動化する
  • やむを得ず通常ユーザーを使う場合でも、用途を限定した専用アカウントに分離する
  • “どこで使っているか”の棚卸し表（アプリ名、サーバー名、設定場所）を作って更新する

ロックアウト調査ができるログ設計にしておく

  • DC の Security ログ容量を見直し、上書きが早すぎないようにする
  • イベント転送（Windows Event Forwarding）や SIEM に 4740/4771/4776 を集約して、検索を楽にする
  • 「特定アカウントがロックされたら通知」などのアラートを作り、初動を早くする

パスワード変更の“あと工程”を手順化する

  • サービス アカウントのパスワードを変更したら、サービス／タスク／アプリ設定まで更新して初めて完了、と手順書に明記する
  • 変更後は、対象サーバーで「関連サービス再起動」「タスクの試験実行」まで実施する
  • 「古いセッションが残る」ことがあるため、必要に応じてアプリやサーバーの再起動も検討する

よくある質問（現場で詰まりやすい所）

4740 が見つかりません。どうすれば？

まず、DC で「User Account Management（成功）」の監査が有効かを確認してください。監査が無効だった場合、今後に備えて有効化した上で、再発時に 4740 を取りに行くのが確実です。すでにロックアウトが続いているなら、同時刻帯の 4771/4776 から対象アカウントを拾える場合があります。

Caller Computer Name が空欄、または “-” になります

ネットワーク経路や認証方式によっては、4740 だけで発生源が取れないことがあります。その場合は 4771 の Client Address（IP）を優先して追い、IP から端末/機器を逆引きするのが現実的です。DHCP 運用ならリース情報、NAC/無線なら認証ログも併用します。

同じアカウントが短時間で何度もロックされます

このパターンは、ユーザー操作よりも定期処理（監視、同期、複合機、NAS、バッチ）が原因であることが多いです。4771 の間隔が一定か、特定の IP から集中していないかを確認し、該当機器の AD/LDAP 設定を最優先で見直してください。

40960 が DC ではなくメンバー サーバー側に出ます

メンバー サーバーが「LDAP を使う何か（サービス/アプリ）」として DC に接続し、Kerberos で失敗した可能性が高いです。サーバー側で “どのアカウントが使われているか” を洗い、DC 側の 4740/4771 と時刻を合わせて突き止めます。

まとめ：40960 は入口、4740/4771/4776 で「誰が・どこから」を確定する

LsaSrv イベント 40960 と Kerberos 0xc0000234（ldap/＜DC名＞）は、AD の LDAP サービスに対してロックアウト状態の資格情報で認証が試みられたことを示す“症状”です。実際の原因調査は、DC の Security ログで 4740（ロックアウト）を起点に、4771/4776（失敗元）を突き合わせるのが最短ルートです。発生源が分かったら、資格情報マネージャー、共有再接続、サービス、タスク、サードパーティ製品など「古い資格情報を投げる仕組み」を一つずつ潰すことで、ロックアウトの連鎖を止められます。

Active Directory
Active Directory LDAP Kerberos アカウントロックアウト LSA 40960

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次