On 6.11.2015 09:24, Alexander Bokovoy wrote:
> 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.

In other words, if

$ kinit -k -t /etc/nfs/krb5.keytab

is working then the problem is somewhere in appliance config.

Petr^2 Spacek

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to