Kerberos Ticket Forwarding patch/update

View: New views
20 Messages — Rating Filter:   Alert me  

Kerberos Ticket Forwarding patch/update

by Derrick Schommer-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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 (6K) Download Attachment

Re: Kerberos Ticket Forwarding patch/update

by Jeremy Allison :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Thu, Jul 24, 2008 at 04:28:26PM -0400, Derrick Schommer wrote:

> 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.

Send the patch *as an attachement* as a diff -u change to
samba-technical@....

Label the patches as the 3.0.x version and the 3.2.x version
and send them separately. I'd love to review them, thanks !

Jeremy.

Re: Kerberos Ticket Forwarding patch/update

by Love Hörnquist Åstrand :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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>
>
>  D 978.513.2960
>
> M 603.765.0012
>
>
>
>
>
> <image001.gif>


RE: Kerberos Ticket Forwarding patch/update

by Derrick Schommer-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...]
Sent: Thursday, July 24, 2008 17:53
To: Derrick Schommer
Cc: samba-technical@...
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>
>
>  D 978.513.2960
>
> M 603.765.0012
>
>
>
>
>
> <image001.gif>


Re: Kerberos Ticket Forwarding patch/update

by Love Hörnquist Åstrand :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...]
> Sent: Thursday, July 24, 2008 17:53
> To: Derrick Schommer
> Cc: samba-technical@...
> 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>
>>
>> D 978.513.2960
>>
>> M 603.765.0012
>>
>>
>>
>>
>>
>> <image001.gif>
>


Re: Kerberos Ticket Forwarding patch/update

by Derrick Schommer-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


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@...> 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@...]
>> > Sent: Thursday, July 24, 2008 17:53
>> > To: Derrick Schommer
>> > Cc: samba-technical@...
>> > 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>
>>> >>
>>> >> D 978.513.2960
>>> >>
>>> >> M 603.765.0012
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> <image001.gif>
>> >
>
>


Re: Kerberos Ticket Forwarding patch/update

by Love Hörnquist Åstrand :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello Derrick,

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.

To test the behaivor you need to use SSPI directly and test the  
behavior of the windows SSPI Kerberos interface.

Love



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@...> 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@...]
>> > Sent: Thursday, July 24, 2008 17:53
>> > To: Derrick Schommer
>> > Cc: samba-technical@...
>> > 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>
>> >>
>> >> D 978.513.2960
>> >>
>> >> M 603.765.0012
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> <image001.gif>
>> >
>>
>>


Re: Kerberos Ticket Forwarding patch/update

by Derrick Schommer-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



> 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@...> 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@...]
>>>>  > Sent: Thursday, July 24, 2008 17:53
>>>>  > To: Derrick Schommer
>>>>  > Cc: samba-technical@...
>>>>  > 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>
>>>>  >
>>>  
>>>  
>>>  
>>  
>>  
>
>


Re: Kerberos Ticket Forwarding patch/update

by Andrew Bartlett :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Thu, 2008-07-24 at 23:27 +0100, Love Hörnquist Åstrand 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.
The problem here is that if it's up to the user (ie, as a command line
option), then none of this useful delegation stuff ever happens, and we
end up giving hosts the right to make up arbitrary tickets, not just
accept forwarded ones.  I actually agree with Microsoft here, and the
delegation should be controlled by the KDC.

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.


signature.asc (196 bytes) Download Attachment

Re: Kerberos Ticket Forwarding patch/update

by Derrick Schommer-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Yes, from my experience with everything from XP to Vista Business, we've
never found a client who's had any ability to control how the flow of
kerberos authentication works while running through virtualized storage,
because this would be a nightmare for helpdesks.

If a client could disable the ability to use delegated proxy authentication
user error would result from the authentication error and helpdesk calls
would be the next step :)

Derrick


On 7/24/08 10:02 PM, "Andrew Bartlett" <abartlet@...> wrote:

