Fix client code for S4U2Self with certificate

During realm identification, don't send the certificate in the AS
request if we have an enterprise name, for consistency with the
Windows LSA API behavior.  If we are using just a certificate, use the
appropriate client principal name type with a single empty data
component.

krb5int_process_tgs_reply() needs to see an S4U2Self padata type in
in_padata to apply the correct logic when verifying the client
principal in the reply.  If we are using only a certificate, we
currently do not pass any in_padata (because we do not send
PA-FOR-USER in this case, and the PA-S4U-X509-USER is constructed via
a callback).  Change the code to place an empty PA-S4U-X509-USER in
in_padata, to be modified by the callback; that way we can reliably
detect the S4U2Self case when processing the reply.

In krb5_get_self_cred_from_kdc(), when constructing an empty client
principal for a cert-only S4U2Self request, properly terminate the
krb5_build_principal_ext() argument list to avoid a crash.  Don't
bother setting the name type as it isn't sent.

Only send the certificate in the first TGS-REQ to the client realm.
To the intermediate and final realms, send the principal name only.
Use the checksum-protected principal name in the first KDC's
PA-S4U-X509-USER response for subsequent requests and to verify the
unprotected client name in the final reply.

After receiving the final reply, check if we had cached credentials
under the discovered client name (unless it's the same as the input
client name) and return the cached credentials if we find them.

[ghudson@mit.edu: squashed commits; rewrote commit message]

ticket: 8777

0 files changed, 0 insertions, 0 deletions