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