[krbdev.mit.edu #8586] Need better diagnostics for S4U2Proxy after S4U2Self yields non-forwardable ticket

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[krbdev.mit.edu #8586] Need better diagnostics for S4U2Proxy after S4U2Self yields non-forwardable ticket

Greg Hudson via RT
gss_acquire_cred_impersonate_name() performs an S4U2Self request,
which may yield either a forwardable ticket (if the impersonator has
the ok-to-auth-as-delegate permission or equivalent) or a non-
forwardable ticket.  If the resulting ticket is forwardable, the
result of gss_acquire_cred_impersonate_name() is a proxy credential;
otherwise, it is a regular cred containing only the service ticket to
the impersonator (and no TGT).

If the application expects to receive a proxy cred and calls
gss_init_sec_context() to authenticate to a target service, but
instead holds a regular cred, the operation will fail (the regular
cred can only uthenticate to the impersonator), and the reason for the
failure is not obvious from either the error message or the trace
logs.  A knowledgeable reader of the trace logs can see that only one
credential is stored in the MEMORY ccache during the
gss_acquire_cred_impersonate_name() operation, but there is no
explicit indication that GSS is producing a regular cred instead of a
proxy cred.

_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs