Kerberos Ticket Forwarding patch/update

[Douglas E. Engert]

Love Hörnquist Åstrand wrote:
> Hello allo,
> 
> I would really like to know the behavior of windows, is the the 
> OK_AS_DELEGATE flag that really is used to determine if ticket should be 
> delegated.

http://support.microsoft.com/kb/q266080/
says:
   The Kerberos revisions Internet Draft specifies a new ticket flag -
   "OK as delegate". The Windows 2000 KDC sets this flag in service tickets
   that have the Trusted for delegation account control flag set. If the
   service ticket has the OK as delegate flag set, then the SSPI forwards
   the user's TGT to the service if the SSPI program requested delegation.
   If the ticket flag is not set, then the SSPI delegation flag is ignored
   and the TGT is not forwarded.

So I would read this is the client will only delegate if the client want's to
and the KDC says it is OK.

When using a Kerberos KDC rather the AD, the client ksetup program has the
/SetRealmFlag Delegate  - Everyone in this realm is trusted for delegation
for the case where the KCD has not implemented the OK-AS-DELAGATE flag.


> 
> Or is is that application that thinks it should by setting 
> GSS_C_DELEGATE and the SSPI library that strips is if the OK_AS_DELEGATE 
> isn't set by the KDC on the service ticket.

I believe that is the case, and is how I read the KB article.

> 
> If the user never meant to delegate, samba shouldn't default to.
> 
> Love
> 
> 
> 
> 
> 24 jul 2008 kl. 21.28 skrev Derrick Schommer:
> 
>> Hi,
>>
>>
>>
>> I'm looking to commit a patch for the 3.0 code base and the 3.2 code
>> base to allow samba using Kerberos authentication to work with proxy
>> devices which are set to be "trusted for delegation" in a Windows
>> domain. The update, in clikrb5.c would add detection for tickets with
>> OK_AS_DELEGATE and would then request a forwardable ticket from the KDC
>> and send it along with the krb5_mk_req_extended() function call.
>>
>>
>>
>> This would allow operating systems with Samba 3.x to interoperate with
>> the F5 Acopia ARX product line for storage virtualization along with any
>> other future virtualization vendors. I'm not sure if I send patches to
>> this mailer or not (as this patch is 260 lines long and I have one for
>> 3.0.x and 3.2.x). I'd love for the team to review it and do what would
>> be needed to commit it into the projects.
>>
>>
>>
>> Thanks in advance.
>>
>>
>>
>>
>>
>> Derrick Schommer |  Corporate Systems Engineer
>>
>> F5 Networks
>>
>>  P 978.513.2900
>>
>> F 978.513.2990
>>
>> www.f5.com <http://www.f5.com>
>>
>>  D 978.513.2960
>>
>> M 603.765.0012
>>
>>
>>
>>
>>
>> <image001.gif>
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444