![Warum erhalte ich beim Mounten einer kerberisierten NFS-Freigabe die Fehlermeldung „Kein Cache für Anmeldeinformationen“?](https://rvso.com/image/89157/Warum%20erhalte%20ich%20beim%20Mounten%20einer%20kerberisierten%20NFS-Freigabe%20die%20Fehlermeldung%20%E2%80%9EKein%20Cache%20f%C3%BCr%20Anmeldeinformationen%E2%80%9C%3F.png)
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