> On Thu, 2008-07-24 at 23:27 +0100, Love Hörnquist Åstrand 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.
>
> The problem here is that if it's up to the user (ie, as a command line
> option), then none of this useful delegation stuff ever happens, and we
> end up giving hosts the right to make up arbitrary tickets, not just
> accept forwarded ones.  I actually agree with Microsoft here, and the
> delegation should be controlled by the KDC.
>
> Andrew Bartlett


Re: Kerberos Ticket Forwarding patch/update

by Love Hörnquist Åstrand :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


25 jul 2008 kl. 03.02 skrev Andrew Bartlett:

> On Thu, 2008-07-24 at 23:27 +0100, Love Hörnquist Åstrand 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.
>
> The problem here is that if it's up to the user (ie, as a command line
> option), then none of this useful delegation stuff ever happens, and  
> we
> end up giving hosts the right to make up arbitrary tickets, not just
> accept forwarded ones.  I actually agree with Microsoft here, and the
> delegation should be controlled by the KDC.

So do I

commit 9bdd4ef9a69775475fbd7468fd42edc14107ecc8
Author: lha <lha@ec53bebd-3082-4978-b11e-865c3cabbd6b>
Date:   Wed Nov 2 11:52:49 2005 +0000

     Change sematics of ok-as-delegate to match windows if
     [gssapi]realm/ok-as-delegate=true is set, otherwise keep old  
sematics.


     git-svn-id: svn+ssh://svn.h5l.org/svn/heimdal/trunk/heimdal@16283  
ec53bebd-3082-4978-b11e-865c3cabbd6b


What I'm asking for is samba to honor the GSS_C_DELEGATE_FLAG.  
Probably it should be default set to on for SMB.


Love






Re: Kerberos Ticket Forwarding patch/update

by Andrew Bartlett :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, 2008-07-25 at 08:27 +0100, Love Hörnquist Åstrand wrote:

> 25 jul 2008 kl. 03.02 skrev Andrew Bartlett:
>
> > On Thu, 2008-07-24 at 23:27 +0100, Love Hörnquist Åstrand 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.
> >
> > The problem here is that if it's up to the user (ie, as a command line
> > option), then none of this useful delegation stuff ever happens, and  
> > we
> > end up giving hosts the right to make up arbitrary tickets, not just
> > accept forwarded ones.  I actually agree with Microsoft here, and the
> > delegation should be controlled by the KDC.
>
> So do I
>
> commit 9bdd4ef9a69775475fbd7468fd42edc14107ecc8
> Author: lha <lha@ec53bebd-3082-4978-b11e-865c3cabbd6b>
> Date:   Wed Nov 2 11:52:49 2005 +0000
>
>      Change sematics of ok-as-delegate to match windows if
>      [gssapi]realm/ok-as-delegate=true is set, otherwise keep old  
> sematics.
>
>
>      git-svn-id: svn+ssh://svn.h5l.org/svn/heimdal/trunk/heimdal@16283  
> ec53bebd-3082-4978-b11e-865c3cabbd6b
>
>
> What I'm asking for is samba to honor the GSS_C_DELEGATE_FLAG.  
> Probably it should be default set to on for SMB.
Here Samba is the application, not the library (well, I suppose it is
the library for libsmbclient, but we don't give those callers this level
of control), so it is reasonable to have it on by default.  A config
option might be appropriate, but we already have config-itis...

Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.


signature.asc (196 bytes) Download Attachment

RE: Kerberos Ticket Forwarding patch/update

by Derrick Schommer-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

So, should I submit the diffs with GSS_C_DELEGATE_FLAG?

If so, where is this in the 3.0 tree? I'm seeing a gss_init_sec_context() in libsmb/clifsinfo.c in the 3.2 tree but in the 3.0 tree I only can find this call in sasl.c

Any ideas?

Derrick

