Incorrect delegation state shown on acceptor side by context flags

Vipul Mehta vipulmehta.1989 at
Mon May 20 06:20:36 EDT 2013

One more question, what is the exact use of context delegation flag if it
doesn't need to be same on initiator and acceptor side.

On Fri, May 17, 2013 at 9:54 PM, Vipul Mehta <vipulmehta.1989 at>wrote:

> On Fri, May 17, 2013 at 8:31 PM, Greg Hudson <ghudson at> wrote:
>> The GSSAPI doesn't distinguish between different kinds of credential
>> delegation.  But if you use GSS_C_ACCEPT rather than GSS_C_BOTH acceptor
>> credentials, then constrained delegation won't be used, and you will be
>> able to tell whether traditional Kerberos ticket forwarding was used.
>> In my case it is like acceptor can use delegated credentials or its own
> credential for initiation on the basis of certain conditions, so GSS_C_BOTH
> is required. Now there seems to be no way to check whether client has
> delegated the credential or not.
>> > What about the java implementation of GSS ? Looks like there it works
>> fine.
>> Does it support constrained delegation?  If it doesn't, then the
>> behavior difference isn't surprising.
>> As far as i know about constrained delegation is that only a set of
> acceptors are allowed to use the delegated credential within the domain. No
> idea if this feature is supported by java, may be it is not. Would it be
> too much if you can add a condition that context delegation flag on
> acceptor side should not be set if client hasn't delegated the credential ?
> It seem to be logical too, in the implementation, this flag is set only if
> acceptor can acquire valid delegated credential.
> --
> Regards,
> Vipul


More information about the Kerberos mailing list