KRB5KDC_ERR_ETYPE_NOSUPP in protocol transition

[Luke Howard]

On 29/07/2009, at 6:23 AM, Nikhil Mishra wrote:

> Thanks Luke. I will take a look at the branch.

Again, please accept my apologies for the duplication of effort. I've  
just checked in some changes to get S4U2Proxy to work. You can test  
both S4U2Self and S4U2Proxy using the kvno tool, which now accepts two  
new arguments: -U user and -P.

For example:

# kvno -k krb5.keytab -U delegtest at de.padl.com@DE.PADL.COM -P host/WIN-EQ7E4AA2WR8.DE.PADL.COM at DE.PADL.COM

will use S4U2Self to acquire a ticket from delegtest to the ccache  
principal, and then use S4U2Proxy to acquire a ticket from delegtest  
to host/WIN-EQ7E4AA2WR8.DE.PADL.COM. You need to specify a keytab for  
S4U2Proxy, so that the ticket can be decrypted.

There are also two new exported APIs that can be used from GSS-API  
applications. (I will write this up on the Kerberos projects Wiki  
soon, I promise.) I don't propose to export the krb5 equivalents.

gss_krb5_create_sec_context_for_principal() synthesises an acceptor- 
side security context for an arbitrary principal principal. (There's  
probably a better name for this.) verifier_cred_handle must be both an  
initiator- and acceptor-side credentials handle, because a TGT is  
required to perform S4U2Self.

OM_uint32
gss_krb5_create_sec_context_for_principal(OM_uint32 *minor_status,
	gss_ctx_id_t *context_handle,
	gss_cred_id_t verifier_cred_handle,
	gss_name_t principal,
	OM_uint32 req_flags,
	OM_uint32 time_req,
	gss_name_t *src_name,
	gss_OID *mech_type,
	OM_uint32 *ret_flags,
	OM_uint32 *time_ret,
	gss_cred_id_t *delegated_cred_handle);

gss_krb5_add_sec_context_delegatee() creates or updates a skeleton  
context that can be passed to gss_accept_sec_context(), such that  
delegated_cred_handle will contain credentials for delegating to the  
specified principals.

OM_uint32
gss_krb5_add_sec_context_delegatee(OM_uint32 *minor_status,
	gss_ctx_id_t *context_handle,
	gss_name_t name);

That way, the existing GSS-API delegation model is maintained; the  
only difference is that you don't get a TGT, instead you get a  
credentials handle with a set of service tickets.

As for your specific issue, might be worth either contacting Larry Zhu  
directly or posting on the MS protocol forum (the URL which I don't  
have to hand right now).

-- Luke