Anton Semjonov <> 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:

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.


Attachment: signature.asc
Description: PGP signature

FreeIPA-users mailing list --
To unsubscribe send an email to

Reply via email to