samba - Apr 2016 - smbclient fails to authenticate with non extended-security SMB1 server after applying badlock patches

Hi,
   We support an older version SMB1 server (propietary implementation) which
does not support extended security . Mapping a share from that server, using
smbclient, was working before applying badlock patches (to the smbclient) , with
default settings in smb.conf. However, after applying badlock patches, smbclient
fails to map with default settings.  When I set the option : "client ntlmv2
auth = no", mapping works fine, however it uses ntlmv1 rather than ntlmv2 .
I am suspecting it is due to the 'behaviour changes' documented in
https://www.samba.org/samba/security/CVE-2016-2111.html :
"client ntlmv2 auth = yes" and "client use spnego = yes"   
(both the default values), require extended security (SPNEGO)    support from
the server. That means NTLMv2 is only used within    NTLMSSP.
In the same page , new smb.conf option for "raw NTLMv2 auth" is
described as :

raw NTLMv2 auth (G)    This parameter determines whether or not smbd(8) will
allow SMB1 clients    without extended security (without SPNEGO) to use NTLMv2
authentication.In order to get back to the working setup, what I really need is
the smbclient to allow raw NTLMv2 auth . Is that possible , by setting any
configuration option ?I suppose if there was a client side option like
"client raw ntlmv2 auth = yes", it would have served my purpose.
However I believe there is no such/similaroption. Any help on how to re-enable
raw ntlmv2 authentication from smbclient, will be really helpful for
us.Thanks,Sushmita

Hi Sushmita,
>    We support an older version SMB1 server (propietary implementation)
which does not support extended security . Mapping a share from that server,
using smbclient, was working before applying badlock patches (to the smbclient)
, with default settings in smb.conf. However, after applying badlock patches,
smbclient fails to map with default settings.  When I set the option :
"client ntlmv2 auth = no", mapping works fine, however it uses ntlmv1
rather than ntlmv2 . I am suspecting it is due to the 'behaviour
changes' documented in
https://www.samba.org/samba/security/CVE-2016-2111.html :
> "client ntlmv2 auth = yes" and "client use spnego =
yes"    (both the default values), require extended security (SPNEGO)   
support from the server. That means NTLMv2 is only used within    NTLMSSP.
Yes, that's expected.

I guess you want "client use spnego = no" instead of "client
ntlmv2 auth
= no",
as you'll only get the error if *both* are set to "yes" (the
default for
both).

Or if you want this just for a specific command, try
to pass --option="client use spnego = no" to smbclient.
(note --option=clientusespnego=no should also work in case you have
problems with escaping whitespaces.
> In the same page , new smb.conf option for "raw NTLMv2 auth" is
described as :
> 
> raw NTLMv2 auth (G)    This parameter determines whether or not smbd(8)
will allow SMB1 clients    without extended security (without SPNEGO) to use
NTLMv2 authentication.
The "raw NTLMv2 auth" option is just for the server.
> In order to get back to the working setup, what I really need is the
smbclient to allow raw NTLMv2 auth . Is that possible
>, by setting any configuration option ?I suppose if there was a client
side option like "client raw ntlmv2 auth = yes",
it
> would have served my purpose. However I believe there is no
such/similaroption. Any help on how to re-enable raw
ntlmv2
> authentication from smbclient, will be really helpful for
us.Thanks,Sushmita
See "client use spnego = no" above...

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20160429/d08d2fe7/signature.sig>