Kerberos troubles

Greg Hudson ghudson at MIT.EDU
Wed Sep 22 09:37:47 EDT 2010


On Tue, 2010-09-21 at 14:48 -0400, Jean-Yves Avenard wrote:
> I have now identified the cause of the issue.
> When using mod_auth_kerb with MIT krb5 v1.6.x it works perfectly
> with krb5 1.7 and 1.7.1 same.
> However, I get this "GSS-API major_status:000d0000,
> minor_status:000186a3" error whenever I use MIT 1.8.x kerberos
> libraries (tested with 1.8.1 and 1.8.3)
> 
> Not sure what can be done from there...

Apologies that you've had to struggle with this mostly on your own.  I
wish I could offer more assistance.

Sadly, the major and minor status codes don't provide much insight.  The
major code is just "failure" and the minor code (100003 in decimal) is a
faked-up error code designed to make mechanism-specific error codes
generic.  The real error code from the failing krb5 operation is trapped
in an error map table.  In theory, it should be displayed in the
parentheses of "Minor code may provide more information (, )", and in
other failure cases you've seen it there, but for unknown reasons, it
isn't appearing properly in this case.

I'd be very interested in finding out what's going wrong here,
especially since this sounds like a regression from krb5 1.7 to 1.8.
Unfortunately, I don't have any bright ideas for debugging this further
without source-level investigation--either attaching to the server
process and stepping through kg_accept_krb5() (using a non-optimized
build of krb5 with debugging symbols), or adding instrumentation to that
function.





More information about the Kerberos mailing list