Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-RT-Original-Encoding: iso-8859-1 Content-Length: 3236

Even if gss_init/accept_sec_context reported the actual mechanism it still wouldn’t work.  What I’m seeing is that the top level glue layer is returning fake minor status codes.  What happens is the krb5 function returns an error code, the glue layer which called it calls map_error for that error with the KRB5 mechanism and returns the error code to SPNEGO.  SPNEGO returns the error code.  The top glue layer also calls map_error but this time it calls it for the error with the SPNEGO mechanism.  The mapping function doesn’t find a mapping for the error with SPNEGO but does find one for Kerberos so it makes up a fake error code and returns the fake error code to the caller because error codes are expected to be unique across all mechanisms.  The glue layer for gss_display_status searches the cache of mapped error codes.  It uses the associated mechanism from the cache and ignores the one that was passed in.  The problem with this is that when using SPNEGO you will always pass through the glue layer twice with two different mechanisms with the result that a fake error code will always be returned to the caller.  The concept of fake error codes is fundamentally flawed because they are meaningless to the calling application which therefore cannot respond to them.