On Thu, 05 Nov 2015, j...@use.startmail.com wrote:
On Thursday, November 5, 2015 1:54 PM, Rob Crittenden <rcrit...@redhat.com> 
wrote:
j...@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 ad...@corp.example.org: XXXXXXX
mickey> klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ad...@corp.example.org

Valid starting       Expires              Service principal
05/16/2015 18:17:00  05/17/2015 18:16:50
krbtgt/corp.example....@corp.example.org
mickey> kinit -k -t /etc/nfs/krb5.keytab
nfs/mickey.corp.example....@corp.example.org
mickey> klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: nfs/mickey.corp.example....@corp.example.org

Valid starting       Expires              Service principal
05/16/2015 23:48:14  05/17/2015 23:48:13
krbtgt/corp.example....@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?
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.
--
/ Alexander Bokovoy

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

Reply via email to