Anton Semjonov <red...@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
Description: PGP signature
_______________________________________________ FreeIPA-users mailing list -- firstname.lastname@example.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org