3 votes

macOS High Sierra rencontre des problèmes pour monter des partages NFSv4 Kerberisés

J'utilise FreeIPA pour LDAP/Kerberos et j'ai créé un principal pour une appliance de stockage (Dell/EMC UnityVSA VM). J'ai configuré le VSA avec un keytab d'IPA, j'ai également configuré la configuration LDAP dans le VSA et créé un NAS avec un support pour les partages NFS Kerberisés. L'IPA et le VSA ne signalent aucun problème et tout semble aller pour le mieux.

À partir d'un client macOS (High Sierra), je suis en mesure de monter le partage NFSv4 lorsque Kerberos est désactivé sur le serveur (les principes de base fonctionnent donc). Cependant, lorsque je spécifie Kerberos pour la sécurité de ce partage, je ne peux pas me connecter ("Permission refusée").

La commande que j'utilise pour monter est :

sudo mount_nfs -vv -o sec=krb5,vers=4 <storage-server>:/test ~/test

La sortie est :

mount <storage-server>:/test on /Users/<user>/test
mount flags: 0x0
socket: type:any,nomntudp
file system locations:
/test
  <storage-server>
    inet <ip of storage server>
NFS options:     fg,retrycnt=1,vers=4,hard,nointr,noresvport,conn,callback,negnamecache,nonamedattr,acl,noaclonly,nocallumnt,locks,quota,rsize=32768,wsize=32768,readahead=16,dsize=32768,nordirplus,nodumbtimr,timeo=10,retrans=10,maxgroups=16,acregmin=5,acregmax=60,acdirmin=5,acdirmax=60,deadtimeout=0,nomutejukebox,noephemeral,nonfc,sec=krb5
mount_nfs: can't mount /test from <storage-server> onto <mount-point>:    Permission denied

Je suis capable d'obtenir un ticket du KDC du côté client. Le site klist montre la sortie suivante après que j'ai essayé de me connecter au partage NFS, où la deuxième entrée est le principal IPA pour VSA (serveur de stockage).

Credentials cache: API:A2FC2CF2-BA23-CE06-BC50-D5CA1180C946
        Principal: admin@<REALM>

  Issued                Expires               Principal
Feb 20 21:13:07 2019  Feb 21 21:12:46 2019  krbtgt/<REALM>@<REALM>
Feb 20 21:18:12 2019  Feb 21 21:12:46 2019  nfs/<storage-server>.<domain>@<REALM>

Le fichier /etc/krb5.conf sur mon client ressemble à ceci :

[libdefaults]
 default_realm = <REALM>
 dns_lookup_realm = false
 dns_lookup_kdc = true
 rdns = false
 ticket_lifetime = 24h
 forwardable = true
 udp_preference_limit = 0
 default_ccache_name = KEYRING:persistent:%{uid}

[realms]
 <REALM> = {
  kdc = tcp/<FQDN of IPA>
  admin_server = tcp/<FQDN of IPA>
}

[domain_realm]
 .<domain> = <REALM>
 <domain> = <REALM>
 <FQDN of IPA> = <REALM>
 <FQDN of storage-server> = <REALM>

En passant, je ne peux pas obtenir kadmin pour fonctionner. Par exemple, la commande

kadmin admin@REALM.COM

renvoie la sortie suivante :

kadmin: kadm5_init_with_password: Cannot contact any KDC for requested realm

Une idée de ce que j'ai raté ? Ai-je besoin du fichier krb5.conf, ou l'API devrait-il être capable de tout gérer avec les enregistrements de service dans le DNS ?

更新情報

Lorsque je spécifie AUTH_SYS du côté du serveur qui semble fonctionner correctement en termes de connectivité NFS également.

Mise à jour 2 : Dump WireShark

Le dump ci-dessous montre le trafic NFS entre le client et le serveur NFS pendant la commande mount ci-dessus. Le premier est le client, le second est la réponse du serveur (continue par paires ci-dessous) :

Client-NFS-Server traffic during mount

2voto

Tom Marthenal Points 558

Il s'est avéré qu'il y avait un problème avec la spécification du schéma sur l'UnityVSA, et qu'il ne pouvait pas faire une recherche LDAP correctement ; NFS Kerberisé fonctionne maintenant.

Je ne sais toujours pas pourquoi kadmin renvoie ce qu'il fait sur macOS.

Pour mémoire, /etc/krb5.conf (ou le fichier équivalent dans /Library/Preferences/... ) n'est pas du tout nécessaire et DNS s'occupe de tout le travail. Aucune configuration cryptographique spécifique n'est requise pour macOS avec IPA, elle est prête à l'emploi.

Pour référence future, en termes de comportement, même si l'identité Kerberos est spécifiée dans le macOS Ticket Viewer (avec le mot de passe stocké dans le trousseau), on doit explicitement demander un ticket (si un ticket n'est pas actif mais que l'identité est spécifiée, un ticket n'est pas implicitement demandé lors de l'accès au partage NFS dans le finder, par exemple).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X