「共有フォルダが開けない」「サインインに時間がかかる」「Kerberos ではなく NTLM になっているようだ」。認証まわりのトラブルを調べるとき、どこに何の記録が残っているかを知っていると、切り分けがぐっと早くなります。この記事では、PC で使う klist と、DC とサーバのセキュリティログのイベント（4768・4769・4771・4776・4624・4625）を組み合わせて、「どちらの方式で認証したか」「どの段階で失敗したか」を調べる方法を説明します。
- 認証の記録が、PC・DC・サーバのどこに残るか
- klist とイベントで、Kerberos と NTLM のどちらで認証したかを見分ける方法
- 失敗したときの結果コードの読み方と、調べる順番
記録はどこに残るか
この記事では、ドメイン corp.example.com のユーザー user01 が、PC01 から FS01 の共有フォルダを開く場面で考えます。1回のアクセスでも、記録は3台に分かれて残ります。
| 場所 | 記録 | 何が分かるか |
|---|---|---|
| PC01 | klist | PC01 が今持っている Kerberos のチケット。どのサーバ用のチケットをもらえたか |
| DC01 | 4768・4771 | TGT（チケットをもらうためのチケット）の発行と、事前認証の失敗。主にサインインのとき |
| DC01 | 4769 | サービスチケット（サーバに見せるチケット）の発行 |
| DC01 | 4776 | NTLM の応答の確認。ドメインのアカウントなら DC に、ローカルのアカウントならそのコンピュータに残る |
| FS01 | 4624・4625 | FS01 へのログオンの成功と失敗。ログオンの種類と、使った認証方式 |
4768・4769・4771 は DC にしか記録されません。DC が複数あるときは、PC01 が実際に話した DC のログを見る必要があります。Kerberos のチケットの流れは「Kerberos認証とは？」、ログオンの種類は「ログオンの種類とは？」の記事で説明しています。
これらのイベントは、監査ポリシーで有効にしたものだけが記録されます。対応は次のとおりです。
- 4768・4771：Audit Kerberos Authentication Service（Kerberos 認証サービスの監査）
- 4769：Audit Kerberos Service Ticket Operations（Kerberos サービス チケット操作の監査）
- 4776：Audit Credential Validation（資格情報の確認の監査）
- 4624・4625：Audit Logon（ログオンの監査）
DC には「成功と失敗」を、サーバには少なくとも 4624・4625 の記録を設定しておくと、あとから調べられます。
Kerberos で認証したときの記録
PC01 から \\fs01.corp.example.com\共有 のように名前で開くと、ふつうは Kerberos で認証します。
サインインのときに TGT をもらった記録（4768）と、共有を開くときに FS01 用のサービスチケットをもらった記録（4769）が DC01 に残ります。FS01 には、ログオンの種類 3（ネットワーク）、認証パッケージ（Authentication Package）が Kerberos の 4624 が残ります。サービスチケットは一度もらえば有効期間のあいだ使い回すので、2回目以降のアクセスでは 4769 が増えないことがあります。
klist の見方
PC01 で klist を実行すると、PC01 のユーザーが今持っているチケットの一覧が表示されます。
見分けるのは Server の欄です。krbtgt/CORP.EXAMPLE.COM が TGT、cifs/fs01.corp.example.com が FS01 の共有用のサービスチケットです。cifs は共有フォルダ（SMB）のサービスの名前です。KerbTicket Encryption Type では、チケットの暗号化タイプ（AES など）が分かります。
FS01 用のチケットがなければ、共有を開いたときに Kerberos を使えていない可能性があります。klist get cifs/fs01.corp.example.com で、その場でチケットを頼んでみると、もらえない理由がエラーで表示されます。
NTLM で認証したときの記録
同じ共有でも、\\10.1.0.21\共有 のように IP アドレスで開くと、Kerberos は使えず NTLM になります。Kerberos ではサーバの名前（SPN）でチケットを頼むので、既定では IP アドレスでは頼めないからです。
NTLM では、FS01 がチャレンジと応答を DC01 に渡して確かめてもらいます。このとき DC01 に 4776 が残ります。4776 の Source Workstation（ワークステーション）は PC01 で、FS01 の名前は入りません。FS01 には、認証パッケージが NTLM の 4624 が残り、パッケージ名（NTLM のみ）の欄に NTLM V2 などのバージョンが入ります。PC01 の klist には、FS01 用のチケットは増えません。
Kerberos か NTLM かを見分ける
「Kerberos で認証しているはずなのに NTLM になっている」ことは、よくあります。次の3か所で確かめます。
NTLM になる主な原因は、IP アドレスでアクセスしている、サーバの SPN が登録されていない（または重複している）、DC に届かない、の3つです。SPN がないときは、DC01 に 4769 の失敗（結果コード 0x7）が記録され、そのあと NTLM に切り替わって 4776 が記録されます。利用者から見ると問題なく開けているので、気づきにくい点に注意してください。SPN については「SPNとは？」の記事で説明しています。
失敗したときの結果コード
失敗のイベントには、理由を表す結果コードが入ります。Kerberos のコード（4768・4769・4771）は RFC 4120 で決められた番号で、NTLM のコード（4776・4625）は Windows のエラーコードです。よく見るものを、どの段階で起きるかに分けてまとめます。
| コード | 意味と、まず確かめること |
|---|---|
| 0x6 | そのユーザー名が AD にない。ユーザー名やドメイン名の打ち間違い、削除されたアカウント |
| 0x18 | 事前認証の失敗。多くはパスワードの間違い。古いパスワードを覚えたままの PC やサービスがないか |
| 0x12 | アカウントが使えない状態（無効、ロックアウト、有効期限切れ、ログオン時間外など） |
| 0x17 | パスワードの有効期限切れ。パスワードを変えてもらう |
| 0x25 | PC と DC の時計のずれが大きすぎる（既定で5分を超えた） |
| 0x7 | サービスチケットを頼んだ SPN が見つからない。サーバの SPN の登録を確かめる |
| 0xE | 暗号化タイプが合わない。アカウントや DC で許可している暗号化タイプを確かめる |
| 0xC000006A | NTLM でパスワードが違う |
| 0xC0000234 | NTLM でアカウントがロックアウトされている |
| 0xC0000064 | NTLM でユーザー名がない |
| 0xC000015B | サーバ側で、そのログオンの種類が許可されていない（4625） |
アカウントのロックアウトの原因を探すときは、0x18 や 0xC000006A の失敗がどこから来ているかを見ます。4771 には Client Address（接続元の IP アドレス）が、4776 には Source Workstation（接続元の名前）が入るので、古いパスワードのまま動いている PC やサービスを見つけられます。
Kerberos では、PC が最初に事前認証なしで TGT を頼み、DC が「事前認証が必要」（KDC_ERR_PREAUTH_REQUIRED）と返してから、あらためて頼み直すのがふつうの流れです。ネットワークのキャプチャでこのエラーを見ても、正常な動きなので気にしなくてかまいません。
調べる順番
認証のトラブルは、次の順番で調べると迷いにくくなります。
最初に「いつ、どの PC から、どのサーバに、だれが」を決めておくことが大切です。イベントは数が多いので、時刻とアカウント名で絞り込まないと、関係ない記録に埋もれてしまいます。DC が複数あるときは、PC が話した DC を先に確かめてから、その DC のログを見ます。
確認に使うコマンド
PC01（コマンドプロンプト）：持っているチケットの一覧を表示する
klist
PC01（コマンドプロンプト）：TGT の詳細を表示する
klist tgt
PC01（コマンドプロンプト）：FS01 の共有用のチケットを、その場で頼んでみる
klist get cifs/fs01.corp.example.com
PC01（コマンドプロンプト）：最近話した DC を表示する
klist query_bind
PC01（コマンドプロンプト）：チケットを消して、取り直す状態にする
klist purge
DC01（PowerShell・管理者）：直近30分の 4768・4769・4771・4776 のうち、user01 に関するものを表示する
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768,4769,4771,4776; StartTime=(Get-Date).AddMinutes(-30)} | Where-Object Message -match 'user01'
FS01（PowerShell・管理者）：直近30分の 4624・4625 のうち、user01 に関するものを表示する
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625; StartTime=(Get-Date).AddMinutes(-30)} | Where-Object Message -match 'user01'
DC01・FS01（コマンドプロンプト・管理者）：監査ポリシーの設定をすべて表示する
auditpol /get /category:*
klist purge を実行すると、そのユーザーのチケットがすべて消えます。次にサーバにアクセスするときにチケットを取り直すので、グループを変えた直後に新しいグループを反映させたいときなどに使います。ただし、チケットを取り直せないと、サインインし直すまでアクセスできなくなることがあります。
まとめ
| 項目 | ひとことで |
|---|---|
| klist | PC が持っているチケット。Server の欄で TGT とサーバ用のチケットを見分ける |
| 4768・4771 | DC での TGT の発行と事前認証の失敗。サインインのトラブルはここ |
| 4769 | DC でのサービスチケットの発行。SPN の問題（0x7）はここ |
| 4776 | NTLM の確認。これが出ていれば NTLM で認証している |
| 4624・4625 | サーバへのログオン。認証パッケージで Kerberos か NTLM かが分かる |
| 調べる順番 | 時刻と場所を決める → klist → どの DC か → DC のイベント → サーバのイベント |
認証の記録は1台にまとまっていないので、最初は追いかけるのが大変です。PC・DC・サーバのどこに何が残るかを図1のように頭に入れておくと、「次はどこを見ればよいか」が分かるようになります。
- klist（Microsoft Learn）
- 4768(S, F): A Kerberos authentication ticket (TGT) was requested（Microsoft Learn）
- 4769(S, F): A Kerberos service ticket was requested（Microsoft Learn）
- 4771(F): Kerberos pre-authentication failed（Microsoft Learn）
- 4776(S, F): The computer attempted to validate the credentials for an account（Microsoft Learn）
- Kerberos authentication troubleshooting guidance（Microsoft Learn）
- How to enable Kerberos event logging（Microsoft Learn）
- Use a log analysis test scenario to troubleshoot Kerberos authentication（Microsoft Learn）
- Detect and remediate RC4 usage in Kerberos（4768・4769 の暗号化タイプの欄）（Microsoft Learn）
- RFC 4120：The Kerberos Network Authentication Service (V5)
コメント