[28117] in Kerberos
Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand
daemon@ATHENA.MIT.EDU (Henry B. Hotz)
Thu Jul 26 14:51:10 2007
In-Reply-To: <200707262028.46879.achim@grolmsnet.de>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <FC9A39B2-B4D1-4CD1-AF82-9537343398DE@jpl.nasa.gov>
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
Date: Thu, 26 Jul 2007 11:40:57 -0700
To: achim@grolmsnet.de
Cc: kerberos@mit.edu, modauthkerb-help@lists.sourceforge.net,
"Douglas E. Engert" <deengert@anl.gov>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Jul 26, 2007, at 11:28 AM, Achim Grolms wrote:
> On Thursday 26 July 2007 20:16, Douglas E. Engert wrote:
>> Achim Grolms wrote:
>
>>> From my point of view that means we can exclude the item
>>> "Client sends nothing as delegated credeatials" because from
>>> my point of view the logging means *something* is received.
>>
>> No, the trace showed that the client obtained a TGT to forward,
>> but did not forward it.
>>
>> reqFlags: 02
>> 0... .... = delegFlag:False
>
> OK, got it.
>
> But I do not understand why on mod_auth_kerb side
> gss_accept_sec_context () sets the GSS_C_DELEG_FLAG
> of ret_flags.
>
> If I understand RFC2744 correct GSS_C_DELEG_FLAG
> would not be set in that case?
>
> Achim
Agreed. That flag shouldn't be set AFAIK, though the value isn't
valid until negotiation is complete.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
