3

I'm using FreeIPA for LDAP/Kerberos and I've created a principal for a storage appliance (Dell/EMC UnityVSA VM). I have setup the VSA with a keytab from IPA, I've also setup within the VSA the LDAP configuration and created a NAS with support for Kerberized NFS shares. Both IPA and VSA aren't reporting any issues and things look nominally fine there.

From a macOS client (High Sierra), I am able to mount the NFSv4 share when Kerberos on the server is disabled (so the basics work). However when I specify Kerberos for security of that share I am unable to connect ("Permission denied").

The command I am using to mount is:

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

The output is:

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

I am able to get a ticket from the KDC on the client side. The klist command shows the following output after I try to connect to the NFS share, where the second entry is the IPA principal for VSA (storage server).

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>

The /etc/krb5.conf file on my client looks like this:

[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>

As an aside, I cannot get kadmin to work. For instance, the command

kadmin admin@REALM.COM

returns the following output:

kadmin: kadm5_init_with_password: Cannot contact any KDC for requested realm

Any thoughts what I'm missing here? Do I need the krb5.conf file, or should IPA be able to handle everything with service records in DNS?

Update

When I specify AUTH_SYS on the server end that seems to work fine in terms of NFS connectivity as well.

Update 2: WireShark Dump

The below dump shows NFS traffic between the client and NFS server during the mount command above. The first is the client, the second is the server response (continues in pairs below):

Client-NFS-Server traffic during mount

  • First check that your DNS is working. – Michael Hampton Feb 20 at 16:18
  • Basic DNS functionality checks out. Plus, correct me if I'm wrong, but I don't think I would be able to get a ticket from my DC if it weren't... – user3814483 Feb 20 at 16:21
2

Turns out to be a problem with the schema specification on the UnityVSA, so it couldn't do an LDAP search properly; Kerberized NFS works now.

Still don't know why kadmin returns what it does on macOS.

For the record, /etc/krb5.conf (or the equivalent file in /Library/Preferences/...) is not required at all and DNS takes care of all the heavy lifting. No specific crypto configuration required for macOS with IPA, works out of the box.

For future reference, in terms of behavior, even if the Kerberos identity is specified in the macOS Ticket Viewer (with password stored in keychain), one must explicitly request a ticket (if a ticket is not active but the identity is specified, a ticket is not implicitly requested when accessing the NFS share in finder, for example).

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.