Is KRB5_CONFIG info cached?

Mike Friedman mikef at ack.Berkeley.EDU
Thu Jun 29 17:21:57 EDT 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[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.

When I do this, I find that the second call fails, apparently because I 
wind up connecting to the wrong KDC.  If I call the MIT KDC first, 
authentication succeeds;  then the second call (to the AD KDC) gives this 
message (from get_in_tkt_with_password):

    Cannot resolve network address for KDC in requested realm

I can see in the MIT KDC logs that the first authentication did, in fact, 
succeed.  And, although I don't have access to the AD KDC logs, my code 
displays the realm being used and it is, indeed, that of the AD KDC.

If I call the AD KDC first, then authentication succeeds, but the second 
call (to the MIT KDC) gives this message (also from 
get_in_tkt_with_password):

    Server not found in Kerberos database

I believe that both symptoms are consistent with my connecting to the 
wrong KDC;  i.e., the second call still tries to connect to the KDC of the 
first call.

However, my code also displays the name of the krb5.conf file being used 
and it's always correct!  I obtain this value by doing a 'echo 
$KRB5_CONFIG' in my subroutine, so presumably that really does reflect the 
environment at the time the subroutine is run.  Also, I give my 
credentials cache a name containing the PID, so I can also see that both 
calls are taking place within the same process (as I'd expect, since it's 
all one perl script).

So, on the one hand, it would seem that the environment variable is being 
set correctly.  Yet, the evidence is that I'm connecting to the same KDC 
both times (but, of course, the second call is using the wrong keytab 
file).

I should also say that if I make both calls to the same KDC, I get two 
good authentications.  Also, if I enter the wrong password, I can tell 
from the failure responses which KDC I'm talking to, because AD always 
returns 'preauth failed', while MIT KDC returns 'Decrypt integrity check 
failed'.

Any ideas about this?  Is there any way to force connection to a specific 
KDC other than using the 'KRB5_CONFIG' environment variable?  (We don't 
use SRV records here, so that's not an option even if it would help in 
this case).

Thanks.

Mike

_________________________________________________________________________
Mike Friedman                        System and Network Security
mikef at ack.Berkeley.EDU               2484 Shattuck Avenue
1-510-642-1410                       University of California at Berkeley
http://socrates.berkeley.edu/~mikef  http://security.berkeley.edu
_________________________________________________________________________

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBRKREeK0bf1iNr4mCEQIjKACeL3BEqaFR3k8usHioA48asc6MWfQAoPKW
vSoJ0SHlHFAofbBA3Vi7A33i
=iTHL
-----END PGP SIGNATURE-----



More information about the Kerberos mailing list