Will gss_acquire_cred automatically refresh the cache if credential in KRB5CCNAME file expired? If not, is that a way to force refresh without removing the file?
I am using KRB5 v1.10. -----Original Message----- From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of Xie, Hugh Sent: Monday, October 27, 2014 12:18 PM To: Greg Hudson; <kerberos@mit.edu> Subject: RE: gss_init_sec_context with delegated_cred_handle error Thanks. Setting KRB5_CLIENT_KTNAME and setting KRB5CCNAME to a none default location resolve the issue. -----Original Message----- From: Greg Hudson [mailto:ghud...@mit.edu] Sent: Monday, October 27, 2014 11:21 AM To: Xie, Hugh; <kerberos@mit.edu> Subject: Re: gss_init_sec_context with delegated_cred_handle error 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 > use...@my.domain.com. Currently, I can remedy the situation by running a > 'kinit use...@my.domain.com<mailto:use...@my.domain.com> -t -v $KRB5_KTNAME' > to create a lower case default principal > use...@my.domain.com<mailto:use...@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. ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
