[Samba] smbclient fails to authenticate with non extended-security SMB1 server after applying badlock patches

Sushmita Bhattacharya Sushmita at microfocus.com
Fri Apr 29 13:08:15 UTC 2016

   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


More information about the samba mailing list