samba - Apr 2019 - Windows clients require reboot once a day in order to access mapped drives

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.
> >
>
> > smb.conf on file server
> > ----------------------------------
> >
> > [global]
> > kerberos method = system keytab
> > workgroup = REALM
> > security = ads
> > realm = REALM.EXAMPLE.COM
>
> Provided that 'REALM' is really 'DOMAIN' (a single word, 15
characters
> or less, without a dot)

Yes, REALM is actually a 4 letter word (but not "that kind" of 4
letter
word...).


> , the only thing I would do is to remove the
> 'kerberos method' line
>
I'll try removing that and see what happens.


--
Mason

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
>

>
> 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.
>
I added "server max protocol = SMB2" to my smb.conf file.  After
restarting
smbd, I tried to connect using a windows 10 client and was denied (error
message on the client and server says that a parameter is incorrect).  I
rebooted the PC and tried again.  No go...  So apparently it's not possible
to force W10 to downgrade to SMB2?

I'm really hoping someone is able to give me something to go on here,
because now I'm really stuck....
>

Hai, 

If i may suggest.. 

AD-DC, fine no changes needed. 
File server smb.conf, i made some changes, see below. 

I change the keytab and kerberos methode because your thinking that related to
the problem.
And i changed some settings below, which are moved from Global setting to Share
setting.

3 settings where defined as (S) as in, its a "share" setting, so put
it in the share definition.
Now i suggest, play with these 2:
    access based share enum = yes
    smb encrypt = desired

Other option try :  acl_xattr:ignore system acls = yes 
In place of acl_xattr:default acl style = windows 

Try as shown with the config below, then turn the smb encrypt off, try again.
Then the other, try again.  You know the drill.  ;-) test the 3 changes share
settings.

Stop and start samba after changing these settings ( no restart ).
Just to make sure everything is loaded as it should. 

(the file server's ) adjusted smb.conf


[global]

dedicated keytab file = /etc/krb5.keytab
kerberos method = secrets and 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
map acl inherit = yes
store dos attributes = yes

#disable netbios = yes
# just disable the start up of nmbd. 

template shell = /bin/false
template homedir = /srv/samba/Users/%U


[Users]
	  acl_xattr:default acl style = windows
        access based share enum = yes
	  smb encrypt = desired
        path = /srv/samba/Users
        comment = Share for user home dirs
        guest ok = no
        read only = no

[Shared]
	 acl_xattr:default acl style = windows
       access based share enum = yes
       smb encrypt = desired 
       path = /srv/samba/Shared
       guest ok = no
       read only = no

Greetz Louis

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens 
> Mason Schmitt via samba
> Verzonden: donderdag 25 april 2019 5:29
> Aan: Rowland Penny
> CC: samba at lists.samba.org
> Onderwerp: Re: [Samba] Windows clients require reboot once a 
> day in order to access mapped drives
> 
> >
> > 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.
> >
> 
> I added "server max protocol = SMB2" to my smb.conf file.  
> After restarting
> smbd, I tried to connect using a windows 10 client and was 
> denied (error
> message on the client and server says that a parameter is 
> incorrect).  I
> rebooted the PC and tried again.  No go...  So apparently 
> it's not possible
> to force W10 to downgrade to SMB2?
> 
> I'm really hoping someone is able to give me something to go on here,
> because now I'm really stuck....
> 
> >
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
> 
>