[Samba] smbclient error talking to Netapp with SMB 3.11 / Samba 4.7.11

[Rowland Penny]

On Thu, 14 Feb 2019 09:59:30 +0100
Philipp Gesang <philipp.gesang at intra2net.com> wrote:

> Hi Rowland,
> 
> -<| Quoting Rowland Penny via samba <rpenny at samba.org>, on Wednesday,
> 2019-02-13 05:01:19 PM |>-
> > On Wed, 13 Feb 2019 17:16:21 +0100
> > Philipp Gesang via samba <samba at lists.samba.org> wrote:
> > > -<| Quoting L.P.H. van Belle via samba <belle at bazuin.nl>, on
> > > Wednesday, 2019-02-13 04:59:55 PM |>-
> > > > DOM.AIN\foobar's password:
> > > > ^^^^^^^^ 
> > > > 
> > > > No dot is allowed in the NTDOM 
> > > > Fix that first, then try again.
> 
> Looking at the packet dumps, that value never even goes over the
> wire.
> 
> > > Unfortunately we can’t just arbitrarily access the box in
> > > question so before I schedule a call with the customer I’d
> > > rather gather some more feedback first.
> > 
> > And before we can start to help you, we need more info. What you are
> > connecting from, the smb.conf (if there is one) from the netapp etc
> 
> About the other side we only know there is a share reachable
> through an IP address that the customer wants to connect to.
> What kind of software it runs is completely unknown.

The problem is, there may be something very obvious in the smb.conf and
without seeing this (even if it is sanitised), nobody will ever know.

> 
> What we do have is the tcpdumps. They look roughly as follows
> (N for the netapp box, I for our end):
> 
>     [TCP handshake]
>     I → N: SMB Negotiate Protocol Request
>     N → I: SMB2 Negotiate Protocol Response
>     I → N: ACK
>     I → N: SMB2 Negotiate Protocol Request
>     N → I: SMB2 Negotiate Protocol Response
>     [TCP teardown]
>  
> In the broken 3.11 version, second response message contains an
> extra SMB2_PREAUTH_INTEGRITY_CAPABILITIES blob that is not in the
> 3.10 version. It looks like this (redacted):
> 
>     0000   01 00 26 00 00 00 00 00 01 00 20 00 01 00 2a 2a
>     0010   2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a
>     0020   2a 2a 2a 2a c6 26 94 20 ee 9c ac 68 31 38 00 00
>     0030   02 00 0a 00 00 00 00 00 01 00 01 00 2b 06 01 04
>     0040   01 82                                          
> 
> Note that wireshark stops dissecting after the cipherid of the
> first cipher at byte 0x3b (which is byte 0x181 of 0x187 of the
> packet), leaving six bytes unanalyzed.
> 
> A redacted excerpt of the diff from the (good) SMB 3.10 to the
> (bad) 3.11 response:
> 
>     @@ -124,8 +124,8 @@
>              Security mode: 0x01, Signing enabled
>                  .... ...1 = Signing enabled: True
>                  .... ..0. = Signing required: False
>     -        Dialect: 0x0300
>     -        NegotiateContextCount: 0
>     +        Dialect: 0x0311
>     +        NegotiateContextCount: 2
>              Server Guid: 11111111-2222-3333-4444-555555555555
>              Capabilities: 0x00000057, DFS, LEASING, LARGE MTU,
> PERSISTENT HANDLES,
> ENCRYPTION .... .... .... .... .... .... .... ...1 = DFS: This host
> supports DFS @@ -153,4 +153,18 @@ MechType: 1.3.6.1.4.1.311.2.2.10
> (NTLMSSP - Microsoft NTLM Security Support Provider) negHints
>                                  hintName:
> not_defined_in_RFC4178 at please_ignore
>     -        NegotiateContextOffset: 0x0000
>     +        NegotiateContextOffset: 0x0100
>     +        Negotiate Context: SMB2_PREAUTH_INTEGRITY_CAPABILITIES 
>     +            Type: SMB2_PREAUTH_INTEGRITY_CAPABILITIES (0x0001)
>     +            DataLength: 38
>     +            Reserved: 00000000
>     +            HashAlgorithmCount: 1
>     +            SaltLength: 32
>     +            HashAlgorithm: SHA-512 (0x0001)
>     +            Salt:
> ffffffffffffffffffffffffffffffffffffffffffffffff...
>     +        Negotiate Context: SMB2_ENCRYPTION_CAPABILITIES 
>     +            Type: SMB2_ENCRYPTION_CAPABILITIES (0x0002)
>     +            DataLength: 10
>     +            Reserved: 00000000
>     +            CipherCount: 1
>     +            CipherId: AES-128-CCM (0x0001)
> 
> Skimming smbXcli_negprot_smb2_done(), there is a check for the
> data length:
> 
>         if (cipher->data.length != (2 + 2 * cipher_count)) {
>                 tevent_req_nterror(req,
>                                 NT_STATUS_INVALID_NETWORK_RESPONSE);
>                 return;
>         }
> 
> Looks like Samba expects a value of 4 but the server sends 10 so
> the above check fails. The difference appears to be the six
> unaacounted for bytes above. Those bytes look unstructured, could
> it be that the server pads the message to 8 bytes (the last byte
> of the packet is 0x187)? The check is still the same on current
> master btw.
> 
> I’m not really in a position to decide whether the server or
> Samba is at fault here. Would it make sense to relax that check
> and try again?

That check has been there for years, so it may be that Windows is
sending something new and this could in fact be a mis-configured
windows client, or it could be that the netapp is mis-configured, but
without seeing the smb.conf, nobody will ever know.

Rowland