Problem:
Each morning, windows 10 users are not able to access their mapped drives.  Once they reboot their computers, they are fine for another day.  Windows 7 users do not experience this issue. 

Configuration:
Samba AD DC, running on Ubuntu 18.04, using the stock samba package (4.7.6)
Samba file server, running on CentOS 7.6, using the stock samba package (4.8.3)


smb.conf on AD DC
--------------------------------

# Global parameters
[global]
        dns forwarder = 10.0.38.1
        netbios name = AD1
        realm = REALM.EXAMPLE.COM
        server role = active directory domain controller
        workgroup = REALM
        idmap_ldb:use rfc2307 = yes

[netlogon]
        path = /var/lib/samba/sysvol/realm.example.com/scripts
        read only = No

[sysvol]
        path = /var/lib/samba/sysvol
        read only = No


krb5.conf on AD DC
------------------------------
[libdefaults]
        default_realm =  REALM.EXAMPLE.COM
        dns_lookup_realm = false
        dns_lookup_kdc = true



smb.conf on file server
----------------------------------

[global]
kerberos method = system keytab
workgroup = REALM
security = ads
realm = REALM.EXAMPLE.COM

# Logging
log file = /var/log/samba/%m.log
log level = 3

idmap config REALM : range = 2000000-2999999
idmap config REALM : backend = rid
idmap config * : range = 10000-999999
idmap config * : backend = tdb

winbind use default domain = no
winbind refresh tickets = yes
winbind offline logon = yes
winbind enum groups = no
winbind enum users = no

username map = /etc/samba/user.map
bind interfaces only = yes
interfaces = lo eth0

vfs objects = acl_xattr
acl_xattr:default acl style = windows
map acl inherit = yes
store dos attributes = yes
template shell = /bin/false
disable netbios = yes
smb encrypt = desired # Problem exists if this is removed too.
access based share enum = yes
template homedir = /srv/samba/Users/%U
obey pam restrictions = yes

[Users]
        path = /srv/samba/Users
        comment = Share for user home dirs
        guest ok = no
        read only = no

[Shared]
       path = /srv/samba/Shared
       guest ok = no
       read only = no


krb5.conf on file server
------------------------------
[libdefaults]
        default_realm =  REALM.EXAMPLE.COM
        dns_lookup_realm = false
        dns_lookup_kdc = true


--------------------------------------------------------------

Supporting details


For a windows 10 client that is currently unable to access mapped drives, a packet capture shows:

PC -> FS - encrypted and signed SMB3 packet with SMB2 TRANSFORM_HEADER 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.  I don’t know if the bursts corresponded to me clicking on the share in the Windows UI, but I expect they might.


What the protocol docs say

According to Microsoft, 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 “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???
From the quoted section above, we’re referred to section 3.2.4.23.   Essentially, I think that section says that 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.