KRB5KDC_ERR_ETYPE_NOSUPP in protocol transition
lukeh at padl.com
Wed Jul 29 08:21:34 EDT 2009
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.
# 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.
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
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).
More information about the krbdev