Error while accessing CIFS shares through SMBv1

[SHAIKNR]

Hi,

We have issue accessing shares via SMBv1, with error below after migrating from 7_Mode (8.2) to Cluster Mode (9.2)

2019-01-26 10:23:32,527 [localhost-startStop-1] DEBUG com.swhh.l.f.j - added and started thread IOJobs Manager thread

2019-01-26 10:23:32,528 [IOJobs Manager thread] DEBUG com.swhh.cs.uarchive.af - IOJobManager Started

2019-01-26 10:23:40,180 [IOJobs Manager thread] WARN  jcifs.smb.SmbTreeConnection - Referral failed, trying next

jcifs.smb.SmbException: Signature validation failed

               at jcifs.smb.SmbSessionImpl.sessionSetupSMB2(SmbSessionImpl.java:646)

               at jcifs.smb.SmbSessionImpl.sessionSetup(SmbSessionImpl.java:463)

               at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:358)

               at jcifs.smb.SmbSessionImpl.send(SmbSessionImpl.java:336)

               at jcifs.smb.SmbTreeImpl.treeConnect(SmbTreeImpl.java:600)

               at jcifs.smb.SmbTreeConnection.connectTree(SmbTreeConnection.java:609)

               at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:563)

               at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:484)

               at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:460)

               at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:421)

               at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:545)

               at jcifs.smb.SmbFile.exists(SmbFile.java:821)

               at com.swhh.utils.io.a.a(SourceFile:117)

               at com.swhh.cs.uarchive.aa.g(SourceFile:229)

               at com.swhh.cs.uarchive.aa.b(SourceFile:176)

               at com.swhh.cs.uarchive.aa.a(SourceFile:203)

               at com.swhh.cs.uarchive.ac.g(SourceFile:203)

               at com.swhh.cs.uarchive.v.g(SourceFile:112)

               at com.swhh.cs.uarchive.b.g(SourceFile:337)

               at com.swhh.cs.uarchive.ad.q(SourceFile:492)

               at com.swhh.cs.uarchive.af.run(SourceFile:382)

               at java.lang.Thread.run(Thread.java:748)

2019-01-26 10:23:40,200 [IOJobs Manager thread] ERROR com.swhh.cs.uarchive.aa - Folder \\NetAppController1\CIFSShare_2019\: jcifs.smb.SmbException - Signature validation failed

[GrumpyOldMen]

Is SMB v1 active on the vserver?

https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.pow-cifs-cg%2FGUID-09B378E8-87B3-4413-83C7-AB91213F91BE.html

[SHAIKNR]

Yes, SMB1, SMB2, SMB3 enabled on the Vserver. Today i have changed the setting of the IS-SIGNING-REQUIRED to TRUE and i can see the users who was complaining earlier that his AVAYA CONTACT RECORDER application was failing with Signing was able to access .... But after sometime i see some users who are on WINDOWS 10 complaining that they are not able to access their shares.  So i put back the setting IS-SIGNING-REQUIRED to FALSE.  Now i am still hanging issue with the AVAYA application.

  Kerberos Clock Skew:                  10 minutes
                    Kerberos Ticket Age:                  10 hours
                   Kerberos Renewal Age:                   7 days
                   Kerberos KDC Timeout:                  10 seconds
                    Is Signing Required:               false
        Is Password Complexity Required:                true
   Use start_tls for AD LDAP connection:               false
              Is AES Encryption Enabled:               false
                 LM Compatibility Level:     ntlm-ntlmv2-krb
             Is SMB Encryption Required:               false
                Client Session Security:                none
        SMB1 Enabled for DC Connections:               false
        SMB2 Enabled for DC Connections:                true 

[GidonMarcus · Accepted solution]

Hi

The signature still provided by ONTAP even if it's disabled. if you moved a CNAME with one signature to another filer it may cache it on the client and complain that it changed .  you can also see it on the filer side with the following command.

event log show -message-n Nblade.smbSignatureMismatch

When i had this issue is was on around 15  Windows Server 2012 R2 Standard (seems that 2008/non-R2 2012/2016 Windows versions were not impacted)

The soultuion was to either reboot it , or (as it wasn't possible on some servers), set this regkey until the next reboot

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" RequireSecureNegotiate -Value 0 -Force

i suspect your windows 10 issue when the signature is enforced is different.

are your clients actually manage to create smb 2+ sessions and Keberos authentication?  see with:

 cifs session show -fields address,windows-user,is-session-signed,auth-mechanism,protocol-version

Gidi