Kerberos 化された NFS 共有をマウントするときに「資格情報キャッシュがありません」というエラーが発生するのはなぜですか?

Kerberos 化された NFS 共有をマウントするときに「資格情報キャッシュがありません」というエラーが発生するのはなぜですか?

ローカル ネットワーク上に nfsclient (CentOS 7) と nfsserver (CentOS 6) という 2 つのシステムがあります。これらの名前は IP アドレスに正しく解決され、Kerberos がそれらの間で動作しています (nfsserver は KDC)。nfsserver にエクスポートされた Kerberized NFSv4 共有があり、/etc/exports は次のようになります。

/export                 *(rw,sync,fsid=0,no_subtree_check,sec=krb5p)                   
/export/home            *(rw,sync,no_subtree_check,no_root_squash,sec=krb5p)

nfsclient から次のエクスポートを確認できます。

[root@nfsclient ~]# showmount -e nfsserver
Export list for nfsserver:
/export/home *
/export      *

/etc/exportsのsec=krb5pオプションを削除すると、nfsclientから共有をマウントできます。

[root@nfsclient ~]# mount -t nfs4 nfsserver:/ /mnt/nfs

しかし、NFS が Kerberos 化されると、状況はうまくいきません。

[root@nfsclient ~]# mount -t nfs4 -o sec=krb5p nfsserver:/ /mnt/nfs
mount.nfs4: access denied by server while mounting nfsserver:/

これには、/var/log/messages に一連のエラー メッセージが繰り返し表示されます。

Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more information, No credentials cache found

サーバーのログには何も表示されません。クライアントで klist を実行すると、ルートが /tmp/krb5cc_0 に資格情報キャッシュを持っていることが示されるため、gss-proxy に問題があると考えられます。

/etc/gssproxy/gssproxy.conf:

[gssproxy]

[service/HTTP]
  mechs = krb5
  cred_store = keytab:/etc/gssproxy/http.keytab
  cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
  euid = 48

[service/nfs-server]
  mechs = krb5
  socket = /run/gssproxy.sock
  cred_store = keytab:/etc/krb5.keytab
  trusted = yes
  kernel_nfsd = yes
  euid = 0

[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0

したがって、gss-proxy は /var/lib/gssproxy/clients 内の資格情報キャッシュを検索する必要があります。また、/etc/krb5.keytab (プリンシパル nfs/nfsclient および host/nfsclient のキーを含む) からキーを取得します。ただし、nfsclient では /var/lib/gssproxy/clients は常に空のようです。

何か見落としているのでしょうか? この共有をマウントする際に何が問題なのか正確にはわかりません。

答え1

キャッシュのパスを定義する際のデフォルトのファイル設定に問題があります。次のクライアント設定を試してください/etc/gssproxy/gssproxy.conf:

[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/tmp/krb5cc_%U
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0
  debug = true

答え2

クライアントがドメインに参加していることを確認してください。

ipa-client-install --force-join

チケットを持っていることを確認してください

kinit admin

そしてkrb5.keytabを再確認する

restorecon -v /etc/krb5.keytab

クライアントがキータブにあることを確認する

kinit -k

host/ < client > . < domain > @REALM

そうすれば、sec=krb5p

関連情報