Domain Users cannot connect to CIFS shares

[Ebo_Hagan]

Hi All,

I have HA NetApp Storage running CIFS connected to the DCs. Everything was working fine until three days ago. The first controller was not serving CIFS Data after a reboot.  The next day it happened on the second controller also. Running CIFS Domaininfo shows as below.

cifs domaininfo
NetBIOS Domain: xxxxxxxxx
Windows Domain Name: xxxxxxxxx.com
Domain Controller Functionality: Windows 8
Domain Functionality: Windows 8
Forest Functionality: Windows 2008 R2
Filer AD Site: default-first-site-name

Not currently connected to any DCs
Preferred Addresses:
192.16.5.3 xxxxxxx  PDCBROKEN
Favored Addresses:
192.16.5.5 PDCBROKEN
192.16.5.4 PDCBROKEN
192.16.5.6 PDCBROKEN
Other Addresses:
192.16.5.2  PDCBROKEN

Connected AD LDAP Server: \\xxxxx.xxxxxxxxx.com
Preferred Addresses:
192.16.5.3
xxxxx.xxxxxxxxx.com
Favored Addresses:
192.16.5.5
xxxxx.xxxxxxxxx.com
192.16.5.4
xxxxx.xxxxxxxxx.com
192.16.5.6
xxxxx.xxxxxxxxx.com
Other Addresses:
192.16.5.2
xxxxx.xxxxxxxxx.com

The windows version four of the DC server has been upgraded to 2016, only one of the DC is still running windows server 2012. But after the upgrade , the cifs shares were still accessible without any issue.

Please I need you assistance to get this resolved asap. Thanks in advance.

[TMACMD]

Check your Times:

On the Domain Controller (powershell window): [System.DateTime]::UtcNow

On the NetApp CLI: date -u

Those are both times in UTC format. This discounts any TimeZone settings.

They should be close. If they are not, set your time, setup a NTP server.

Keep the times in sync.

https://kb.netapp.com/app/answers/answer_view/a_id/1086746

I had a customer tinking all was good to find out that even though the time was correct, the timezone distorted everything making it look correct. Upon examining the UTC time, there was an hour difference preventing access to CIFS shares.

[Ebo_Hagan]

Thanks TMAC_CTG.

I have checked the time and the timezone both are is in sync but the issues .

Have anyone experience similar situation and can help out. Below are the alerts.

Thu Aug 31 04:20:58 GMT [xxxxxx:cifs.server.errorMsg:error]: CIFS: Error for server \\xxxxxxxx: Error while negotiating protocol with server STATUS_IO_TIMEOUT.
Thu Aug 31 04:21:19 GMT [xxxxxx:cifs.server.infoMsg:info]: CIFS: Warning for server \\xxxxxxx: Connection terminated.

[TMACMD]

I might have another idea but I need to know what version of ONTAP you are running on your cluster please. I'll send out another reply in about an hour

[Adam7ck]

I had similar issue, please read this article:

https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.cdot-famg-cifs%2FGUID-973C24E8-DF20-4EC8-8591-84AF9B4C902E.html

if you have turned off SMB1, please turn it on.

NetApp use SMB1 for authentication to domain controller, so if this protocol is tunned off on DC or Nettapp you can get error which you described

Best Regards

Adam

[TMACMD]

If you are running , I think, 9.1P8 or later, you can disable the SMBv1 connection. I also like to turn on SMBv2 from system-defined to true.

vserver cifs security modify -vserver <cifs-vserver> -smb1-enabled-for-dc-connections false -smb2-enabled-for-dc-connections true

Note, you MUST be on a version of ONTAP that supports this. It was added in 9.1P8 (I think) and all future releases. I have had some customers have to upgrade to this release to get it to work. They were running 8.3 and did the 8.3->9.0->9.1 hops. Worked like a champ after words.

[TMACMD · Accepted solution]

I usually see this in two cases:

1. The customer is using older (Win2012) DCs and enables security STIGs that effectivley turn off SMBv1 on the DCs preveting a running ONTAP vsrerver from communicating any longer.

2. The customer has installed new Windows (2016 or newer) which I think actually disables SMBv1 by default anyway but their ONTAP version is too old (8.3/9.0 or earlier than the 9.1P8 release) and ONTAP will refuse to connect.

In case #2, if you are running a current ONTAP version, ONTAP will detect if SMBv1 is in use and actually disable it for you.

[paul_stejskal]

I think that is 7-mode based on the "cifs domaininfo" output folks...

But my first hunch was SMB1 was disabled on the DCs and you need to enable it. I don't know if it is supported for SMB2 only in 7-mode for DC authentication.

[TMACMD]

which is why I asked for a version clarification.

would be easier to answer with appropriate details

[Ebo_Hagan]

Thanks Paul....it worked after the SMB1 was enabled.

[paul_stejskal]

Glad you got it.

[Ebo_Hagan]

The issue has been resolved after enabling SMB1 on the DC.