[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] 6.7.18 problem: Kerberos authentication issues post-upgrade

> So again, there still seems to be some kind of credentical 
> cache problem.
To add to this:

I have just installed 6.7.18 today in a fresh pool (not an upgrade), and
am experiencing what I think are similar/related problems.  I'm
authenticating against a Win2K3 domain (hence my general delight at the
release of 6.7.18 which is linked against much more modern kerberos libs
making this generally possible)   

I'm using kerberos authentication all around:


And after some messing around, I managed to get my AD principals and
keytabs in order.  So, I can start condor ok, and with D_SECURITY on,
everything seems to be in order.  If I login as a general Kerberos user
(miskellc for e.g.), I can run condor_status and such without problems.
At this point, /tmp contains the condor kerberos credentials, but they
have uid of 0 in the filename.
-rw-------    1 condor   condor       2524 Mar 30 14:50 /tmp/krb5cc_0
Condor will continue to mostly work up until I do something condory as
root (e.g. condor_status).  The root commands will work (condor_status
will show me appropriate responses), as will any other user initiated
actions, but any condor->condor communications are now broken
(condor_off for example).  At this point, the krb credentials in /tmp
are now owned by root:
-rw-------    1 root     root         2524 Mar 30 14:51 /tmp/krb5cc_0

Which I think is the root problem.  If I manually kill condor then
restart, it will not start properly (unable to authenticate interdaemon
communication) until I kdestroy the credentials in /tmp.  

I reckon either:
a) condor shouldn't be writing the credential cache and should just be
running off of /etc/krb5.keytab (which is where it gets initial
credentials from anyway), or
b) condor should be creating this credential cache with the uid of the
condor user, not uid 0 (e.g. /tmp/krb5cc_<condoruid>). 

Of course, it could still be something else, and there might be a nice
workaround (I think there are KRB_* environment variables that can be
set to determine where credentials are cached, but I haven't used them

Hope this helps finding a fix,

Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.