Thanks Greg. It worked when I provided only usercd entry in default keytab file.
On Wed, Feb 5, 2014 at 12:39 AM, Greg Hudson <ghud...@mit.edu> wrote: > 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 > -- Regards, Suneetha Nadella ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
