[19896] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: About proxy_impersonator

daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Feb 19 17:53:32 2019

To: Weijun Wang <weijun.wang@oracle.com>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <d198d15e-35ea-3c88-f074-9bd34482925f@mit.edu>
Date: Tue, 19 Feb 2019 17:53:23 -0500
MIME-Version: 1.0
In-Reply-To: <BD1C8545-8325-4551-9C7A-A43492A44F3A@oracle.com>
Content-Language: en-US
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

On 2/16/19 2:28 AM, Weijun Wang wrote:
> Suppose there is only one process, is the intermediate server also forbidden to get a ticket to a backend server on its own?

If a caller uses an impersonator credential with gss_init_sec_context(),
the GSSAPI layer will always try to make an S4U2Proxy request, not a
regular TGS request.

The same caller may have previously acquired a cred handle which it used
to produce the impersonator cred (either with gss_accept_sec_context()
or gss_acquire_cred_impersonate_name()).  That cred could be used to get
a ticket to another server with a regular TGS request.

> Is this true for any GSS_C_BOTH credential?

No, the GSS_C_BOTH usage is orthogonal.  Impersonator credentials are
typically GSS_C_INITIATE, and a GSS_C_BOTH credential which is not an
impersonator cred can be used to make regular TGS requests.

_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post