gss_init_sec_context with delegated_cred_handle error

[Greg Hudson]

On 10/23/2014 11:38 AM, Xie, Hugh wrote:
> When I pass GSS_C_NO_CREDENTIAL as cred_handle to gss_init_sec_context(), I got no error. But when I pass delegated_cred_handle (output from gss_accept_sec_context) as cred_handle to gss_init_sec_context(), I got 'Matching credential not found' error. It seems that when passing delegated_cred_handle gss_init_sec_context care about ticket cache. In my case the default principal in the ticket cache was upper case USERID at MY.DOMAIN.COM. Currently, I can remedy the situation by running a 'kinit userid at MY.DOMAIN.COM<mailto:userid at MY.DOMAIN.COM> -t -v $KRB5_KTNAME' to create a lower case default principal userid at MY.DOMAIN.COM<mailto:userid at MY.DOMAIN.COM>.

>From your previous question on October 6, I assume you are using
S4U2Proxy using the client's service ticket, not traditional Kerberos
credential delegation.

> 1.      Why gss_init_sec_context care about ticket cache default principal when using delegated_cred_handle? Why it works when I am not delegating?

S4U2Proxy requires your TGT to operate.  You have to send a TGS request
to the KDC, from yourself to the target service, with the client's
service ticket presented as an "evidence ticket," in order to get a
credential from the client to the target service.

The principal in the ccache must match the principal in the keytab used
to decrypt the ticket.  (It does not matter what principal the client
used to get the service ticket; that field is not protected in the
AP-REQ exchange and could be an alias anyway, so we ignore it.)

> 2.      Is there a better approach to remedy this problem other than kinit since the ticket cache could expire overtime, I am running a web service that could stop working if it expires? Is there a code based solution?

You should be able to use a client keytab to get credentials.  Make sure
KRB5CCNAME points to a location which won't be disturbed by other uses,
and set KRB5_CLIENT_KTNAME to point to a keytab containing your key as
the first entry.  gss_acquire_cred will automatically get credentials
using the keytab, and that TGT will be used for S4U2Proxy.

> I think the delegated_cred_handle output from gss_accept_sec_context, has principal in lower case. When delegated_cred_handle passed to gss_init_sec_context the default principal of the krbtgt is in upper case causing the "Matching credential not found" error. Can I report this as a bug?

I think we need better diagnostics for this as it has come up at least
once before.  But the fact that it doesn't work is not necessarily a
bug.  MIT krb5 generally follows the original architecture of Kerberos
in treating principals as case-sensitive, unlike Microsoft's
implementation which treats them as case-insensitive.

I will file an issue about the lack of appropriate diagnostics.