[35741] in Kerberos
Re: Kerberos constrained delegation
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Feb 4 14:09:48 2014
Message-ID: <52F13AED.5060307@mit.edu>
Date: Tue, 04 Feb 2014 14:09:33 -0500
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: suneetha Nadella <nsuneetha@gmail.com>
In-Reply-To: <CABx3ADvMdPuB7EJdg7t8VUgNX26wLz_98gQkvMaFD3G_Pfj_MA@mail.gmail.com>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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@JUPITER.COM ->
usercd@JUPITER.COM
Decrypted AP-REQ with server principal HTTP/zeus.jupiter.com@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
