Kerberos constrained delegation

[suneetha Nadella]

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 <ghudson at 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 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
>



-- 
Regards,
Suneetha Nadella