Linux上のKerberos認証統合｜チケット期限切れ障害の切り分けと復旧フロー

チケット期限切れが引き起こす障害と、その背景

Kerberos認証を組み込んだLinux環境では、サービスが突然アクセスを拒否するという障害が定期的に発生します。その大半の原因はTGT（Ticket Granting Ticket）またはサービスチケットの期限切れです。NFSマウント・SSHのGSSAPI認証・PostgreSQLのKerberos統合など、バックエンドにKerberosを使うサービスはすべてこの影響を受けます。

Kerberosのチケット体系は階層構造になっています。TGTはKDC（Key Distribution Center）が発行する「チケット取得のためのチケット」であり、クライアントはこれを使って各サービスのチケットを取得します。デフォルトでは有効期限が24時間に設定されることが多く、Renewable Lifetimeとして7日間の更新猶予期間が設けられます。この期間内であればパスワードなしで更新できますが、猶予期間を超えると再認証が必要になります。

問題は、チケット期限切れが起こしたエラーが表面上はサービス固有の問題に見えやすいことです。NFSなら「Permission denied」や「Stale file handle」、SSHなら「Authentication failed」として現れるため、Kerberosを疑わないままサービス側の設定変更に時間を費やすケースが現場では少なくありません。cronジョブやバッチ処理が深夜にTGTが期限切れになり、翌朝サイレントで失敗していた、というパターンも典型的です。

切り分けの起点：チケット状態と環境の確認

障害発生時にまず確認すべきは現在のチケット状態です。klistコマンドでTGTおよびサービスチケットの有効期限を確認します。

klist -e

-eオプションを付けると暗号化タイプも表示されます。出力に「Credentials cache: …」が表示されるものの、有効期限が過去の時刻になっていれば期限切れです。チケット自体が存在しない場合は「No credentials cache found」または「Credentials cache file ‘/tmp/krb5cc_…’ not found」のようなメッセージが返ります。

次に確認すべきは時刻同期の状態です。Kerberosは認証元とKDCの時刻差が±5分を超えると認証を拒否します（エラーコード：KRB_AP_ERR_SKEW）。

timedatectl status
chronyc tracking

systemdを使う環境ではtimedatectlでNTP同期状態を確認し、chronydを使っている場合はchronyc trackingでオフセット値を確認します。「System time offset」が数百ミリ秒以内に収まっていれば問題ありません。時刻ずれが原因の場合、kinit自体が「Clock skew too great」と返すため比較的わかりやすいですが、見逃されることも多い確認ポイントです。

KDCへの到達確認はtelnetではなく、KRB5_TRACE環境変数を使ったkinitのデバッグ出力で行うのが実務的です。

KRB5_TRACE=/dev/stderr kinit username@EXAMPLE.COM 2>&1 | head -40

接続先KDCのIPアドレスや失敗した操作が逐次出力されるため、ネットワーク経路の問題なのか認証情報の問題なのかを素早く区別できます。KDCへのTCPポート88番が到達不能な場合は「Cannot contact any KDC for realm」というエラーが返ります。

手動復旧手順：kinit と kinit -R の使い分け

チケットの期限切れが確認できた場合、最初に試みるべきはkinit -Rによるチケットの更新です。TGTがRenewable Lifetimeの範囲内（多くの場合7日間）であれば、パスワードなしで更新できます。

kinit -R
klist

更新に成功すると、klistの出力でValid startingとExpiresの時刻が更新されます。更新できなかった場合（「krb5_get_renewed_creds: Ticket expired」等）はRenewable Lifetimeも超過しているため、パスワードによる再認証が必要です。

kinit username@EXAMPLE.COM

サービスアカウント（デーモンやcronジョブ）の場合はkeytabファイルを使います。keytabはサービスアカウントのパスワードをハッシュ化して保存したファイルであり、非対話型の認証に不可欠です。

kinit -k -t /etc/krb5.keytab service/hostname@EXAMPLE.COM
klist

keytabからのkinitが成功したら、サービスを再起動する前にkvnoでサービスチケットが取得できるかを確認します。kvnoはKey Version Numberを表示するコマンドですが、実質的にはサービスチケットの取得テストとして機能します。

kvno host/target-server.example.com@EXAMPLE.COM

エラーなく返ればKDCとの連携は正常です。サービスを再起動する前のスモークテストとして取り入れることで、「再起動してみたが認証はやはり失敗する」という二度手間を防げます。

自動更新の設計：systemdタイマーと krenew の活用

手動でのkinitは応急処置にすぎません。本番環境では自動更新の仕組みを組み込む必要があります。代表的なアプローチは2つあります。

krenew を使う方法

krenew（Debian/Ubuntuではkrb5-userパッケージに含まれることが多い）はバックグラウンドでTGTを監視し、期限切れ直前に自動更新します。

krenew -K 60 -b -- /usr/local/bin/my-batch-job.sh

