このセクションでは、Kerberos ソフトウェアに関するトラブルシューティング情報を提供します。
KDC で使用される鍵バージョン番号 (KVNO) と、システム上でホストされるサービスの /etc/krb5/krb5.keytab に格納されているサービス主体鍵が一致しないことがあります。keytab ファイルを新しい鍵で更新せずに KDC 上で新しい鍵セットが作成されると、KVNO が同期しなくなる場合があります。問題を診断したら、krb5.keytab ファイルをリフレッシュしてください。
keytab エントリを一覧表示します。
各主体の KVNO が各エントリ内の最初の項目です。
# klist -k Keytab name: FILE:/etc/krb5/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 host/denver.example.com@EXAMPLE.COM 2 host/denver.example.com@EXAMPLE.COM 2 host/denver.example.com@EXAMPLE.COM 2 nfs/denver.example.com@EXAMPLE.COM 2 nfs/denver.example.com@EXAMPLE.COM 2 nfs/denver.example.com@EXAMPLE.COM 2 nfs/denver.example.com@EXAMPLE.COM
host 鍵を使用して、最初の資格を取得します。
# kinit -k
KDC で使用される KVNO を確認します。
# kvno nfs/denver.example.com nfs/denver.example.com@EXAMPLE.COM: kvno = 3
ここに示されている KVNO は 2 ではなく 3 です。
krb5.conf ファイルが正しくフォーマットされない場合は、次のエラーメッセージが端末ウィンドウに表示されるか、またはログファイルに記録されることがあります。
Improper format of Kerberos configuration file while initializing krb5 library
形式が正しくないと、関連付けられているサービスが攻撃に対して脆弱になることがあります。この問題を修正しないと、Kerberos 機能を使用できません。
Kerberos データベースの伝播が失敗した場合は、スレーブ KDC とマスター KDC の間で、およびマスター KDC からスレーブ KDC サーバーに /usr/bin/rlogin -x を試してみてください。
KDC がデフォルトでセキュアになっている場合、rlogin コマンドは無効になっているため、この問題のトラブルシューティングには使用できません。KDC 上で rlogin を有効にするには、eklogin サービスを有効にする必要があります。
# svcadm enable svc:/network/login:eklogin
問題のトラブルシューティングを完了したら、eklogin サービスを無効にしてください。
# svcadm disable svc:/network/login:eklogin
リモートアクセスが機能しない場合は、KDC 上の keytab ファイルの問題である可能性があります。リモートアクセスが機能する場合、rlogin と伝播ソフトウェアは同じ host/host-name 主体を使用しているため、keytab ファイルやネームサービスの問題ではありません。この場合、kpropd.acl ファイルが正しいことを確認してください。
Kerberos NFS ファイルシステムのマウントに失敗した場合には、NFS サーバーに /var/rcache/root ファイルが存在することを確認してください。ファイルシステムの所有者が root でない場合は、削除してから再度マウントします。
Kerberos NFS ファイルシステムへのアクセスに問題がある場合は、使用するシステムと NFS サーバー上で gssd サービスが有効になっていることを確認してください。
Kerberos NFS ファイルシステムにアクセスしようとしたときに invalid argument または bad directory のどちらかのエラーメッセージが表示される場合は、NFS ファイルシステムをマウントしようとするときに完全修飾 DNS 名を使用していないことが問題である可能性があります。マウントされているホストが、サーバーのキータブファイル内のサービス主体名に含まれるホスト名と一致していません。
また、複数の Ethernet インタフェースを実装したサーバーに DNS を設定するときに、ホスト単位に複数のアドレスレコードを割り当てずに、インタフェース単位に名前を割り当てた場合にも、この問題が発生します。Kerberos サービスの場合は、次のようにホスト単位に複数のアドレスレコードを設定する必要があります Ken Hornstein、「Kerberos FAQ」、[http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#kerbdns]、2010 年 3 月 10 日にアクセス。
my.host.name. A 1.2.3.4 A 1.2.4.4 A 1.2.5.4 my-en0.host.name. A 1.2.3.4 my-en1.host.name. A 1.2.4.4 my-en2.host.name. A 1.2.5.4 4.3.2.1 PTR my.host.name. 4.4.2.1 PTR my.host.name. 4.5.2.1 PTR my.host.name.
この例の設定では、インタフェースごとに 1 つの参照が割り当てられます。また、サーバーのキータブファイル内で、3 つのサービス主体の代わりに、1 つのサービス主体を使用できます。
システム上で root になろうとしたときに認証に失敗したが、root 主体はすでにホストの keytab ファイルに追加している場合は、2 つの領域を調査してください。まず、キータブファイル内の root 主体が、そのインスタンスとして完全指定形式のシステム名であることを確認します。完全指定形式名の場合は、/etc/resolv.conf ファイルを確認して、システムが DNS クライアントとして正しく設定されていることを確認してください。
資格マッピングをモニターするには、最初に、/etc/gss/gsscred.conf ファイルの次の行をコメント解除します。
SYSLOG_UID_MAPPING=yes
次に、gssd サービスで /etc/gss/gsscred.conf ファイルを読み取ります。
# pkill -HUP gssd
これで、gssd によってリクエストされた資格マッピングをモニターできます。syslog.conf ファイルが debug の重要度レベルで auth システム機能用に構成されている場合、これらのマッピングは syslog デーモンによって記録されます。