Warum erhalte ich beim Mounten einer kerberisierten NFS-Freigabe die Fehlermeldung „Kein Cache für Anmeldeinformationen“?

Warum erhalte ich beim Mounten einer kerberisierten NFS-Freigabe die Fehlermeldung „Kein Cache für Anmeldeinformationen“?

Ich habe zwei Systeme in einem lokalen Netzwerk, nfsclient (CentOS 7) und nfsserver (CentOS 6). Diese Namen werden korrekt in ihre IP-Adressen aufgelöst und Kerberos funktioniert zwischen ihnen (nfsserver ist der KDC). Ich habe eine Kerberized NFSv4-Freigabe auf nfsserver exportiert; meine /etc/exports ist wie folgt:

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

Ich kann diese Exporte von nfsclient sehen:

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

Wenn ich die Optionen sec=krb5p in /etc/exports entferne, kann ich die Freigabe von nfsclient aus mounten mit

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

Wenn NFS jedoch kerberisiert ist, läuft es nicht so gut:

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

Dies wird von einer Reihe wiederholter Fehlermeldungen in /var/log/messages begleitet:

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

In den Protokollen auf dem Server wird nichts angezeigt. Wenn ich klist auf dem Client ausführe, wird angezeigt, dass root einen Anmeldeinformationscache unter /tmp/krb5cc_0 hat. Daher gehe ich davon aus, dass ein Problem mit gss-proxy vorliegt.

/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

Daher muss gss-proxy nach dem Anmeldeinformationscache in /var/lib/gssproxy/clients suchen. Es ruft auch Schlüssel aus /etc/krb5.keytab ab (das Schlüssel für die Principals nfs/nfsclient und host/nfsclient enthält). Allerdings scheint /var/lib/gssproxy/clients auf nfsclient immer leer zu sein.

Übersehe ich hier etwas? Ich kann nicht genau herausfinden, was beim Mounten dieser Freigabe schief läuft.

Antwort1

Es gibt ein Problem mit der Standarddateikonfiguration beim Definieren des Cachepfads. Versuchen Sie es mit dieser Konfiguration des Clients in /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

Antwort2

Stellen Sie sicher, dass Ihr Client der Domäne beigetreten ist.

ipa-client-install --force-join

Dann besorgen Sie sich ein Ticket

kinit admin

und überprüfen Sie dann noch einmal die krb5.keytab

restorecon -v /etc/krb5.keytab

Stellen Sie sicher, dass Ihr Client im Keytab ist

kinit -k

host/ < client > . < domain > @REALM

Sie sollten dann in der Lage sein, mitsec=krb5p

verwandte Informationen