Kerberos「Server not found in Kerberos database」エラーの完全解決ガイド

LinuxサーバーでKerberos認証を設定していて、こんなエラーメッセージに遭遇したことはありませんか?

Server not found in Kerberos database

または

kinit: Server not found in Kerberos database while getting initial credentials

このエラーは、Kerberos認証の設定でよく遭遇するトラブルの一つです。

「データベースにない？でも設定したはずなのに…」と困惑する方も多いですよね。

今回は、このエラーの原因から解決方法、予防策まで、初心者の方にも分かりやすく徹底解説していきます!

Kerberosとは何か
エラーメッセージの意味
1. よくあるエラーメッセージ
2. エラーが示している問題
エラーの原因と診断方法
解決方法: ステップバイステップ
Active Directory統合での特有の問題
予防策とベストプラクティス
よくある質問と回答
まとめ: Kerberosエラーを確実に解決しよう

Kerberosとは何か

エラー解説の前に、Kerberosの基本を理解しましょう。

Kerberos認証の基礎

**Kerberos（ケルベロス）**は、ネットワーク上で安全に認証を行うためのプロトコルです。

名前の由来は、ギリシャ神話の三つ首の番犬「ケルベロス」。3つの頭が以下を表しています:

認証サーバー（AS: Authentication Server）
チケット発行サーバー（TGS: Ticket Granting Server）
サービスサーバー

もっと簡単に言うと:

パスワードをネットワーク上で送らずに、安全に本人確認をする仕組み

Kerberosが使われる場面

Active Directory（Windows）:

WindowsのドメインコントローラーはKerberosを使っています。

Linux統合認証:

LinuxサーバーをActive Directoryドメインに参加させるとき。

NFSやSamba:

Kerberos認証でファイル共有を保護するとき。

Hadoop、Spark:

ビッグデータシステムのセキュリティ強化。

SSHやSudo:

Kerberos認証でパスワード入力を省略。

重要な用語

プリンシパル（Principal）:

Kerberosで識別される主体（ユーザーやサービス）。

形式: 名前@REALM

例: alice@EXAMPLE.COM, host/server01.example.com@EXAMPLE.COM

レルム（Realm）:

Kerberos管理ドメインの名前。通常は大文字で書きます。

例: EXAMPLE.COM

KDC（Key Distribution Center）:

Kerberosの中核サーバー。認証とチケット発行を行います。

キータブ（Keytab）:

認証に使う秘密鍵を格納したファイル。パスワードの代わりに使います。

身近な例で理解しよう

遊園地の入場システムを想像してみてください。

1. 入口で身分証を見せる（認証）

チケット売り場（KDC）で身分証を見せて、リストバンド（チケット）をもらいます。

2. 各アトラクションで提示

各アトラクション（サービス）では、リストバンドを見せるだけ。身分証は不要です。

3. リストにない人は入れない

リストバンドに書かれた名前が、遊園地の顧客リスト（Kerberosデータベース）にない場合、アトラクションには乗れません。

これが「Server not found in Kerberos database」エラーの状況です!

エラーメッセージの意味

具体的にどんなエラーが表示されるか見てみましょう。

よくあるエラーメッセージ

パターン1: kinitコマンド実行時

$ kinit user@EXAMPLE.COM
kinit: Server not found in Kerberos database while getting initial credentials

パターン2: SSH接続時

$ ssh server.example.com
Server not found in Kerberos database

パターン3: ログファイル

Server 'host/server01.example.com@EXAMPLE.COM' not found in Kerberos database

パターン4: 詳細なエラー

KDC has no support for encryption type while getting initial credentials
Server not found in Kerberos database

エラーが示している問題

このエラーメッセージは、以下のいずれかを意味しています:

1. プリンシパルが存在しない

指定したプリンシパル（ユーザーやサービス）が、KDCのデータベースに登録されていません。

2. プリンシパル名が間違っている

正しく登録されているが、接続時に指定した名前が微妙に違う（大文字小文字、スペルミスなど）。

3. レルム名が間違っている

プリンシパルは存在するが、別のレルムに登録されている。

4. サービスプリンシパルが未登録

ホストやサービスのプリンシパルがKDCに追加されていない。

