KRB5 context is not updated when starting a new Apache session (using mod_auth_kerb)

[Guus Leeuw jr.]

Hi,

looking at OpenLDAP and KRB5, the question really boils down to:
Why do you want to rebind through OpenLDAP in case mod_auth_kerb has already
got the ticket in the first place?

OpenLDAP's ldapsearch has an option -Y GSSAPI which acts pretty much like -x,
but uses the kerberos ticket that is already there. Normally you'd do
something similar in PHP (and extend PHP in case something similar is not
available). From the top of my head, I don't think that OpenLDAP is re-binding
in the case of -Y GSSAPI, so they must call something similar that,
presumably, is available in the LDAP API. I'm not sure how standard -Y GSSAPI
is, though.

Ultimately, using Kerberos, you'd want your user to log in *once* and make
sure that LDAP can re-use the ticket. Why else bother with kerberos based
authentication in the first place ;)

On another note, did you look at PHP's LDAP Connection caching, making sure
that that doesn't screw up the bill?

Just my 2 cents,
Guus

On Wed, May 30, 2007 07:56, gil ran wrote:
> Hi.
>
>
> I am using a Linux-From-Scratch based Linux, with OpenLdap-2.3.27,
> Heimdal-0.7.2, Apache-httpd-2.2.4, mod_auth_kerb-5.3 and php-5.2.1.
>
>
> I'm trying to use OpenLDAP (over Heimdal GSSAPI with KRB5) from
> mod_php under Apache (using php's ldap_sasl_bind with GSSAPI as mechanism - it
> calls lsap_sasl_interactive_bind_s). Apache is configured to re-use processes
> for handling multiple sessions (mpm_workers_module with MaxRequestsPerChild of
> 0). The first time my
> code runs inside any given httpd process it works OK. After that it always
> fails with credentials error, which points to non-existing credentials file
> from the previous time.
>
> After some digging I discovered that the problem is due to KRB5CCNAME
> evironment variable changes. When a process is re-used by Apache, it first
> invokes mob_auth_kerb which authenticates and sets KRB5CCNAME environment
> variable. The problem is that GSSAPI already has an existing KRB5 context
> (from the previous time) which already has
> default_cc_name. KRB5 does not re-read the environment variable and stays with
> incorrect credentials file name.
>
> It looks as if GSSAPI is not designed to be invoked from process
> handling multiple sessions, because it does not have either of: 1) A way to
> re-initialize the default credentials file if the environment changes 2) A ways
> to destory underlying KRB5 context after the work is completed by the previous
> session.
>
> I have an ugly hackish solution that solves my problem:
> In Heimdal's KRB5 cache.cc: krb5_cc_default_name() I've changed
>
>
> <    if (context->default_cc_name == NULL)
> <	    krb5_cc_set_default_name(context, NULL);
>
>
> To:
>
>
>> if ((context->default_cc_name == NULL) || strcmp(context->default_cc_name,
>> getenv("KRB5CCNAME"))) krb5_cc_set_default_name(context, NULL);
>
> Which always checks the environment variables whenever default name is
> required.
>
> Another solution would be to modify mod_auth_kerb, to update GSSAPI
> KRB5 context when "KRB5CCNAME" is changed. This also looks extremely
> ugly to me. I didn't try to do that, but it should solve the problem.
>
> Yet another solution is to configure Apache to kill each process after
> handling 1 request. This is extremely undesirable, and will cause other
> problems for me.
>
> What would be the proper solution for this?
>
>
> Thanks,
> Gil Ran.
>
>
>