On 6.11.2015 09:24, Alexander Bokovoy wrote: > On Thu, 05 Nov 2015, [email protected] wrote: >> On Thursday, November 5, 2015 1:54 PM, Rob Crittenden <[email protected]> >> wrote: >>> [email protected] 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 [email protected]: XXXXXXX >>>> mickey> klist >>>> Ticket cache: FILE:/tmp/krb5cc_0 >>>> Default principal: [email protected] >>>> >>>> Valid starting Expires Service principal >>>> 05/16/2015 18:17:00 05/17/2015 18:16:50 >>>> krbtgt/[email protected] >>>> mickey> kinit -k -t /etc/nfs/krb5.keytab >>>> nfs/[email protected] >>>> mickey> klist >>>> Ticket cache: FILE:/tmp/krb5cc_0 >>>> Default principal: nfs/[email protected] >>>> >>>> Valid starting Expires Service principal >>>> 05/16/2015 23:48:14 05/17/2015 23:48:13 >>>> krbtgt/[email protected] >>>> 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? > principal key != valid ticket. With the help of the principal's key you > can get a ticket which is valid for some time. It needs to be renewed > periodically. In case of FreeIPA as KDC the default validity of the > ticket is 24 hours. Kerberos principal keys, on other hand, only expire > if there is a password policy associated with them. For service > principals you create with 'ipa service-add' there is no expiration > associated with the key that is generated with 'ipa-getkeytab' as > keys are generated randomly and long enough to be seen as strong. User > principals have password policy associated with them and expire normally > (90 days is the default password policy expiration time). > > Your workflow should be something like this (using IPA CLI as an example > here): > 1. Create a service with 'ipa service-add' > 2. Associate a key with a service with 'ipa-getkeytab' and store it in a > keytab -- either directly on the server where service is running or on > any other IPA client. > 3. Deliver the keytab from step (2) to a server where it should be if > needed. In case of clustered configuration deliver the keytab to all > cluster nodes which will be operating as the service. > > Do not run 'ipa-getkeytab' multiple times as each run invalidates > previously obtained keytab. > > 4. Use the keytab to kinit and obtain initial ticket granting ticket > (TGT) for the service principal periodically. This either has to be > supported by an application itself or run with a wrapper that kinits > periodically. On RHEL 7, CentOS 7, and Fedora use GSS-PROXY to > perform automatic renewal, this is much cleaner way of doing it. > > If your NAS appliance has issues like below it only says that NFS server > side did not accept your configuration. Thus, you need to look into the > NAS appliance logs to say what is wrong there.
In other words, if $ kinit -k -t /etc/nfs/krb5.keytab nfs/[email protected] is working then the problem is somewhere in appliance config. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