5. キータブファイルの内容が古い

キータブに含まれるプリンシパルが、KDCから削除されている。

エラーの原因と診断方法

なぜこのエラーが起きるのか、原因を特定しましょう。

原因1: ホストプリンシパルの未登録

最も一般的な原因です。

状況:

新しいサーバーをKerberosドメインに参加させようとしたが、サーバーのプリンシパルをKDCに登録し忘れた。

診断方法:

KDCサーバーで以下を実行:

kadmin.local
listprincs | grep server01

自分のサーバー名が表示されなければ、未登録です。

原因2: レルム名の不一致

大文字小文字の違いでもエラーになります。

状況:

設定ファイルではexample.com（小文字）と書いたが、KDCのレルム名はEXAMPLE.COM（大文字）。

診断方法:

# /etc/krb5.confを確認
grep default_realm /etc/krb5.conf

# KDCで確認
kadmin.local -q "get_principal user@EXAMPLE.COM"

レルム名は必ず大文字で統一するのが一般的です。

原因3: プリンシパル名のタイプミス

ホスト名のスペルミスやFQDNの間違い。

状況:

キータブにはhost/server01.example.com@EXAMPLE.COMがあるが、実際のホスト名はhost/srv01.example.com@EXAMPLE.COM。

診断方法:

# 実際のホスト名を確認
hostname -f

# キータブの内容を確認
klist -kt /etc/krb5.keytab

# DNSの逆引きも確認
nslookup $(hostname -i)

原因4: キータブファイルの問題

キータブが古いか、壊れているか、権限が間違っている。

診断方法:

# キータブの内容確認
klist -kt /etc/krb5.keytab

# キータブのプリンシパルが存在するか確認
kadmin.local -q "listprincs" | grep -f <(klist -kt /etc/krb5.keytab | awk '{print $4}')

# ファイル権限確認
ls -la /etc/krb5.keytab

正しい権限: root:root 600

原因5: 時刻のずれ

Kerberosは時刻に非常に敏感です。5分以上ずれているとエラーになります。

診断方法:

# 現在時刻を確認
date

# KDCサーバーの時刻と比較
ssh kdc-server date

# 時刻同期サービスの状態確認
systemctl status chronyd

または

systemctl status ntpd

原因6: DNSの問題

ホスト名がDNSで正しく解決できない。

診断方法:

# 正引き確認
nslookup server01.example.com

# 逆引き確認
nslookup <IPアドレス>

# /etc/hosts も確認
cat /etc/hosts | grep server01

正引きと逆引きの両方が一致している必要があります。

解決方法: ステップバイステップ

それぞれの原因に対する解決策です。

解決策1: ホストプリンシパルの追加

ステップ1: KDCサーバーにログイン

管理者としてKDCサーバーにアクセスします。

ステップ2: kadminを起動

sudo kadmin.local

kadmin.localはローカルでのみ使える管理ツールで、パスワード不要です。

ステップ3: ホストプリンシパルを追加

addprinc -randkey host/server01.example.com@EXAMPLE.COM

-randkey: ランダムなキーを生成（パスワード不要）
host/: ホストプリンシパルの接頭辞
server01.example.com: FQDN（完全修飾ドメイン名）
@EXAMPLE.COM: レルム名（大文字）

ステップ4: キータブにエクスポート

ktadd -k /tmp/server01.keytab host/server01.example.com@EXAMPLE.COM

これで/tmp/server01.keytabファイルが作成されます。

ステップ5: kadminを終了

quit

ステップ6: キータブをクライアントに転送

# SCPで安全に転送
scp /tmp/server01.keytab root@server01:/etc/krb5.keytab

# 転送後、KDC側のファイルは削除
rm /tmp/server01.keytab

ステップ7: クライアント側で権限設定

# server01サーバー上で実行
sudo chown root:root /etc/krb5.keytab
sudo chmod 600 /etc/krb5.keytab

ステップ8: 動作確認

# キータブを使って認証テスト
kinit -kt /etc/krb5.keytab host/server01.example.com@EXAMPLE.COM

# チケットが取得できたか確認
klist

成功すれば、チケット情報が表示されます!

解決策2: レルム名の修正

