>> It's much simpler to use a keytab for your service and let Kerberos
>> acquire a TGT automatically. You can either place the keytab in a
>> special location, set the env var KRB5_CLIENT_KTNAME or use GSSProxy to
>> handle the keytab for you. With a client keytab, you don't have to call
>> kinit at all.
> 
> OK, I'd seen references to using keytabs with cron. I'll go down that
> route. Thank you.

I've had a similar situation recently and found that GSSProxy works
nicely for this purpose.

Since I found documentation to be a little scattered: GSSProxy in its
(ipa-)default configuration (on CentOS) looks for client keytabs in
'/var/lib/gssproxy/clients/$EUID.keytab'. Then, whenever a user accesses
a kerberized NFS mount, GSSProxy 'automagically' gets a ticket and saves
that in '/var/lib/gssproxy/clients/krb5cc_$EUID'. All while the keytab
and cache are both inaccessible to the user.

So in the simplest case:

# kinit $user
# ipa-getkeytab -p $user \
 -k /var/lib/gssproxy/clients/$(id -u $user).keytab

.. and then just make sure gssproxy.service is started and the script
runs as that user but don't bother with tickets.

I could not get this to work for system users, i.e. service principals
of the form 'apache/$hostname@$REALM', though. They are able to access
the share but I couldn't figure out how to properly map the username to
enable write access aswell.

- Anton
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to