[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.