Anton Semjonov <redhat(a)semjonov.de> writes:
>> 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.
Our source and docs live here these days:
https://pagure.io/gssproxy
Happy to have suggestions for improvement!
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.
This doesn't seem like a gssproxy problem, though we're happy to fix it
if it is.
Thanks,
--Robbie