We received the following alert from our ActiveIQ Unified Management Appliance (and a similiar one in ActiveIQ / AutoSupport): Alert from Active IQ Unified Manager: Advisory ID: NTAP-20160412-0001
You can find more details here: https://security.netapp.com/advisory/ntap-20160412-0001/
After reviewing it, fixing it seemed like a straight forward change but I wanted to know, is enabling SMB signing on your NetApp a non-disruptive change?
Everything I’ve read says it has been supported since Windows 98 and if you’ve disabled SMBv1 (which you hopefully have) everyone should be using it anyway with SMBv2 and newer which signs by default. On top of that, Domain Controllers use signing by default for things like SysVol and I assume DFS if you have that on your Domain Controllers. Windows also negotiates whether or not to use SMB signing based on client/server settings and by default it prefers more the more secure use of signing unless someone is man-in-the-middling you and downgrading your connection or you’re using…. Windows 95?
Since I couldn’t find any kind of answer to my question I figured I’d post something to hopefully help the next person wondering the same thing and faced with this security alert.
So, is enabling SMB signing on your NetApp a non-disruptive change? He asked again, out loud, like a crazy person.
Short answer: No.
Long answer: Nope but it’s probably not that bad.
I enabled SMB signing on our NetApp (OnTap 9.7P14) and about 95% of clients didn’t even notice but 5% did.
The 5% of clients that had a problem with SMB signing immediately lost access to all shares hosted on the NetApp and would get a “You do not have permissions to access this” error messages.
For remote workers it was easy, disconnect/reconnect your VPN and that solved it. On-premise workers had to logoff/on or reboot. Servers though, they had to be rebooted.
The kicker? Clients that had problems ranged from Windows 7 (I KNOW) to Windows 10. Servers that had problems? Server 2008 R2 (I KNOW) up to 2012 R2. Surprising none of our 2016 or 2019 servers had a problem but we have significantly less of those so plan accordingly if you’re doing this.
Here is an example: We had two identical 2012 R2 servers, one worked post change, one didn’t. We had to reboot one with the issue and then everything was good again.
My advice if you are tasked with implementing this in your organization?
For desktops: Ask your clients to logoff when they go for the day and make the change in the evening.
For servers: Had I been smarter I could have enabled SMB signing on Patch Tuesday right before server reboots. That would have caused the lease disruption and folded in nicely to our existing maintenance window. If that isn’t an option for you have a quick test plan to check if each server can access a share and if it can’t, reboot it.
There is potentially another option I was exploring but abandoned. You could build a GPO that makes SMB signing required and apply it to your Desktops/Servers ahead of time. After the GPO has propagated, in theory, you should be able to enable SMB signing on the NetApp and since all systems are already required to use it, there should be no disruption.
There you go. My lessons learned from this experience. Good luck. Hopefully this helps someone.
NetApp provides documentation here on how to enable SMB signing: https://library.netapp.com/ecmdocs/ECMP1366834/html/GUID-9C1135BA-5DEB-4E0F-9F58-3AED83DA1DD3-copy.html
Yes! thanks! helped me!
Well, after failing I found this post.
Did the same change, could not access my network-home-drive, which is on a Netapp-share, the second after, but changing back to disabled, the settings stayed active!!
We use Citrix and can not switch off the remote desktop, only logging off/on, that did NOT help either.
Only luck was that I made the change on Friday late in the afternoon and Citrix restarting sessions in the night.
No complaints on Monday. going to ask for the GPO-change first before I do a second try…
Hi, I am looking to implement this in our environment. You post does help a lot with planning. One question I do have is on performance. Have you seen any increase in cpu or performance degradation or complaints at either at client or Netapp end?
I honestly never went and looked. Our NetApp is pretty over provisioned for our use. We did not notice any performance issues post change. No reports from clients either but I don’t know if they’d even know what to be watching out for.
Hey Eric, such a fantastic post! last year I accidentally enabled SMB signing on all svm’s on one of our clusters but reverted within 5 seconds of realizing what I did. We saw the same thing…95% users unaffected, 5% affected. VPN users reconnected and were fine, on-prem users had a tougher time. About 50 ppl affected so it wasnt a great day, what made it worse is that we used NetApp for home drives and we have offline files enabled, the offline files element got really messed up. We had to disable offline files, unmap drives, reboot, map drives, enable offline files. Now, im reading your post because I am planning to properly implement SMB signing across the org and given what happened laat year I wasnt looking forward to it. Obviously this will be done on a weekend and hopefully everyone will be logged off on Friday evening. Fingers crossed it all goes well, everyone is on Windows 10 so technically it should be ok.
Good luck!