Kerberos constrained delegation

[Greg Hudson]

On 02/04/2014 06:54 AM, suneetha Nadella wrote:
> Enabled trace.. Logs attached. Looks like its looking into wrong memory
> block??

The mailing list server stripped your attachment, so I got it but the
list didn't; that's probably fine.

It's expected that there are two different MEMORY ccaches involved,
because of the init_accept_sec_context function in t_s4u, delegates the
S4U2Self result.  Normally that doesn't do much besides exercise some
code.  However, in your test case it goes somewhat awry:

    Creating authenticator for administrator at JUPITER.COM ->
usercd at JUPITER.COM
    Decrypted AP-REQ with server principal HTTP/zeus.jupiter.com at JUPITER.COM

It appears that usercd and HTTP/zeus.jupiter.com both have entries in
the keytab, both have the same key, and HTTP/zeus.jupiter.com appears
first.  Due to the loose way we decrypt AP-REQs (because of
http://k5wiki.kerberos.org/wiki/Projects/Aliases), we treat the ticket
as if it were a ticket for administrator -> HTTP/zeus obtained via a
service alias, and store it in the mememory ccache with the HTTP/zeus
server name.  When we later go looking for the evidence ticket in
gss_init_sec_context, we look for it under the name administrator ->
usercd and don't find it.

I would t_s4u to work if you do any of the following:

* Use different keys for usercd and HTTP/zeus
* Use separate keytabs for usercd and HTTP/zeus
* Put usercd first in the keytab