[Freeipa-users] problems with NFS service principal

[jcnt at use.startmail.com]

On Thursday, November 5, 2015 1:54 PM, Rob Crittenden <rcritten at redhat.com> wrote:
> jcnt at use.startmail.com wrote:
>> Hello everyone,
>>
>> I initially followed freeipa NFS documentation for setting up external
>> stand alone NFS server
>>
>> ipa host-add mickey.corp.example.org
>> ipa service-add nfs/mickey.corp.example.org
>> ipa-getkeytab -s razoul.corp.example.org -p nfs/mickey.corp.example.org
>> -k /tmp/nfs.keytab
>>
>> uploaded keytab to NFS server and all appeared to work just fine:
>>
>> mickey> export KRB5_CONFIG=/etc/nfs/krb5.conf
> 
> Why are you using a custom krb5.conf?
NFS server is a network appliance. It automatically creates /etc/nfs/krb5.conf based on nfs keytab provided.

> 
>> mickey> kinit admin
>> Password for admin at CORP.EXAMPLE.ORG: XXXXXXX
>> mickey> klist
>> Ticket cache: FILE:/tmp/krb5cc_0
>> Default principal: admin at CORP.EXAMPLE.ORG
>>
>> Valid starting       Expires              Service principal
>> 05/16/2015 18:17:00  05/17/2015 18:16:50 
>> krbtgt/CORP.EXAMPLE.ORG at CORP.EXAMPLE.ORG
>> mickey> kinit -k -t /etc/nfs/krb5.keytab
>> nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG
>> mickey> klist
>> Ticket cache: FILE:/tmp/krb5cc_0
>> Default principal: nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG
>>
>> Valid starting       Expires              Service principal
>> 05/16/2015 23:48:14  05/17/2015 23:48:13 
>> krbtgt/CORP.EXAMPLE.ORG at CORP.EXAMPLE.ORG
>> mickey>
>>
>> However, I learned hard way (NFS stopped working) that ipa-getkeytab
>> issues ticket with a default timeout of 3 months.
> 
> keytabs don't time out. What made you think it has a 3-month validity
> period?
Well, network appliance tech support told me that "authentication key being expired".
Are you saying that keytab should never need to be updated on NFS server?

>>
>> I repeated ipa-getkeytab and got:
>>
>> mickey> kinit -k -t /etc/nfs/krb5.keytab
>> kinit: Keytab contains no suitable keys for
>> host/mickey.corp.example.org at CORP.EXAMPLE.ORG while getting initial
>> credentials
>> mickey> klist -k -t /etc/nfs/krb5.keytab
>> Keytab name: FILE:/etc/nfs/krb5.keytab
>> KVNO Timestamp           Principal
>> ---- -------------------
>> ------------------------------------------------------
>>   5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG
>>   5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG
>>   5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG
>>   5 11/03/2015 10:50:10 nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG
> 
> You used the right command earlier:
> 
> # kinit -k -t /etc/nfs/krb5.keytab
> nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG
Opps, found the problem, at least on kinit part, principal should be specified on command line:
#kinit -k -t /etc/nfs/krb5.keytab \
nfs/mickey.corp.example.org at CORP.EXAMPLE.ORG
#

> 
>> When client tries to mount:
>>
>> # mount -vvv -o sec=krb5 mickey:/volume1/homes /mnt
>> mount.nfs: timeout set for Thu Nov  5 11:41:39 2015
>> mount.nfs: trying text-based options
>> 'sec=krb5,vers=4,addr=192.168.26.2,clientaddr=192.168.26.31'
>> mount.nfs: mount(2): Invalid argument
>> mount.nfs: an incorrect mount option was specified
>>
>> Not much information available...
>>
>> Any NFS experts out here?
> 
> The NFS server may have more info.

That is a network appliance, I'll have to try to manually add debug options to NFS components.

But client is an IPA domain member, kerberos logins are working just fine - is it sufficient to conclude that host is in good shape?

Thanks you.
Josh.