Hi On 22 September 2010 23:37, Greg Hudson <ghud...@mit.edu> wrote: > Apologies that you've had to struggle with this mostly on your own. I > wish I could offer more assistance.
Thanks.. It was a rather painful first encounter with MIT kerberos :) > > 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. I've been able to reproduce the problem on three machines ; one with FreeBSD 7.2, one with FreeBSD 8.1 and one Linux CentOS 5. it was with either mod_auth_kerb 5.3 or 5.4 and MIT krb5 1.8.x. As soon as I used krb5 1.6.x or 1.7.x the GSSAPI error completely disappeared. This is using the default KDC on a Mac OS 10.6 server ; not sure what version they are using there. I have seen the same 000186a3 error with 1.7 ; when I was playing with the encryption type on the mac kdc and somehow none of my clients could log in any more. Not sure on how I could help further ; let me know if there is anything specific you need. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
