[Samba] Windows clients require reboot once a day in order to access mapped drives

[Mason Schmitt]

Hi Rowland,

I'm still seeing the problem that I described earlier.  I have however
uncovered some more information that might help resolve the issue.

On Thu, 18 Apr 2019 at 13:10, Mason Schmitt <mason at ftlcomputing.com> wrote:

> Hi Rowland,
>
> > I hope someone has seen this before and knows what's going on.  Given
>> > the time delay between the problem recurring, I'm guessing the issue
>> > lies with Kerberos, but I'm not sure how to verify that or how to
>> > resolve the issue. If you need more info, please let me know.
>> >
>> > Problem:
>> > Each morning, windows users are not able to access their mapped
>> > drives. Once they reboot their computers, they are fine for another
>> > day.
>>
>
The timing of the problem is related to the expiration of a kerberos
ticket, but the problem isn't with kerberos.

I took a packet capture of traffic between a Windows 10 PC, that is
currently unable to remount its mapped drives, and the samba server that is
providing the shares.  I see the following behaviour:


   -

   PC -> FS - encrypted and signed SMB3 packet with SMB2 TRANSFORM_HEADER
   <https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/d6ce2327-a4c9-4793-be66-7b5bad2175fa>
   showing a session ID of 0x000000005bb17760
   -

   FS -> PC - plain text SMB2 packet with the same session ID as above, and
   an NT Status header that says STATUS_NETWORK_SESSION_EXPIRED (0xc000035c)
   -

   During the 17 seconds of the packet capture, this fruitless exchange
   happened 18 times across 4 bursts. Each burst corresponded to me clicking
   on the mapped drive in the Windows 10 GUI.


On the file server, each time I click on the mapped drive I get a burst of
5 identical messages that look like this:

[2019/04/24 14:52:35.439764,  3]
../source3/smbd/smb2_server.c:3171(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1]
status[NT_STATUS_NETWORK_SESSION_EXPIRED] || at
../source3/smbd/smb2_server.c:2505

*What the protocol docs say*

According to Microsoft
<https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55>
NT Status STATUS_NETWORK_SESSION_EXPIRED (0xc000035c) means: “The client
session has expired; so the client must re-authenticate to continue
accessing the remote resources.”

According to Microsoft’s SMB2 protocol documentation
<https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/717222e4-72c6-40e7-9121-a9646d874058>
“If the Status field in the SMB2 header is STATUS_NETWORK_SESSION_EXPIRED,
the client MUST attempt to reauthenticate the session that is identified by
the SessionId in the SMB2 header, as specified in section 3.2.4.2.3. If the
reauthentication attempt succeeds, the client MUST retry the request that
failed with STATUS_NETWORK_SESSION_EXPIRED. If the reauthentication attempt
fails, the client MUST fail the operation and terminate the session, as
specified in section 3.2.4.23.”

Therefore, according to Microsoft’s own protocol documentation, if the
re-auth attempt fails, the client MUST fail the operation and terminate the
session…  So, why doesn’t the client give up and attempt to create a new
session???


>From the quoted section above, we’re referred to section 3.2.4.23.  It’s a
bit long, so here’s a link to it
<https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/58abc9fb-252c-4e37-aeae-24e5cae45aba>.
Essentially, I think the client should be sending a logoff message to the
server with the SMB2 header populated with specific messages.

Even with SMB3 and encrypted payload, the SMB2 header still appears to be
in plain text, so it doesn’t appear to me that the client is following the
spec, because I don’t see any of the required headers in the SMB2 header.



*So what to do next?*
At this point I'm starting to get in over my head and could use some
direction.  This looks like a Windows 10 client bug, but given that I can't
see the full SMB conversation (due to encryption) I'm not certain whether
the samba server is replying in the way the client expects.  Can you or
someone else help me either find a work around or a resolution?  Because
the Windows 7 clients (SMB2 not SMB3) don't exhibit this behaviour, I'm
thinking that forcing all clients to downgrade to SMB2 would probably work
around the issue.  Can you confirm this?  If not, I can just try it and see
what happens.

Thanks!

--
Mason

>