Kerberos事前認証エラーの原因となっているプロセス/プログラムを追跡（コード0x18）
2つのサーバーのうちの1つを介してロックアウトされているドメインアカウントがあります。ビルトイン監査はそれだけを教えてくれます（SERVER1、SERVER2からロックアウト）。
アカウントは5分以内にロックアウトされ、1分あたり約1リクエストのようです。
私は最初に（sysinternalsから）procmonを実行して、アカウントのロックを解除した後に新しいPROCESS STARTが生成されているかどうかを確認しようとしました。疑わしいものは何も出てきません。ワークステーションでprocmonを実行し、UACシェル（conscent.exe）に昇格した後、ADに対して認証しようとすると、スタックからntdll.dllおよびrpct4.dllが呼び出されたようです（不明）。
DCへの認証要求の原因となっているプロセスを絞り込む方法はありますか？これは常に同じですDCなので、そのサイトのサーバーである必要があります。wiresharkで呼び出しを探してみることができますが、それがどのプロセスであるかを絞り込むことはできません。実際にそれを引き起こします。
そのドメインアカウントを使用しているサービス、ドライブマッピング、またはスケジュールされたタスクもないため、ドメインの資格情報が格納されている必要があります。どのサーバーにも、そのドメインアカウントで開いているRDPセッションはありません（確認しました）。
その他のメモ
はい、「=成功/失敗」ログオン監査は、問題のDC=で有効になっています-アカウントが実際にロックアウトされるまで、失敗イベントは記録されません。
さらに掘り下げてみると、アカウントがロック解除されると、LSASS.exeが問題のDCにKERBEROSを呼び出します。これの前に（通常）Javaが付きますこれは、vCenterプロセスであるvpxd.exeによって呼び出されているようです。しかし、他の「server2」を見ると、アカウントのロックアウトが発生する可能性もあり（また）、lsass.exeへの呼び出しが表示されず、Apacheプロセスのみが生成されます。この2つの関係は、SERVER2がSERVER1のvSphereクラスターの一部であるということです（server1はvSphere OSです）。
DCのエラー
つまり、ADから言われるのは、認証前のKerberosエラーだということだけです。私が確認したところ、klistのチケットはなく、念のためにフラッシュを実行しました。このkerberosエラーの原因はまだわかりません。
Index : 202500597
EntryType : FailureAudit
InstanceId : 4771
Message : Kerberos pre-authentication failed.
Account Information:
Security ID: S-1-5-21-3381590919-2827822839-3002869273-5848
Account Name: USER
Service Information:
Service Name: krbtgt/DOMAIN
Network Information:
Client Address: ::ffff:x.x.x.x
Client Port: 61450
Additional Information:
Ticket Options: 0x40810010
Failure Code: 0x18
Pre-Authentication Type: 2
Certificate Information:
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:
Certificate information is only provided if a certificate was used for pre-authentication.
Pre-authentication types, ticket options and failure codes are defined in RFC 4120.
If the ticket was malformed or damaged during transit and could not be decrypted, then many fields
in this event might not be present.
ログオンイベントは、ログオンを試行しているプロセスを記録します。ローカルセキュリティポリシー（secpol.msc）で失敗したログオン監査を有効にして（[セキュリティの設定]> [ローカルポリシー]> [監査ポリシー]> [監査ログオンイベント]）、イベントのセキュリティイベントログを調べます。必要に応じて、グループポリシーを使用して有効にすることもできます。
実行可能パスとプロセスIDの両方を記録するプロセス情報セクションがあります。
例：
Process Information:
Process ID: 0x2a4
Process Name: C:\Windows\System32\services.exe
Kerberos0x18は確かに不正なパスワード試行です。
Kerberos0x12は、アカウントが無効、期限切れ、ロックアウト、またはログオン時間の制限です。
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4771
別の問題を調査しているときにこの古い質問を見つけましたが、同様の問題を抱えている人のために：
エラーコード0x18は、クライアントが認証を試みたときに、アカウントが既に無効になっているかロックされていることを意味します。
失敗コード0x24の同じイベントIDを見つける必要があります。これにより、アカウントのロックアウトの原因となった失敗したログイン試行が識別されます。 （これは、どこかにキャッシュされたパスワードが正しくないために発生していると想定しています。）
これらのイベントのクライアントアドレスを確認できます無効な資格情報を渡しているシステムを確認します。そこから、それが古いパスワードを持つサービスであるか、マップされたネットワークドライブなどであるかを理解する必要があります。
さまざまなエラーコードがあるため、0x24コードのイベントがない場合は、0x18以外のものを探して、アカウントロックアウトの原因を特定する必要があります。ロックアウトにつながる唯一のタイプの失敗は0x24（不正なパスワード）だと思いますが、私は間違っている可能性があります。
私は今日多くの時間を費やして、根本的な原因を見つけました。私は間違った方法で行った-ネットワークスニファーでキャプチャされた情報から（kerberosエラープロセスIDは566 = lsass.exe）。情報を要約させてください。
問題のあるPCにログオンし、昇格した権限でPowerShellを実行します
監査ログオンを有効にする
auditpol /set /subcategory:"logon" /failure:enableソースを確認する
Get-WinEvent -Logname 'Security' -FilterXPath "*[System[EventID=4625]]" -MaxEvents 2 | fl
あなたが見るなら：
プロセス情報：
呼び出し元プロセスID：0x140
呼び出し元プロセス名：C：\ Windows\System32\services.exe
古いパスワードの問題のあるアカウントからサービスが実行されていることを意味します
これは上記のメモからです。この投稿の開始者が最後のコメントで述べたようです。 Java vpxd.exeプロセスを呼び出しています。
詳細注記はい、「=成功=失敗」ログオン監査は、問題のDC=）で有効になっています-アカウントが実際にロックアウトされるまで、失敗イベントは記録されません。
さらに掘り下げてみると、LSASS.exeは、アカウントがロック解除されると、問題のDCに対してKERBEROS呼び出しを行います。これの前に（通常）Java vCenterプロセスであるvpxd.exeによって呼び出されます。しかし、他の「server2」を見ると、アカウントロックアウトが発生する可能性もあり（また）、lsass.exeへの呼び出しが表示されず、Apacheプロセスのみが生成されます。 。2つの関係は、SERVER2がSERVER1のvSphereクラスタの一部であるということです（server1はvSphere OSです）。