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 administra...@jupiter.com ->
use...@jupiter.com
Decrypted AP-REQ with server principal HTTP/zeus.jupiter....@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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
