[37363] in Kerberos
Re: Constrained Delegation incurs high rate of TGS exchange
daemon@ATHENA.MIT.EDU (Isaac Boukris)
Sun Dec 27 22:57:23 2015
MIME-Version: 1.0
In-Reply-To: <CAC-fF8TT7VZKa18w_sSV9XBASH1ZauWgqvxrRtYC8tvKPGs3+A@mail.gmail.com>
Date: Mon, 28 Dec 2015 05:57:04 +0200
Message-ID: <CAC-fF8QYJMHnNNJEa1Uc=zL377cMHKqwgV2jrrrLUW+nzwX9RA@mail.gmail.com>
From: Isaac Boukris <iboukris@gmail.com>
To: kerberos <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Hi again,
On Sat, Dec 26, 2015 at 3:47 AM, Isaac Boukris <iboukris@gmail.com> wrote:
> Hello,
>
> I'm trying to use gss_acquire_cred_impersonate_name() followed by
> gss_store_cred_into() to store impersonated creds into a ccache which
> I later use for calling gss_init_sec_context() on behalf of the user.
>
> This works fine (against w2k3) but it seems that each call to
> gss_init_sec_context() incurs a new TGS exchange (on wire) and
> subsequently 'klist' shows additional entries although the target
> server is the same.
> This doesn't happen when I use regular 'kinit' to initialize the
> ccache (rather the first TGS seems to be reused).
>
> I was wondering if this is expected in constrained-delegation scenario
> or whether I might be doing something wrong (tested with 1.12.2 and
> 1.14-pre).
I think I found the bug in 'init_sec_context', when we have
impersonator credentials we don't check first if we have cached
credentials.
Please have a look at PR #381 - it fixes it for me (no high rate of
TGS exchange and no duplicate entries in ccache).
Thanks a lot!
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos