Question about krb5_rd_req

Mike Friedman mikef at ack.Berkeley.EDU
Wed Jun 21 12:37:17 EDT 2006


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

I've been testing authentication code that is intended to work with an 
Active Directory KDC, as well as with an MIT K5 KDC, and which uses the 
MIT K5 libraries. This is 'proxy auth', where I do the AS_REQ and also 
process the AP_REQ in the same code, using a keytab file.

[Everything that follows applies when using krb5-1.3.4 and krb5-1.4.2].

As it happens, the keytabs that were generated for me by the AD folks were 
based on the wrong password for the service principals, so, naturally, the 
rd_req failed.  However, I found the particular symptoms interesting and 
wonder if this is intentional or an inadvertent by-product of the MIT 
library logic.

If I call krb5_rd_req specifying NULL for the server principal, then the 
error message I get is 'Bad encryption type while decoding authenticator' 
(RC=188).  But if I specify the server principal in krb5_rd_req, then I 
get this error:  'Decrypt integrity check failed' (RC=31).

[Both forms of the call to krb5_rd_req work fine when the keytabs are OK].

We've now got our keytabs corrected, but I'm still curious about the 
different error messages for the same keytabs, depending (it appears) only 
on whether a server principal is supplied in the call to krb5_rd_req. Is 
this discrepancy intended?  Right now, it's just curiosity on my part.

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://ack.Berkeley.EDU/~mikef  http://security.berkeley.edu
_____________________________________________________________________

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

iQA/AwUBRJl1wK0bf1iNr4mCEQI3JQCfRWenbDFxwvgks8tcEfaIdO7qTpwAmwdp
WjIkIu+u379rmTCZg8RqgvfK
=iJ16
-----END PGP SIGNATURE-----



More information about the Kerberos mailing list