Kerberos Ticket Forwarding patch/update

Thu Jul 24 23:27:21 GMT 2008


> Maybe the client don't want to authenticate to that service, you are forcing
> it upon them to always delegate, even for services which they don't need to
> delegate too.
> 
I¹m not sure I follow... If a user goes to //proxy.example.com/share01 they
would have to authenticate with a forwardable ticket, otherwise they¹ll be
declined access to the back-end storage and not be able to make a successful
kerberos connection. True, if, for some reason, a random server joined to a
windows domain had ³Trust for delegation² set, the client would send two
tickets when only one was needed, but that would be an odd configuration.
You¹re saying the client would have to be forced to say ³I¹d like to be able
to received tickets if this host is trusted for delegation²? If so, that¹s
not the standard MS Windows behavior, as there is no place to turn on/off a
client side trust relationship that I¹ve seen.
> 
> To test the behaivor you need to use SSPI directly and test the behavior of
> the windows SSPI Kerberos interface.
> 
You mean connect to the proxy via Windows kerberos?


Derrick
> 
> 
> 
> 24 jul 2008 kl. 23.55 skrev Derrick Schommer:
> 
>>    
>>  
>>  I¹m not sure how Microsoft handles it internally, what I do know is if the
>> client doesn¹t Œwant¹ to delegate, than they¹re going to be declined the
>> ability to authenticate because the server is virtualizing the back-end
>> storage. You cannot authenticate directly with the virtualized system without
>> using a management address. The client wouldn¹t gain any advantage from not
>> allowing the delegated trust.
>>  
>>  What I do know is Microsoft automatically sends the second ticket to the
>> Acopia ARX when the device has been trusted for delegation, there has never
>> been a case where this isn¹t true. The minute you disable trust for
>> delegation you¹ll see the security blog is half as large (since it¹s missing
>> a ticket). Given the data is encrypted it¹s not really easy to know what¹s
>> going on under the hood.
>>  
>>  
>>  Derrick
>>  
>>  On 7/24/08 6:27 PM, "Love Hörnquist Åstrand" <lha at kth.se> wrote:
>>  
>>  
>>> Hello,
>>>  
>>>  That the computer it "trusted for delegation" doesn't mean that the
>>>  user want to delegate.
>>>  
>>>  The reason I'm asking is that when I asked msft about this, they said
>>>  they only delegated if GSS_C_DELGATE_FLAG and ok-as-delegate was set.
>>>  ok-as-delegate alone was not a critera alone for delegation. I want to
>>>  know if its true.
>>>  
>>>  If its true, and the user never sets GSS_C_DELEGATE_FLAG, samba
>>>  shouldn't delegate.
>>>  
>>>  Love
>>>  
>>>  
>>>  
>>>  24 jul 2008 kl. 23.03 skrev Derrick Schommer:
>>>  
>>>>  > The OK_AS_DELEGATE is set when the ticket is granted based on a
>>>>  > computer account being told, on the domain controller, "trusted for
>>>>  > delegation"
>>>>  >
>>>>  > In those cases, we want to forward on the second ticket for that
>>>>  > system so that it can negotiate with the back-end storage that it's
>>>>  > virtualizing.
>>>>  >
>>>>  > Derrick
>>>>  >
>>>>  > -----Original Message-----
>>>>  > From: Love Hörnquist Åstrand [mailto:lha at kth.se]
>>>>  > Sent: Thursday, July 24, 2008 17:53
>>>>  > To: Derrick Schommer
>>>>  > Cc: samba-technical at lists.samba.org
>>>>  > Subject: Re: Kerberos Ticket Forwarding patch/update
>>>>  >
>>>>  > 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.
>>>>  >
>>>>  > 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.
>>>>  >
>>>>  > 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>  <http://www.f5.com>
>>>>>  >>
>>>>>  >> D 978.513.2960
>>>>>  >>
>>>>>  >> M 603.765.0012
>>>>>  >>
>>>>>  >>
>>>>>  >>
>>>>>  >>
>>>>>  >>
>>>>>  >> <image001.gif>
>>>>  >
>>>  
>>>  
>>>  
>>  
>>   
> 
>