-K 60は60分ごとにチケットを確認・更新することを意味します。-bでバックグラウンド実行になります。後続のコマンドを指定すると、そのプロセスのライフサイクルに合わせてチケット管理を行うため、長時間実行するバッチジョブのラッパーとして有効です。

systemdタイマーを使う方法

デーモンとして常駐するサービスアカウントには、systemdのタイマーユニットとサービスユニットの組み合わせが適しています。

# /etc/systemd/system/krb5-renew.service
[Unit]
Description=Kerberos TGT Renewal

[Service]
Type=oneshot
User=serviceaccount
ExecStart=/usr/bin/kinit -k -t /etc/krb5.keytab serviceaccount@EXAMPLE.COM

# /etc/systemd/system/krb5-renew.timer
[Unit]
Description=Kerberos TGT Renewal Timer

[Timer]
OnBootSec=5min
OnUnitActiveSec=6h

[Install]
WantedBy=timers.target

有効期限24時間のTGTに対して6時間ごとに更新するのは余裕のある設定です。OnUnitActiveSecはユニットが最後に実行されてからの相対時間を指定します。登録とテストは以下の手順で行います。

systemctl daemon-reload
systemctl enable --now krb5-renew.timer
systemctl list-timers krb5-renew.timer

systemctl list-timersで「NEXT」欄に次回実行予定時刻が表示されれば正常に登録されています。初回動作確認はsystemctl start krb5-renew.serviceで即時実行してklistの出力を確認します。

切り戻しと注意点

切り戻しが必要な場面として多いのは、テスト環境で別ユーザーのチケットを取得した後に本来のユーザーに戻し忘れるケースです。kdestroyでキャッシュを明示的に破棄してから再認証することを習慣にします。

kdestroy
kinit correct-user@EXAMPLE.COM

複数のKerberosチケットキャッシュを扱う場合はKRB5CCNAME環境変数を活用します。ファイルパスを明示することで、既存の本番キャッシュを汚染せずにテスト用チケットを管理できます。

export KRB5CCNAME=FILE:/tmp/krb5cc_test
kinit test-user@EXAMPLE.COM
# テスト作業...
kdestroy
unset KRB5CCNAME

ccacheのタイプにも注意が必要です。Linuxカーネルのキーリング機能を使うKEYRINGタイプはセッション切断後に自動破棄されます。FILEタイプは/tmp/krb5cc_UIDのようなファイルに永続し、sssdと組み合わせる場合はKCM（Kerberos Credentials Manager）タイプが推奨されることもあります。/etc/krb5.confの[libdefaults]セクションにあるdefault_ccache_nameでデフォルトを制御できるため、環境に合わせて明示的に設定します。

見落とされがちな落とし穴としてDNS逆引きがあります。Kerberosのサービスプリンシパル（例：host/server.example.com）はFQDNで照合されるため、逆引きが正しく設定されていないと認証が通らないことがあります。krb5.confにrdns = falseを設定することで逆引きへの依存を減らせますが、環境によっては別の問題を引き起こすこともあるため、変更前には十分な動作確認が必要です。

2026年現行環境での差分と運用ポイント

2026年時点でRHEL 9系（AlmaLinux 9・Rocky Linux 9含む）やUbuntu 24.04 LTSを採用している環境では、Kerberosの統合方式がRHEL 7/8系から変わっている点に注意が必要です。

RHEL 9系ではsssd（System Security Services Daemon）とrealmdが標準的な統合レイヤーになっています。Active Directoryドメインへの参加はrealm joinコマンドで行えます。sssdが管理するKerberosチケットはKCMキャッシュを使うため、klistの出力先が以前の環境と異なる場合があります。全ユーザーのキャッシュ一覧を確認するには以下のオプションを使います。

klist -l

MIT Kerberos 1.21系（RHEL 9に同梱）では、FAST（Flexible Authentication Secure Tunneling）のサポートが強化されています。FASTはKDCとのAS-REQ/AS-REP交換を保護するプリ認証トンネルであり、オフライン辞書攻撃への耐性が高まります。Windows Server 2016以降のActive DirectoryはFASTに対応しているため、新規構築環境では積極的に活用を検討する価値があります。

Ubuntu 24.04 LTS環境でActive Directoryに参加する場合もrealmd + sssdが推奨構成です。winbindを使う構成は現在も動作しますが、新規構築では避けるほうが無難です。sssd管理下のKerberosチケットはsssdが自動更新するため、個別のkrenewやsystemdタイマーが不要になるケースがあります。ただし、keytabを直接使う非対話型バッチジョブでは引き続きsystemdタイマーによる管理が適しています。

クラウド統合の観点では、Azure AD Kerberos Serverを使ったオンプレミスとAzure ADのハイブリッド構成も普及しています。この構成ではTGTの発行がAzure側で行われるため、krb5.confのKDC指定をオンプレミスのドメインコントローラーだけでなくAzure ADのエンドポイントも含める必要があります。障害発生時の切り分けにはAzure ADのサインインログも併せて確認する運用フローを事前に整備しておくことが重要です。