Difference between revisions of "Samba4 Port: NTLM thread"

Latest revision as of 11:17, 2 September 2009

From:    Andrew Bartlett <abartlet@samba.org>
Date:    1 September 2009 11:25:56 PM
To:      Luke Howard <lukeh@padl.com>
Subject: Re: NTLM

On Tue, 2009-09-01 at 19:52 +0200, Luke Howard wrote:
> Are you using Heimdal's NTLM implementation in Samba 4?
> Do you provide your own "struct ntlm_server_interface"?

Not yet.  (and at this stage I think I would prefer to pase 
the NTLM blobs in Samba, but perhaps either use Heimdal's 
bulk sign/seal code, or provide the whole mech).

Andrew Bartlett

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

===================================================
From:    Luke Howard <lukeh@padl.com>
To:      Andrew Bartlett <abartlet@samba.org>
Subject: Re: NTLM
Date:    Wed, 2 Sep 2009 00:50:31 +0200
Cc:      Don Davis <dodavis@redhat.com>, 
         Stephen C Buckley <sbuckley@mit.edu>

[expanding cc list]


On Tue, 2009-09-01 at 19:52 +0200, Luke Howard wrote:
>> Are you using Heimdal's NTLM implementation in Samba 4?
>> Do you provide your own "struct ntlm_server_interface"?

On 01/09/2009, at 11:25 PM, Andrew Bartlett wrote:
> Not yet.  (and at this sage I think I would prefer to pass
> the NTLM blobs in Samba, but perhaps either use Heimdal's
> bulk sign/seal code, or provide the whole mech).

Something where you gss_import_sec_context() a context emitted by  
Samba, and use Heimdal for sign/seal? When you say "provide the whole  
mech" do you mean Samba or Heimdal provide the whole mech?

Is your desire for NTLM in GSS so that OpenLDAP / FDS can work with  
NTLM? Or are you moving gensec towards GSS? Or have I misunderstood  
you? :-)

cheers,

-- Luke
===================================================
Subject: Re: NTLM
From:    Andrew Bartlett <abartlet@samba.org>
To:      Luke Howard <lukeh@padl.com>
Cc:      Don Davis <dodavis@redhat.com>,
         Stephen C Buckley <sbuckley@mit.edu>,
         Love Hornquist Astrand <lha@kth.se>,
         Günther Deschner <gd@samba.org>
Date:    Wed, 02 Sep 2009 12:49:05 +1000

>> [expanding cc list]
[expanding further] :-)

Luke: Are you using Heimdal's NTLM implementation in Samba 4?
Luke: Do you provide your own "struct ntlm_server_interface"?

Andrew: Not yet.  (and at this sage I think I would prefer to pass
Andrew: the NTLM blobs in Samba, but perhaps either use Heimdal's  
Andrew: bulk sign/seal code, or provide the whole mech).

Luke: Something where you gss_import_sec_context() a context  
Luke: emitted by Samba, and use Heimdal for sign/seal? 

That's one idea.  Or providing 'credentials' that tells Heimdal
to pass whole blobs (not the NTLM challenge/response + username)
to Samba to parse and validate.  

Luke: When you say "provide the whole mech" do you 
Luke: mean Samba or Heimdal provide the whole mech?

I wondered if, as there is a renewed interest in 
'NTLMSSP done right' from GD, that we might provide 
a full mechglue mechansim to be loaded from Heimdal. 

Luke: Is your desire for NTLM in GSS so that OpenLDAP / FDS  
Luke: can work with NTLM? Or are you moving gensec towards  
Luke: GSS? Or have I misunderstood you? :-)

I have a number of conflicting desires for NTLM:

 - An 'NTLM done right' that other clients/servers could use. 
   Pointing folks at Heimdal's NTLM lib might mean they abandon 
   poorly written libs that assume unicide is ASCII+\0. 
 - The ability to use Heimdal's SPNEGO code.  SPGNEGO is very 
   tied to Kerberos, particularly for the new actually secure
   version.  Samba has to get at quite a bit of info from
   GSSAPI to try (and often fail) to do SPENGO externally 
   from the GSS lib. 
 - The thought that we could offload NTLM onto an external 
   crypto lib, that just works.
 - The need to ensure that NTLM is done really well, as it is 
   the fallback security mechanism. Samba has a good record of 
   this in the past.
 - The need to integrate any solution with Samba's NTLM auth 
   subsystem and Samba4's credentials context. 
 - The need to support 'security=server' style MITM attacks 
   for the CIFS proxy.
 - The desire to rid the world of this horrible protocol. 
   But also the need to potentially support the less secure
   variants despite this. 