ステップ1: /etc/krb5.confを編集

sudo vi /etc/krb5.conf

ステップ2: default_realmを確認・修正

[libdefaults]
    default_realm = EXAMPLE.COM

レルム名は必ず大文字にしてください。

ステップ3: realmsセクションも確認

[realms]
    EXAMPLE.COM = {
        kdc = kdc.example.com
        admin_server = kdc.example.com
    }

こちらも大文字で統一します。

ステップ4: 再度テスト

kinit user@EXAMPLE.COM

解決策3: ホスト名の確認と修正

ステップ1: 現在のホスト名を確認

hostname
hostname -f

hostname -fでFQDN（完全修飾ドメイン名）が正しく返ってくるか確認します。

ステップ2: ホスト名が違っていたら修正

# ホスト名を恒久的に変更
sudo hostnamectl set-hostname server01.example.com

# /etc/hosts も更新
sudo vi /etc/hosts

/etc/hostsの内容例:

127.0.0.1   localhost
192.168.1.10   server01.example.com server01

ステップ3: DNS設定の確認

# 正引き
nslookup server01.example.com

# 逆引き
nslookup 192.168.1.10

両方が一致している必要があります。

ステップ4: 正しいプリンシパルで再登録

KDCサーバーで:

kadmin.local
# 古いプリンシパルを削除（存在する場合）
delprinc host/old-hostname.example.com@EXAMPLE.COM

# 正しいプリンシパルを追加
addprinc -randkey host/server01.example.com@EXAMPLE.COM
ktadd -k /tmp/server01.keytab host/server01.example.com@EXAMPLE.COM
quit

キータブをクライアントに転送して設置します。

解決策4: キータブの再生成

キータブが壊れているか古い場合。

ステップ1: 既存キータブのバックアップ

sudo cp /etc/krb5.keytab /etc/krb5.keytab.backup

ステップ2: KDCでプリンシパルのkvnoを更新

kadmin.local
change_password -randkey host/server01.example.com@EXAMPLE.COM
ktadd -k /tmp/server01.keytab host/server01.example.com@EXAMPLE.COM
quit

change_passwordでキーバージョン番号（kvno）が増えます。

ステップ3: 新しいキータブを配置

前述の手順と同じです。

解決策5: 時刻同期の設定

ステップ1: NTP/Chronydのインストール

# CentOS/RHEL 8以降、Fedora
sudo dnf install chrony

# Ubuntu/Debian
sudo apt install chrony

ステップ2: 設定ファイルの編集

sudo vi /etc/chrony.conf

NTPサーバーを設定:

server ntp.example.com iburst
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst

KDCサーバーと同じNTPサーバーを使うのが理想的です。

ステップ3: サービスの起動

sudo systemctl enable chronyd
sudo systemctl start chronyd

ステップ4: 時刻同期の確認

chronyc tracking

ステップ5: 手動で時刻を合わせる（緊急時）

sudo chronyd -q

または直接時刻を設定:

sudo date -s "2025-01-15 14:30:00"

解決策6: DNS設定の修正

ステップ1: /etc/resolv.confの確認

cat /etc/resolv.conf

正しいDNSサーバーが設定されているか確認:

nameserver 192.168.1.1
search example.com

ステップ2: /etc/nsswitch.confの確認

grep hosts /etc/nsswitch.conf

以下のようになっているか確認:

hosts: files dns

または

hosts: dns files

ステップ3: DNSサーバーにレコード追加

DNSサーバー側で、正引き・逆引きレコードを追加します。

正引きレコード（Aレコード）:

server01.example.com.    IN    A    192.168.1.10

逆引きレコード（PTRレコード）:

10.1.168.192.in-addr.arpa.    IN    PTR    server01.example.com.

ステップ4: DNS動作確認

nslookup server01.example.com
nslookup 192.168.1.10

Active Directory統合での特有の問題

Windows Active DirectoryとLinuxの統合時の注意点です。

ADドメイン参加時のエラー

よくあるシナリオ:

# ドメイン参加コマンド
sudo realm join -v EXAMPLE.COM

# エラー
Server not found in Kerberos database

原因:

コンピューターアカウントがADに作成されていない。

