Kerberosチケット削除は、共有フォルダや社内Web、SQL Server などに「権限変更したのに反映されない」「古い認証のままアクセス拒否になる」ときの有力な初手です。結論から言うと、klist purge が効くのは Kerberos の TGT やサービスチケットを取り直させたい場面 で、whoami /groups の更新、ローカル管理者権限の反映、GPO の適用まで一気に直すコマンドではありません。Windows では access token はサインイン時に作られ、Kerberos チケットとは別で管理されるためです。(Microsoft Learn)
この記事では、Windows と Active Directory を前提に、Kerberosチケット削除が有効な場面、効かない場面、klist purge と klist -li 0x3e7 purge の使い分け、gpupdate・cmdkey・net use まで含めた現場向けの判断基準をまとめます。(Microsoft Learn)
Kerberosチケット削除が有効かどうかの早見表
| 状況 | klist purge の有効度 | まず取るべき行動 |
|---|---|---|
| 共有フォルダ、社内Web、SQL など Kerberos で再認証させたい | 高い | klist purge 後に接続し直す |
ADグループ変更後、PCローカル権限や whoami /groups を更新したい | 低い | サインアウトしてサインインし直す |
| GPO、ログオンスクリプト、フォルダリダイレクト | 低い | gpupdate /force、必要なら /logoff |
| サーバーや DC の SYSTEM / コンピューター アカウント | 高い | 管理者で klist -li 0x3e7 purge |
| 共有がつながりっぱなしで古い状態を引きずる | 中 | klist purge に加えて切断・再マウント |
※上の有効度は、klist が対象にするログオン セッション、Kerberos TGT と access token の違い、既存セッションの扱い、gpupdate のログオフ要件、SYSTEM セッションの purge 手順を踏まえた実務上の目安です。(Microsoft Learn)
まず押さえたいのは、Kerberosチケット削除が触るのは「1層」だけということ
- Kerberosチケットキャッシュ
klistは現在キャッシュされている Kerberos チケットを表示し、purgeは指定したログオン セッションのチケットを削除します。-li/-lhを省略すると現在サインイン中のユーザーが対象になり、klist sessionsでログオン セッション一覧、klist getで SPN 指定のチケット取得、klist purge_bindで優先ドメイン コントローラーのキャッシュ削除も行えます。purgeはそのセッションの認証状態をいったん捨てるので、再認証が走るまで一時的にリソースへアクセスできなくなることがあります。(Microsoft Learn) - アクセス トークン
Windows はサインイン時に access token を作成し、ユーザーの SID、特権、所属グループの SID をここに入れます。つまり、whoami /allやwhoami /groupsが古いままなら、それは Kerberos チケットではなく access token 側の問題であり、klist purgeだけでは更新されません。(Microsoft Learn) - 接続セッション・保存済み資格情報・アプリ独自の token cache
既存の SMB セッションは別レイヤーで維持されますし、保存済み資格情報はcmdkey、Microsoft Entra / MSAL 系のトークンは別の token cache で管理されます。MSAL では token cache を消してもブラウザの session cookie は別物です。Kerberos を消しても、共有の再接続や資格情報削除、アプリ側のサインアウトが必要になることがあります。(Microsoft Learn)
Kerberosチケット削除が有効な場面
共有フォルダや社内Webに「新しいチケット」で入り直したいとき
Kerberos を使うネットワークリソースでは、KDC が Active Directory の情報を基に TGT を作り、その TGT を使ってサービスチケットが発行されます。重要なのは、いま使っている TGT が古いと、その TGT から作られるサービスチケットも古い前提を引きずる ことです。Microsoft の説明でも、TGS は毎回 Active Directory に問い合わせるのではなく、現在の TGT に含まれるグループ情報を使ってサービスチケットを作ります。だからこそ、古い TGT を捨てて取り直させる klist purge が効きます。TGT は通常 10 時間程度で期限切れになり、10 日間は更新可能なので、「翌日には直る」のに「今すぐは直らない」という現象も起こりえます。(Microsoft Learn)
たとえば、昼に AD グループへ追加してファイルサーバーの共有権限を付けたのに、ユーザーは午前中に取得した TGT をまだ使っている、というケースです。このときは klist purge のあとに共有へ入り直すと、切り分けが一気に進みます。(Microsoft Learn)
ADグループ変更後に「ネットワーク側」のアクセスだけを更新したいとき
Kerberosチケット削除が向くのは、対象がネットワークリソースで、なおかつ Kerberos の再取得が必要 な場面です。逆に、同じ「グループ変更」でも「この PC のローカル Administrators に入れたのに昇格しない」「whoami /groups に新しいグループが出ない」という話なら、主因は access token 側です。ここはログオンし直さない限り更新されません。(Microsoft Learn)
実務では、ファイルサーバー側の権限反映なら klist purge を試す価値があるが、端末ローカルの権限反映ならサインアウトが本命 と覚えると判断が早くなります。(Microsoft Learn)
サーバーやドメインコントローラーの SYSTEM / コンピューター アカウントが古いチケットを持っているとき
ユーザーの klist purge で消えるのは、あくまで現在ユーザーのログオン セッションです。AD レプリケーションやコンピューター アカウント、SYSTEM で動く処理が古い Kerberos チケットを持っている場合は、Microsoft のトラブルシューティングでも klist -li 0x3e7 purge が案内されています。これは SYSTEM のログオン セッションを対象にした purge で、再起動せずに切り分けしたいときに有効です。(Microsoft Learn)
「ユーザー側では何をやっても直らないが、サーバー再起動で直る」系の問題では、まず SYSTEM 側の Kerberos キャッシュを疑う価値があります。(Microsoft Learn)
Azure Files や Microsoft Entra Kerberos で新しい設定を取り直したいとき
Azure Files の公式トラブルシューティングでも、暗号化方式の変更後に klist purge → 共有の再マウント → klist get cifs/... で確認 という流れが案内されています。これは、Kerberosチケット削除が「設定変更を反映させるための再取得トリガー」として使われる典型例です。(Microsoft Learn)
オンプレ AD だけでなく、クラウド側の Kerberos 連携でも「古いチケットを捨てて新しいチケットを取得する」という考え方は同じです。(Microsoft Learn)
Kerberosチケット削除だけでは足りない場面
ローカル管理者権限や whoami /groups を更新したいとき
Windows がサインイン時にドメイン コントローラーへ到達できなかった場合、ユーザーの security context はキャッシュ情報ベースで作られます。そして Microsoft は、いったん作られた user security context は次回サインインまで更新されない と説明しています。VPN 接続後に whoami /groups が古いままなのは、そのためです。(Microsoft Learn)
しかも VPN 専用クライアントでは、Microsoft は「VPN 接続後にロック → 解除 → サインアウト → サインイン」を、user security context を更新するための 唯一のサポートされた回避策 と案内しています。runas で新しいウィンドウを出しても回避策にはなりません。(Microsoft Learn)
GPO、ログオンスクリプト、フォルダリダイレクト
gpupdate /force はポリシー更新には有効ですが、すべてをその場で完全にやり直せるわけではありません。公式ドキュメントでも、フォルダ リダイレクトや一部の拡張機能は ログオフ後に処理する必要がある ため、/logoff や /boot が用意されています。(Microsoft Learn)
さらに VPN-only 環境では、gpresult /r のグループ情報や WMI 側の情報が古いまま残ることがあります。つまり、Kerberos チケット削除は GPO の代替にはなりません。GPO 問題なら gpupdate と再サインインを軸に考えるほうが筋がいいです。(Microsoft Learn)
共有フォルダの既存セッションやマウントが残っている
Kerberosチケットを消しても、すでに張られているセッションはそのまま というのが落とし穴です。Microsoft も、既存セッションはサインアウトやセッション終了まで継続しうると説明しています。Azure Files でも purge のあとに再マウントする手順が明記されています。(Microsoft Learn)
つまり、「klist purge したのに変わらない」は珍しくありません。共有フォルダなら、接続を切ってから張り直すところまでやって初めて意味があります。net use は共有リソースへの接続・切断を行う標準コマンドです。(Microsoft Learn)
保存済み資格情報や別のトークンキャッシュが原因のとき
保存済みのユーザー名・パスワードは cmdkey で別管理です。対象サーバーへの資格情報が残っていると、Kerberos 以外のレイヤーで誤認証が起きることがあります。(Microsoft Learn)
また、Microsoft Entra / MSAL を使うアプリでは access token cache が別で、そこを消してもブラウザの session cookie は別です。ブラウザ SSO や SaaS サインインの違和感を klist purge だけで解決しようとすると、論点を外しやすくなります。(Microsoft Learn)
Kerberosチケット削除のやり方
Microsoft の Kerberos トラブルシューティングでは、クライアント側・サーバー側ともに管理者のコマンド プロンプトから klist purge や klist -li 0x3e7 purge を実行する流れが示されています。普段の運用でも、まずは管理者権限で開いて切り分けするのが安全です。(Microsoft Learn)
現在ログオン中のユーザーの Kerberos チケットを削除する
- まず、対象のアプリや共有フォルダをいったん閉じます。
- 現在の状態を確認します。
- Kerberos チケットを削除します。
- 共有やアプリへ再接続します。
klist
klist tgt
klist purge必要なら、klist get でチケット再取得のテストもできます。公式の例は次の形です。Azure Files では klist get cifs/<storage-account-name>.file.core.windows.net のように確認する手順が案内されています。(Microsoft Learn)
klist get host/%computername%purge はそのログオン セッションのキャッシュ済みチケットを破棄するため、実行直後に一時的な再認証が走るのは正常です。ここで慌てず、対象リソースに入り直して挙動を見るのがポイントです。(Microsoft Learn)
SYSTEM / コンピューター アカウントのチケットを削除する
サーバー側やドメインコントローラー側で、SYSTEM やコンピューター アカウントの Kerberos キャッシュが疑わしい場合は、現在ユーザーではなく SYSTEM セッションを対象にします。
klist sessions
klist -li 0x3e7 purgeklist sessions はログオン セッションの一覧表示、-li は対象セッションの LUID 指定です。AD レプリケーションのトラブルシューティングでは、Microsoft が klist -li 0x3e7 purge を明示しています。現在ユーザーの klist purge で効かなかったときは、この差を疑うべきです。(Microsoft Learn)
共有フォルダまで含めてやり直す例
共有セッションが残っているなら、Kerberos チケット削除だけで終わらせず、切断して再接続 します。
klist purge
net use Z: /delete
net use Z: \\server01\share保存済み資格情報が怪しいときは、次も合わせて確認します。
cmdkey /list
cmdkey /delete:server01net use は共有リソースの接続・切断、cmdkey は保存済み資格情報の一覧・削除に使います。共有フォルダの不具合を「Kerberosだけの問題」と決めつけず、この 2 つをセットで見るとハマりにくくなります。(Microsoft Learn)
GPO やローカルトークンが怪しいとき
ポリシー更新を試すなら、まずは gpupdate /force です。
gpupdate /forceログオフが必要な拡張機能まで含めて反映を進めたいなら、次のようにします。
gpupdate /force /logoffただし、user security context 自体が古いなら、結局はサインアウトしてサインインし直す必要があります。VPN-only クライアントなら、先に VPN へ接続してから サインアウトするのが重要です。(Microsoft Learn)
失敗しやすいポイント
- AD レプリケーション前に purge してしまう
グループ追加・削除の変更がまだ各ドメイン コントローラーへ複製されていないと、取り直したチケットにも新情報が載りません。Microsoft も、回避策を試す前にレプリケーションの時間を十分に取るよう案内しています。(Microsoft Learn) - 問題の本体が SPN、DNS、時刻ずれなのに purge だけ回してしまう
Kerberos の公式ガイダンスでは、SPN の重複や欠落、DNS 解決、ドメイン コントローラー到達性、端末とサーバーの時刻同期を重点項目として挙げています。特に時刻差は 5 分未満が前提です。何度もklist purgeが必要になるなら、根本原因を疑うべきです。(Microsoft Learn) - 優先ドメイン コントローラーのキャッシュを見落としている
問題が「どの DC に問い合わせるか」の偏りにあるなら、Kerberos チケットよりklist purge_bindのほうが論点に合っています。klist add_bind/query_bind/purge_bindは、その切り分け用です。(Microsoft Learn) - 既存セッションを閉じずに『効かなかった』と判断してしまう
既存の Kerberos / SMB セッションは続くため、アプリ再起動や共有再接続までやらないと結果が変わらないことがあります。purgeは万能リセットではなく、再接続の前段です。(Microsoft Learn)
迷ったときの実務フロー
klistとwhoami /allを見て、Kerberos チケットが古いのか、access token が古いのか を切り分けます。(Microsoft Learn)- 対象が共有フォルダや社内Webなど Kerberos を使うネットワークリソース なら、
klist purgeを実行し、接続を張り直します。(Microsoft Learn) - ローカル権限、
whoami /groups、GPO、ログオンスクリプトが古いなら、gpupdateだけに期待せず、ネットワーク接続後のサインアウト / サインイン を軸に考えます。(Microsoft Learn) - サーバーや DC 側の処理なら、現在ユーザーではなく SYSTEM / コンピューター アカウント を対象に
klist -li 0x3e7 purgeを検討します。(Microsoft Learn) - それでも再発するなら、レプリケーション、SPN、DNS、時刻同期、DC バインドのどこに根本原因があるかを見に行きます。(Microsoft Learn)
Kerberosチケット削除は、古いチケットを捨てて再発行させる ピンポイントな対処 です。効く場面を見極めれば非常に速い一方で、access token、GPO、既存 SMB セッション、保存済み資格情報まで一緒に直してくれる道具ではありません。まず klist と whoami /all で「どの層が古いのか」を見分け、そのうえで klist purge、再接続、gpupdate、サインアウトのどれを使うかを決める。この順番で進めると、無駄な再起動や闇雲なコマンド実行をかなり減らせます。(Microsoft Learn)
コメント