Note that this can have strange interactions with NFS4; some implementations will use the first ccache they find in what they believe to be the ccache directory which is owned by the right uid, and when that ticket expires NFS operations will fail. How you deal with this depends on the NFS4 implementation. :/
-----Original Message----- From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of Ben Gooley Sent: Thursday, December 17, 2015 11:07 AM To: Rainer Krienke <krie...@uni-koblenz.de> Cc: kerberos@mit.edu Subject: Re: Problem with /tmp/krb5cc_%uid cache file name oops... that sent prematurely. I was going to add that for the cron scripts, you would want to make the cache file unique (perhaps with a timestamp appended). Ben On Thu, Dec 17, 2015 at 8:05 AM, Ben Gooley <bgoo...@cloudera.com> wrote: > Rainer, > > We have a KB article that will likely help: > > Scripting Against a Kerberos Enabled Cluster > <https://na29.salesforce.com/articles/KB_Article/Scripting-Against-a-K > erberos-Enabled-Cluster?popup=true&id=kA080000000PLhN> > > On Thu, Dec 17, 2015 at 5:47 AM, Rainer Krienke > <krie...@uni-koblenz.de> > wrote: > >> Hello, >> >> a while ago I set up NFS4/Kerberos in our network. So all NFS mounts >> are done via NFS4. We are using MIT kerberos 5. In krb5.conf I >> configured the credential cache file as: >> >> default_ccache_name = /tmp/krb5cc_%{uid} >> >> Now basically this setup works. However I have one problem that is >> related to the cron-Principal and the default_ccache_name value. >> >> Each user in my setup has a principal username@KRBREALM, for nfs >> access there is an additional nfs/<fqdn>@KRBREALM principal. Users >> wanting to run cron jobs have a username/cron@KRBREALM principal and >> a local keytabfile on the cron host to which the cron principal was exported. >> >> Now when a user logs in on the cron host a /tmp/krb5cc_<%uid> file is >> created with a default principal of username@KRBREALM. It contains >> the krbtgt service principal as well as nfs/<fqdn> service principals. >> >> Next a cron job of this user starts. For this purpose the user >> prepends its real cron job with a call like >> >> kinit -k -t /etc/cronkeytabs/usercron.keytab username/cron@KRBREALM >> >> And since default_ccache_name is set to /tmp/krb5cc_%{uid} and the >> uid of this user is always the same the file /tmp/krb5cc_<%uid> is >> overwritten now containing the cron default principal. The user >> default principal that was in there before is deleted. And since we >> see NFS problems once a week on this host my guess is that this >> overwriting of credential cache files might be the origin. >> >> What I would like to have is either a way to *add* a cron service >> principal to a possibly existing /tmp/krb5cc_%{uid} file with the >> default user principal or to use a different default_ccache_name for >> cron with something like: >> >> default_ccache_name = /tmp/krb5cc_{%service} >> >> however there is no %service parameter expansion available. >> >> Any idea how to solve this name-conflict? >> >> Thanks for your help >> Rainer >> -- >> Rainer Krienke, Uni Koblenz, Rechenzentrum, A22, Universitaetsstrasse >> 1 >> 56070 Koblenz, Tel: +49261287 1312 Fax +49261287 100 1312 >> Web: http://userpages.uni-koblenz.de/~krienke >> PGP: http://userpages.uni-koblenz.de/~krienke/mypgp.html >> >> >> ________________________________________________ >> Kerberos mailing list Kerberos@mit.edu >> https://mailman.mit.edu/mailman/listinfo/kerberos >> >> > > > -- > Ben Gooley > *Customer Operations Engineer* > > > * <http://www.cloudera.com>* > -- Ben Gooley *Customer Operations Engineer* * <http://www.cloudera.com>* ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