Andrew Bartlett

-- Andrew Bartlett                      http://samba.org/~abartlet/ 
   Authentication Developer, Samba Team http://samba.org 
   Samba Developer, Cisco Inc. 
===============================================================
Subject: Re: NTLM
From:    Love Hornquist Astrand <lha@kth.se>
To:      Andrew Bartlett <abartlet@samba.org>
Date:    Tue, 1 Sep 2009 22:15:47 -0700
Cc:      Luke Howard <lukeh@padl.com>, 
         Don Davis <dodavis@redhat.com>,
         Stephen C Buckley <sbuckley@mit.edu>, 
         Günther Deschner <gd@samba.org>

Andrew: That's one idea.  Or providing 'credentials' that tells
Andrew: Heimdal to pass whole blobs (not the NTLM challenge/
Andrew: response + username) to Samba to parse and validate.

So I prefer moving the NTLM parsing to somewhere in Heimdal
code, and just use something like NetrLogonSamLogonEx() for 
the backend auth, since that already exists for Windows with 
pass-through mode and Open Directory (Mac OS X server and 
client).

Luke: When you say "provide the whole mech" do you 
Luke: mean Samba or Heimdal provide the whole mech?

Andrew: I wondered if, as there is a renewed interest in
Andrew: 'NTLMSSP done right' from GD, that we might provide
Andrew: a full mechglue mechansim to be loaded from Heimdal.

I'll eventually have a complete NTLMSSP, at least one to
support smb and related protocols. What I have today talks 
to smbclient and and apple smb

Luke: Is it your desire for NTLM in GSS that OpenLDAP / FDS can
Luke: work with NTLM? Or are you moving gensec towards GSS?
Luke: Or have I misunderstood you? :-)

Andrew: I have a number of conflicting desires for NTLM:
Andrew: - An 'NTLM done right' that other clients/servers could use.
Andrew:   Pointing folks at Heimdal's NTLM lib might mean they
Andrew:   abandon poorly written libs that assume unicide is ASCII+\0.

Yeah, not really done with that yet, always the fun with that
backend unicode library.

One more missing thing: format of NTLM exported name.

Andrew: - The ability to use Heimdal's SPNEGO code.  SPGNEGO is
Andrew:   very tied to Kerberos, particularly for the new actually
Andrew:   secure version.  Samba has to get at quite a bit of info
Andrew:   from GSSAPI to try (and often fail) to do SPENGO externally
Andrew:   from the GSS lib.

yay.

Andrew: - The thought that we could offload NTLM onto
Andrew:   an external crypto lib,that just works.

I get the NTLMv1 crypto right today, the NTLMv2 is not there,
but I have not had a reason to fix it yet.

Andrew: - The need to ensure that NTLM is done really well, as it
Andrew:   is the fallback security mechanism. Samba has a good 
Andrew:   record of this in the past.
Andrew: - The need to integrate any solution with Samba's NTLM 
Andrew:   auth subsystem and Samba4's credentials context.

If you support NetrLogonSamLogonEx() you should be fine for the
server, for the client I have a credcache manager that's based
on KCM.

Andrew: - The need to support 'security=server' style MITM attacks
Andrew:   for the CIFSproxy.
Andrew: - The desire to rid the world of this horrible protocol. 
Andrew:   But also the need to potentially support the less secure
Andrew:   variants despite this.

When I talked to Larry [Zhu] in Stockholm, we kind of agreed
that PK-U2U in password mode would do it if there is a local
kerberos database on the windows clients. I guess we should
follow this up.

Love
==================================================================
From:    Luke Howard <lukeh@padl.com>
To:      Love Hornquist Astrand <lha@kth.se>
Subject: Re: NTLM
Date:    Wed, 2 Sep 2009 07:58:47 +0200
Cc:      Andrew Bartlett <abartlet@samba.org>,
         Don Davis <dodavis@redhat.com>,
         Stephen C Buckley <sbuckley@mit.edu>, 
         Günther Deschner <gd@samba.org>

