[PATCH] change client max protocol default to PROTOCOL_LATEST

[Stefan Metzmacher]

Am 26.05.2017 um 11:33 schrieb Andrew Bartlett via samba-technical:
> On Fri, 2017-05-26 at 12:14 +0300, Alexander Bokovoy via samba-
> technical wrote:
>> Hi,
>>
>> I'd like to start discussion to change 'client max protocol' default to
>> always be PROTOCOL_LATEST instead of PROTOCOL_NT1. While there are known
>> issues with this change for functionality only available over SMB1
>> protocol version, we see increasing amount of deployments where Samba
>> clients cannot in default configuration to connect to servers with
>> disabled SMB1 protocol.
>>
>> Amount of systems with SMB1 support switched off is growing, especially
>> after Microsoft Security Bulletin MS17-010 release (WannaCry). Many
>> organizations did opt to disable SMB1 completely.
>>
>> At this point, I can think of two fall offs from this change:
>>
>>   - MS-RAP/MS-BRWS protocols will not work as they require SMB1
>>   - POSIX extensions would not work as they require SMB1
>>
>> I'd like to see these two addressed in future, if possible. The former
>> one probably would require an alternative approach so that GNOME and KDE
>> UIs could still be able to display available shares and servers (Active
>> Directory did disable browsing already so this is not a new issue). The
>> latter one is in works as discussed during SambaXP.
> 
> Thanks Alexander for brining this up.  I was discussing the same with
> Microsoft recently, and I think we have to find a practical way forward
> here.  There is no point denying SMB2 access to servers that don't
> support SMB1, and the majority of the servers supporting both SMB1 and
> SMB2 won't support unix extensions in any case, yet we hold back the
> protocol just in case.
> 
> Is there any way to detect that SMB1 unix extensions would have been
> available while talking over SMB2?
> 
> It seems reasonable that we at least connect with SMB2 if SMB1 is not
> available, and I would love to see us upgrade to SMB2 if unix
> extensions were not available, ideally tested on a signed connection. 
> 
> Finally, I do hope we can get some progress on unix extensions.  The
> world needs to be able to move on from SMB1, but this is really holding
> things back. 

I tried an autobuild with this change a few times in the past,
but it sadly fails in a lot of places.

I fear someone needs to actively work on this for a few days
to get the existing tests working, in most cases we should test
NT1 and SMB3 in order to avoid regressions.

As much as I'd like to have this change, it's not that trivial
as it seems.

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-technical/attachments/20170526/9423035e/signature.sig>