解決策:

方法1: AD管理者に事前作成を依頼

Active Directory側で、コンピューターオブジェクトを事前に作成してもらいます。

方法2: 管理者権限で参加

sudo realm join -U administrator EXAMPLE.COM

AD管理者のパスワードを入力します。

方法3: 特定のOUを指定

sudo realm join --computer-ou="OU=Servers,DC=example,DC=com" -U administrator EXAMPLE.COM

SPNの重複

Service Principal Name（SPN）が重複している場合。

診断:

ADサーバーで以下を実行:

setspn -Q HOST/server01.example.com

複数の結果が返ってきたら重複しています。

解決:

# 古いSPNを削除
setspn -D HOST/server01.example.com OLD-COMPUTER

# 正しいオブジェクトに追加（通常は自動）
setspn -A HOST/server01.example.com server01

大文字小文字の問題

Active Directoryのレルム名は通常、DNSドメイン名の大文字版です。

例:

DNSドメイン: example.com
Kerberosレルム: EXAMPLE.COM

Linux側の/etc/krb5.confで、レルム名が大文字になっているか必ず確認してください。

予防策とベストプラクティス

エラーを事前に防ぐ方法です。

予防策1: ドキュメント化

すべてのプリンシパル名、レルム名、ホスト名を文書化しましょう。

記録すべき情報:

サーバーFQDN
プリンシパル名
レルム名
KDCサーバーのアドレス
キータブファイルの場所

予防策2: 命名規則の統一

ホスト名やプリンシパル名に一貫性のあるルールを設けます。

推奨ルール:

ホスト名は常にFQDN
レルム名は常に大文字
プリンシパル形式: サービス/FQDN@REALM

予防策3: 自動化スクリプト

プリンシパル作成とキータブ配布を自動化します。

簡単なスクリプト例:

#!/bin/bash
# add-kerberos-host.sh

HOSTNAME=$1
REALM="EXAMPLE.COM"
KEYTAB_FILE="/tmp/${HOSTNAME}.keytab"

# プリンシパル追加
kadmin.local -q "addprinc -randkey host/${HOSTNAME}.example.com@${REALM}"

# キータブ作成
kadmin.local -q "ktadd -k ${KEYTAB_FILE} host/${HOSTNAME}.example.com@${REALM}"

# 転送
scp ${KEYTAB_FILE} root@${HOSTNAME}:/etc/krb5.keytab

# クリーンアップ
rm ${KEYTAB_FILE}

echo "完了: ${HOSTNAME}のKerberos設定"

予防策4: 監視とアラート

Kerberos認証の失敗を監視します。

ログ監視:

# Kerberosログを監視
tail -f /var/log/krb5kdc.log

# 失敗をカウント
grep "Server not found" /var/log/krb5kdc.log | wc -l

Nagios/Zabbixプラグイン:

Kerberos認証の動作確認を定期的に行うプラグインを設定します。

予防策5: 定期的なキータブ更新

セキュリティのため、キータブは定期的に更新しましょう。

Cronジョブ例:

# 毎月1日の深夜にキータブを再生成
0 2 1 * * /usr/local/bin/regenerate-keytabs.sh

予防策6: テスト環境の構築

本番環境で問題が起きる前に、テスト環境で確認します。

テストチェックリスト:

[ ] プリンシパルの追加が成功するか
[ ] キータブでの認証が成功するか
[ ] SSH Kerberos認証が動くか
[ ] NFSマウントが成功するか
[ ] 時刻同期が正常か

よくある質問と回答

Q1: kinitは成功するのに、サービスでエラーになる

A: ユーザープリンシパルとサービスプリンシパルは別物です。

kinit user@REALMが成功しても、host/server@REALMが存在しないとサービスは動きません。

サービスプリンシパルもKDCに登録する必要があります。

Q2: Windows ADでは動くのに、Linux KDCで動かない

A: 設定の微妙な違いが原因かもしれません。

レルム名の大文字小文字
暗号化タイプのサポート
DNSサフィックスの設定

/etc/krb5.confを見直してください。

Q3: エラーログにプリンシパル名が表示されない

A: より詳細なログを有効にしましょう。

# /etc/krb5.confに追加

kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmin.log default = FILE:/var/log/krb5lib.log

KDCサービスを再起動して、再度エラーを再現してください。

Q4: 複数のレルムを使っている場合は?

A: /etc/krb5.confで複数のレルムを定義できます。

[realms]
    EXAMPLE.COM = {
        kdc = kdc1.example.com
    }
    ANOTHER.COM = {
        kdc = kdc2.another.com
    }

プリンシパル指定時に、正しいレルムを指定してください。

Q5: キータブを再生成すると、古いチケットは無効になる?

A: はい、キーバージョン番号（kvno）が変わるため、古いチケットは使えなくなります。

アクティブなセッションがある場合は、計画的に更新しましょう。

Q6: Docker/Kubernetesでの注意点は?

A: コンテナ環境では以下に注意:

ホスト名が動的に変わる場合がある
DNSの逆引き設定
キータブのマウント方法
時刻同期（ホストとコンテナ間）

特にホスト名とDNSの一貫性が重要です。

Q7: このエラーでシステムが完全に使えなくなる?

A: Kerberos認証を必須にしている場合、ログインできなくなる可能性があります。

対策:

ローカルrootアカウントは常に有効にしておく
コンソールアクセス手段を確保
バックアップの認証方式を用意（パスワード認証など）

Q8: プリンシパルを削除して再作成するとどうなる?

A: kvno（キーバージョン番号）がリセットされ、すべての既存キータブが無効になります。

再作成より、change_password -randkeyでキーを更新する方が安全です。

まとめ: Kerberosエラーを確実に解決しよう

「Server not found in Kerberos database」エラーについて解説してきました。最後にポイントをまとめます。

重要ポイント:

エラーの主な原因はプリンシパルの未登録または名前の不一致
ホスト名、レルム名、プリンシパル名の一貫性が重要
kadmin.localでプリンシパルを追加し、キータブをエクスポート
時刻同期とDNS設定も忘れずに確認
testparmのようなテストツール（Kerberosではkinitとklist）を活用
問題を予防するにはドキュメント化と命名規則の統一

Kerberos認証は設定が複雑ですが、一度正しく構築すれば、非常に安全で便利な認証基盤になります。

エラーに遭遇したら、まず落ち着いてプリンシパル名とレルム名を確認することから始めましょう。ほとんどの場合、名前の不一致や未登録が原因です。

この記事の手順に従えば、確実にエラーを解決できるはずです。頑張ってください!

それでは、安全で快適なシステム運用を!

Kerberosとは何か

Kerberos認証の基礎

Kerberosが使われる場面

重要な用語

身近な例で理解しよう

エラーメッセージの意味

よくあるエラーメッセージ

エラーが示している問題

エラーの原因と診断方法

原因1: ホストプリンシパルの未登録

原因2: レルム名の不一致

原因3: プリンシパル名のタイプミス

原因4: キータブファイルの問題

原因5: 時刻のずれ

原因6: DNSの問題

解決方法: ステップバイステップ

解決策1: ホストプリンシパルの追加

解決策2: レルム名の修正

解決策3: ホスト名の確認と修正

解決策4: キータブの再生成

解決策5: 時刻同期の設定

解決策6: DNS設定の修正

Active Directory統合での特有の問題

ADドメイン参加時のエラー

SPNの重複

大文字小文字の問題

予防策とベストプラクティス

予防策1: ドキュメント化

予防策2: 命名規則の統一

予防策3: 自動化スクリプト

予防策4: 監視とアラート

予防策5: 定期的なキータブ更新

予防策6: テスト環境の構築

よくある質問と回答

Q1: kinitは成功するのに、サービスでエラーになる

Q2: Windows ADでは動くのに、Linux KDCで動かない

Q3: エラーログにプリンシパル名が表示されない

Q4: 複数のレルムを使っている場合は?

Q5: キータブを再生成すると、古いチケットは無効になる?

Q6: Docker/Kubernetesでの注意点は?

Q7: このエラーでシステムが完全に使えなくなる?

Q8: プリンシパルを削除して再作成するとどうなる?

まとめ: Kerberosエラーを確実に解決しよう

Youtube

カテゴリー別人気記事

コメント