Love: So I prefer moving the NTLM parsing to somewhere in Heimdal 
Love: code, and just use something like NetrLogonSamLogonEx() for
Love: the backend auth since that already exist for windows with
Love: pass-through mode and Open Directory (Mac OS X server and
Love: client).

You're going to implement NetrLogonSamLogonEx() in Heimdal?
Or leave that to Samba?

-- Luke
===================================================================
Subject: Re: NTLM
From:    Love Hornquist Astrand <lha@kth.se>
To:      Andrew Bartlett <abartlet@samba.org>
Date:    Tue, 1 Sep 2009 23:06:30 -0700
Cc:      Luke Howard <lukeh@padl.com>, 
         Don Davis <dodavis@redhat.com>,
         Stephen C Buckley <sbuckley@mit.edu>, 
         Günther Deschner <gd@samba.org>

Luke: You're going to implement NetrLogonSamLogonEx() 
Luke: in Heimdal? Or leave that to Samba?

The heimdal equivalent (but more secure :) is the digest server 
interface.

It's more secure since the server doesn't get to choose the 
nonce (thus can't do a replay on another server's packets). 
This is important since the heimdal digest protocol supports
ticket delegation as a side effect.

I've got a version which is pretty much just like
NetrLogonSamLogonEx() though.

Love
=================================================================
From:    Luke Howard <lukeh@padl.com>
To:      Love Hornquist Astrand <lha@kth.se>
Subject: Re: NTLM
Date:    Wed, 2 Sep 2009 08:15:46 +0200
Cc:      Andrew Bartlett <abartlet@samba.org>,
         Don Davis <dodavis@redhat.com>,
         Stephen C Buckley <sbuckley@mit.edu>, 
         Günther Deschner <gd@samba.org>

Love: The heimdal equivalent (but more secure :) is the digest
Love: server interface.
Love: It's more secure since the server doesn't get to choose the
Love: nonce (thus can't do a replay on another server's packets).
Love: This is important since the heimdal digest protocol supports
Love: ticket delegation as a side effect.
Love: I've got a version is is pretty much just like
Love: NetrLogonSamLogonEx() though.


But Windows servers don't support the Heimdal interface, and
isn't interoperability with existing Windows deployments 
important to most NTLM consumers?

-- Luke 
===============================================================
Subject: Re: NTLM
From:    Love Hornquist Astrand <lha@kth.se>
To:      Luke Howard <lukeh@padl.com>
Date:    Wed, 2 Sep 2009 09:08:53 -0700
Cc:      Andrew Bartlett <abartlet@samba.org>,
         Don Davis <dodavis@redhat.com>,
         Stephen C Buckley <sbuckley@mit.edu>, 
         Günther Deschner <gd@samba.org>

Luke: But Windows servers don't support the Heimdal interface, 
Luke: and isn't interoperability with existing Windows deployments 
Luke: important to most NTLM consumers?

Heimdal does not do DCE-RPC, others do that better, like samba.

It's quite possible to use a modified digestserver interface 
together with NetrLogonSamLogonEx()

Love
=================================================================
From:    Luke Howard <lukeh@padl.com>
To:      Andrew Bartlett <abartlet@samba.org>
Subject: Re: NTLM
Date:    Wed, 2 Sep 2009 08:17:24 +0200
Cc:      Love Hornquist Astrand <lha@kth.se>,
         Don Davis <dodavis@redhat.com>,
         Stephen C Buckley <sbuckley@mit.edu>, 
         Günther Deschner <gd@samba.org>

Andrew: I wondered if, as there is a renewed interest in
Andrew: 'NTLMSSP done right' from GD, that we might provide
Andrew: a full mechglue mechansim to be loaded from Heimdal.

Would not Heimdal or Likewise's implementation be a good starting 
point?

Andrew: - The ability to use Heimdal's SPNEGO code.  SPGNEGO is
Andrew:   very tied to Kerberos, particularly for the new actually
Andrew:   secure version.  Samba has to get at quite a bit of info
Andrew:   from GSSAPI to try (and often fail) to do SPENGO externally
Andrew:   from the GSS lib.

Also at some point we might support NegoEx
(http://tools.ietf.org/html/draft-zhu-negoex).

> - The desire to rid the world of this horrible protocol.
>   But also the need to potentially support the less secure 
>   variants despite this.

What Love mentioned, and IAKERB should help.

-- Luke