2つのサーバーのうちの1つを介してロックアウトされているドメインアカウントがあります。ビルトイン監査はそれだけを教えてくれます（SERVER1、SERVER2からロックアウト）。

アカウントは5分以内にロックアウトされ、1分あたり約1リクエストのようです。

私は最初に（sysinternalsから）procmonを実行して、アカウントのロックを解除した後に新しいPROCESS STARTが生成されているかどうかを確認しようとしました。疑わしいものは何も出てきません。私のワークステーション上でprocmonのを実行し、UACシェル（conscent.exe）に上昇した後のことがスタックからのように思えるntdll.dllとは、rpct4.dllあなたが（ないように注意してください）ADに対してのauthしようとすると、呼び出されます。

DCへの認証要求を引き起こしているプロセスを絞り込む方法はありますか？これは常に同じDCであるため、そのサイト内のサーバーである必要があります。私はwiresharkでコールを探すこともできますが、それが実際にそれをトリガーしているプロセスを絞り込むことはできません。

そのドメインアカウントを使用しているサービス、ドライブマッピング、またはスケジュールされたタスクもないため、ドメインの資格情報が格納されている必要があります。どのサーバーにも、そのドメインアカウントで開いているRDPセッションはありません（確認しました）。

その他のメモ

はい、「成功/失敗」ログオン監査は問題のDCで有効になっています。実際にアカウントがロックアウトされるまで、失敗イベントはログに記録されません。

さらにショー掘りLSASS.exeになりKERBEROS、アカウントのロックが解除されると、問題のDCへの呼び出しを。これは、（一般的には）vpxd.exevCenterプロセスであるJavaによって呼び出されるようです。しかし、他の "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

別の問題を調査しているときに私はこの古い質問を見つけましたが、同様の問題を持つ人のために：

エラーコード0x18は、クライアントが認証を試みたときに、アカウントが既に無効になっているかロックされていることを意味します。

失敗コード0x24の同じイベントIDを見つける必要があります。これにより、アカウントのロックアウトの原因となった失敗したログイン試行が特定されます。（これは、どこかにキャッシュされたパスワードが正しくないために発生していると想定しています。）

次に、それらのイベントのクライアントアドレスを調べて、どのシステムが不正な資格情報を渡しているかを確認します。そこから、それが古いパスワードのサービスか、マップされたネットワークドライブなどであるかを判断する必要があります。

さまざまなエラーコードがあるため、0x24コードのイベントがない場合は、アカウントロックアウトの原因を特定するために0x18以外のものを探す必要があります。ロックアウトにつながる唯一のタイプの失敗は0x24（不正なパスワード）だと思いますが、私は間違っている可能性があります。

Kerberos 0x18は確かに悪いパスワードの試みです。

Kerberos 0x12は、アカウントが無効、期限切れ、ロックアウト、またはログオン時間の制限です。

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4771

今日は多くの時間を費やして、根本的な原因を突き止めました。私は間違った方法で行った-ネットワークスニファでキャプチャされた情報から（kerberosエラープロセスIDは566 = lsass.exe）。情報を要約させてください。

1. 問題のあるPCにログオンし、昇格した権限でPowerShellを実行します

2. 監査ログオンを有効にする

   auditpol /set /subcategory:"logon" /failure:enable

3. ソースを確認する

   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呼び出しを行うことがわかります。これは（一般に）vCenterプロセスであるvpxd.exeによって呼び出されるように見えるjavaによって先行されます。しかし、他の "server2"を見ると、アカウントのロックアウトが（また）発生する可能性があり、lsass.exeへの呼び出しが表示されず、apacheプロセスのみが生成されます。この2つの関係は、SERVER2がSERVER1のvSphereクラスターの一部である（server1がvSphere OSである）ことだけです。