-----Original Message-----
From: Love Hörnquist Åstrand [mailto:lha@...]
Sent: Friday, July 25, 2008 03:27
To: Andrew Bartlett
Cc: Derrick Schommer; samba-technical@...
Subject: Re: Kerberos Ticket Forwarding patch/update


25 jul 2008 kl. 03.02 skrev Andrew Bartlett:

> On Thu, 2008-07-24 at 23:27 +0100, Love Hörnquist Åstrand 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.
>
> The problem here is that if it's up to the user (ie, as a command line
> option), then none of this useful delegation stuff ever happens, and  
> we
> end up giving hosts the right to make up arbitrary tickets, not just
> accept forwarded ones.  I actually agree with Microsoft here, and the
> delegation should be controlled by the KDC.

So do I

commit 9bdd4ef9a69775475fbd7468fd42edc14107ecc8
Author: lha <lha@ec53bebd-3082-4978-b11e-865c3cabbd6b>
Date:   Wed Nov 2 11:52:49 2005 +0000

     Change sematics of ok-as-delegate to match windows if
     [gssapi]realm/ok-as-delegate=true is set, otherwise keep old  
sematics.


     git-svn-id: svn+ssh://svn.h5l.org/svn/heimdal/trunk/heimdal@16283  
ec53bebd-3082-4978-b11e-865c3cabbd6b


What I'm asking for is samba to honor the GSS_C_DELEGATE_FLAG.  
Probably it should be default set to on for SMB.


Love






Re: Kerberos Ticket Forwarding patch/update

by Scott Lovenberg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Andrew Bartlett wrote:

> On Fri, 2008-07-25 at 08:27 +0100, Love Hörnquist Åstrand wrote:
>  
>> 25 jul 2008 kl. 03.02 skrev Andrew Bartlett:
>>
>>    
>>> On Thu, 2008-07-24 at 23:27 +0100, Love Hörnquist Åstrand 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.
>>>>        
>>> The problem here is that if it's up to the user (ie, as a command line
>>> option), then none of this useful delegation stuff ever happens, and  
>>> we
>>> end up giving hosts the right to make up arbitrary tickets, not just
>>> accept forwarded ones.  I actually agree with Microsoft here, and the
>>> delegation should be controlled by the KDC.
>>>      
>> So do I
>>
>> commit 9bdd4ef9a69775475fbd7468fd42edc14107ecc8
>> Author: lha <lha@ec53bebd-3082-4978-b11e-865c3cabbd6b>
>> Date:   Wed Nov 2 11:52:49 2005 +0000
>>
>>      Change sematics of ok-as-delegate to match windows if
>>      [gssapi]realm/ok-as-delegate=true is set, otherwise keep old  
>> sematics.
>>
>>
>>      git-svn-id: svn+ssh://svn.h5l.org/svn/heimdal/trunk/heimdal@16283  
>> ec53bebd-3082-4978-b11e-865c3cabbd6b
>>
>>
>> What I'm asking for is samba to honor the GSS_C_DELEGATE_FLAG.  
>> Probably it should be default set to on for SMB.
>>    
>
> Here Samba is the application, not the library (well, I suppose it is
> the library for libsmbclient, but we don't give those callers this level
> of control), so it is reasonable to have it on by default.  A config
> option might be appropriate, but we already have config-itis...
>
> Andrew Bartlett
>  
FWIW, I didn't find the configure options for Samba4 to be over the top
at all.  Considering the scope of the project, and the number of
interfacing options, the ./configure --help=recursive was surprisingly
short, IMHO.  Furthermore when I consider that most were cases of "we'll
use it if we can find it".

That's actually one of the things I was just talking to a friend about
last night, the number of compile time options for most Linux apps.  You
can go big and include the kitchen sink, only link the libraries needed
to run the bare minimum or anything in between.  Then again, I don't
maintain any binary packages and I could see where this would be a
headache for upstream packagers.  Just my $0.02.

Re: Kerberos Ticket Forwarding patch/update

by Michael B Allen :: Rate this Message: