Heya folks, Ned here again. Many years ago, we made configuring SMB signing in Windows pretty complicated. Then, years later, we made it even more complicated in an attempt to be less complicated. To...
Updated Nov 09, 2023
Version 14.0
Blog Post
dkuzmiankou Behavior can indeed depend on the specific implementation. I think you have 2 questions:
1) Do you have one or more non-Windows implementations which don't support SMB signing AND will lead to failed connections (because those implementations are coded to do so)? (Here I'm supposing you don't have extremely old Windows versions around, because those can behave with failed connections as well.)
If so, how to identify them?
2) Do you have one or more non-Windows implementations which don't support SMB signing AND will NOT lead to failed connections (but just to SMB connections without signing, so where signing won't be negotiated at the end)?
If so, how to identify them?
There is no Windows event logging indicating point 2 situations as far as I know (and according to Ned). If I've understood Ned well this has probably been placed on the roadmap (although I don't know what exactly should be understood under "signing & encryption auditing", so what exactly will be logged when, where, etc.).
I think you need to inventorize your (non-Windows) environment and try to do some research, ask on specific forums or open support cases to get help. TBH, I have to do this as well... IMHO The most important part, at least in the beginning, is to avoid point 1 situations, especially for critical connections. So try to prepare this as well as possible and try to test things first if possible (if needed you can try to insert some short test window if your internal procedures allow this).
Ciao
Padre Pedro, from WinDoh