Is KRB5_CONFIG info cached?

Marcus Watts mdw at umich.edu
Thu Jun 29 18:43:28 EDT 2006


Mike Friedman <mikef at ack.berkeley.edu> writes:
> Date: Thu, 29 Jun 2006 14:21:57 -0700 (PDT)
> From: Mike Friedman <mikef at ack.berkeley.edu>
> To: kerberos at mit.edu
> Subject: Is KRB5_CONFIG info cached?
> In-Reply-To: <200606212039.k5LKdYDa013625 at ginger.cmf.nrl.navy.mil>
...
> 
> [I apologize for the length of this, but it's about a problem that is 
> proving to be very inscrutable and it needs some explanation].
> 
> I'm doing some testing of code that authenticates against both an MIT K5 
> KDC and an Active Directory KDC.  I've written a perl subroutine that uses 
> Jeff Horwitz's Authen::Krb5 module, which seems to work fine for 
> individual authentications.
> 
> However, here's my problem.  I need to call my subroutine twice from the 
> same perl script, once pointing to our MIT KDC and the second time 
> pointing to our campus AD KDC.  I control which KDC I'm using by 
> manipulating the 'KRB5_CONFIG' environment variable within my subroutine, 
> based on an argument from the caller that specifies the KDC to use.  And, 
> of course, depending on which KDC it is, I use a keytab file that was 
> generated on the appropriate KDC.
...

As long as the KDCs are in different realms, you ought to be able
to use one context, and one KRB5_CONFIG file, to access both.  It
doesn't matter if you normally use SRV records; if you put
explicit host information in your config file, kerberos will use
that; if you set [libdefaults] dns_fallback = false, you can
forbid it from even thinking about looking at DNS.
The kerberos server will not know or care whether you found it
via DNS or a config file.

As it happens, I've been using Jeff's code for some other stuff.

So, at a closer look at Jeff Horwitz's code, looks like he
expects Authen::Krb5::init_context().  He's got this
right before:
	if (context) croak("Authen::Krb5 already initialized");

So the first call you make to Authen::Krb5::init_context() will pick
up whatever's currently in KRB5_CONFIG, and you can't be making any
subsequent calls to that unless you're catching and discarding the
ensuing croak.  If you want to have fun, you can probably call
	Authen::Krb5::krb5_free_context();
but that won't buy you anything unless you edit Krb5.xs and
add a "context = 0" after the krb5_free_context call.

				-Marcus Watts



More information about the Kerberos mailing list