samba - Apr 2017 - Using ntlm_auth to get NTLMv2 Session support from an application

On Sat, 2017-04-22 at 13:41 -0400, pisymbol . wrote:
> 
> 
> On Fri, Apr 21, 2017 at 5:28 PM, Andrew Bartlett <abartlet at
samba.org>
> wrote:
> > On Fri, 2017-04-21 at 14:12 -0700, Jeremy Allison via samba wrote:
> > > Not quickly. Probably best to look into the squid code itself
> > > and see how they drive it.
> > 
> > Also look into Wine.  Kai did something very similar there a long
> > time
> > ago.
> 
> I like red! Not so much white.
;-)
> > Your task is fairly easy as the resulting HTTP session won't be
> > NTLMSSP
> > encrypted, just authenticated with NTLMSSP, so you don't need to
> > involve Samba long-term, or get out encryption keys.
> 
> Right, but clarification Andrew: What do you mean the resultant
> session won't be NTLMSSP encrypted? I thought that was the whole
> point of NTLMv2 session security.
Indeed, but the use on HTTP is dodgy, similar to SMBv1 without signing
- the session is set up, but cleartext and not even authenticated (eg
crypto checksum) after that.  Another good example is LDAP, which
allowed (until we turned it off by default in Samba) LDAP binds without
the subsequent encryption.  

Sadly HTTP has no 'subsequent encryption' option that I'm aware of.
 
> > See the 'squid' helper modes, there is ntlmssp-client-1 that
you
> > should
> > use.
> > 
> 
> That's what I figured.
>  
> > You can also play with NTLMSSP over mouse-buffer between that and
> > the
> > squid-2.5-ntlmssp server mode.  Set --password on the server and it
> > becomes standalone binary that does not need Samba running.
> 
> It does, but I need to understand the flow better on how I can funnel
> mount davfs traffic through it (I thought originally this could be
> done using upcall but that doesn't make sense - I think).
You pass only the NTLM headers via ntlm_auth, the rest you keep in the
binary that makes the actual socket connection. 
> I do appreciate the feedback gentlemen.
Thanks!

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba

On Sat, Apr 22, 2017 at 4:49 PM, Andrew Bartlett <abartlet at samba.org>
wrote:
> On Sat, 2017-04-22 at 13:41 -0400, pisymbol . wrote:
> >
>
> > > Your task is fairly easy as the resulting HTTP session won't
be
> > > NTLMSSP
> > > encrypted, just authenticated with NTLMSSP, so you don't need
to
> > > involve Samba long-term, or get out encryption keys.
> >
> > Right, but clarification Andrew: What do you mean the resultant
> > session won't be NTLMSSP encrypted? I thought that was the whole
> > point of NTLMv2 session security.
>
> Indeed, but the use on HTTP is dodgy, similar to SMBv1 without signing
> - the session is set up, but cleartext and not even authenticated (eg
> crypto checksum) after that.  Another good example is LDAP, which
> allowed (until we turned it off by default in Samba) LDAP binds without
> the subsequent encryption.
>
> Sadly HTTP has no 'subsequent encryption' option that I'm aware
of.
>
>
I would assume once the socket has been setup the davfs commands would go
over the NTLMv2 encrypted session? Did I miss something here?

-aps

On Sat, 2017-04-22 at 17:45 -0400, pisymbol . wrote:
> 
> 
> On Sat, Apr 22, 2017 at 4:49 PM, Andrew Bartlett <abartlet at
samba.org>
> wrote:
> > On Sat, 2017-04-22 at 13:41 -0400, pisymbol . wrote:
> > >
> > 
> > > > Your task is fairly easy as the resulting HTTP session
won't be
> > > > NTLMSSP
> > > > encrypted, just authenticated with NTLMSSP, so you don't
need
> > to
> > > > involve Samba long-term, or get out encryption keys.
> > >
> > > Right, but clarification Andrew: What do you mean the resultant
> > > session won't be NTLMSSP encrypted? I thought that was the
whole
> > > point of NTLMv2 session security.
> > 
> > Indeed, but the use on HTTP is dodgy, similar to SMBv1 without
> > signing
> > - the session is set up, but cleartext and not even authenticated
> > (eg
> > crypto checksum) after that.  Another good example is LDAP, which
> > allowed (until we turned it off by default in Samba) LDAP binds
> > without
> > the subsequent encryption.  
> > 
> > Sadly HTTP has no 'subsequent encryption' option that I'm
aware of.
> > 
> 
> I would assume once the socket has been setup the davfs commands
> would go over the NTLMv2 encrypted session? Did I miss something
> here?
Yes, you missed that as DAV is essentially HTTP, there is no encrypted
session, except for possibly an SSL wrapper.

I suggest spending some 'quality time' with wireshark and see what you
are trying to imitate, perhaps I'm all out of date, but this is how I
understand the protocols. 

I hope this helps,

Andrew Bartlett
-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba