Petr Grolmus <i...@civ.zcu.cz> writes:
> sorry for the delay due to Easter..
Not a problem -- sorry it took me so long to reply. I was out for a while
on vacation that was unexpectedly extended.
>> Presumably you also have $WEBKDC_PRINCIPAL set. Could you have a
>> KRB5CCNAME environment variable set for the Apache process? If so,
>> it's going to call add_proxy_token instead of add_remuser_token. My
>> guess is that's what's happening.
> Nope, I've no $WEBKDC_PRINCIPAL set. In 3.7.1 this works fine without
> $WEBKDC_PRINCIPAL. Our webkdc.conf (without czech commentary) is
> attached. WebKDC principal is set only in module configuration thru the
> keytab.
> Well, I'm not sure if it calls add_proxy_token instead of
> add_remuser_token. At the begining of add_proxy_token there is a
> print STDERR "adding a proxy token for $ENV{REMOTE_USER}\n";
> # if $self->param ('debug');
> Even if I commented out the condition of debug mode (which is set ON in my
> environment), this print is not shown in log - see attached log.log file.
> It seems to me that neither add_proxy_token nor add_remuser_token is
> used in 4.x version... Is it possible?
I'm not sure. Well, it must be possible, since that seems to be what's
happening. :) But I'm not sure what would cause it.
Here is the relevant code:
# If WebKDC::Config::REMUSER_ENABLED is set to a true value, see if we
# have a ticket cache. If so, obtain a proxy token in advance.
# Otherwise, cobble up a proxy token using the value of REMOTE_USER and
# add it to the request. This allows the WebKDC to trust Apache
# authentication mechanisms like SPNEGO or client-side certificates if so
# configured. Either way, pass the REMOTE_USER into the WebKDC for
# logging purposes.
if ($ENV{REMOTE_USER} && $WebKDC::Config::REMUSER_ENABLED) {
if ($ENV{KRB5CCNAME} && $WebKDC::Config::WEBKDC_PRINCIPAL) {
$self->add_proxy_token;
} else {
$self->add_remuser_token;
}
}
So if the REMOTE_USER environment variable is set and REMUSER_ENABLED is
set in your configuration, one or the other of those methods should always
be called.
In your Apache access log, I'm not seeing anything in the authenticated
identity field. REMOTE_USER is generally logged there. Could something
be broken in the Apache configuration that causes REMOTE_USER to not be
set or client-side certificate authentication to not be performed?
Can you add a debugging warn statement to see if REMOTE_USER is set and
what it's set to in login.fcgi when it's invoked?
--
Russ Allbery <ea...@windlord.stanford.edu>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University
