Unsolved
This post is more than 5 years old
157 Posts
0
2323
Win2K8R2 client cannot access CIFS share without credentials
Hi,
We have a VNX5600 running 8.1.8-121 with a single CIFS server joined to a mixed mode domain. Most of the clients using the share are all non-R2 boxes, all accessing it fine. They built up a couple new R2 machines, not DCs just SQL servers, and neither machine can access the files. Those new boxes are in the same domain, nothing looks out of place with DNS, NTP is synching, etc., yet neither can get to files. They get prompted for credentials, put them in, get access denied. Ran a packet capture on the NAS interface, I see the SMB2 negotiation, right after the celerra sends the response, the client sends a rst and then it starts over again. I cannot see anything in the trace which indicates where in this process it is failing, no Kerberos errors or anything weird coming or going to their DCs. They claim they have other R2 clients in a different domain in the forest which can access this NAS fine although I have no way to verify that personally as I have no account there to test with.
Anyone have any idea? I've looked at the server logs using -a and -s, no errors at all. Everything from what I can see with CIFS on the NAS is ok, it is obviously talking to there DCs fine and domain accounts are not locked out or anything like that.
thanks
downhill2
157 Posts
0
February 1st, 2016 11:00
No, the Windows team told me to make sure it was enabled (they found some NetApp article relating to the same thing). Seems to me we’d want it enabled for the security aspect, but I suppose it is worth a test.
thanks
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
February 1st, 2016 11:00
have you tried to disable SMB signing ?
dynamox
2 Intern
2 Intern
•
20.4K Posts
0
February 1st, 2016 13:00
give it a try
downhill2
157 Posts
0
February 15th, 2016 13:00
Tried this over the weekend, no change. A little more detail might make sense (finally): If the app team connects to our NAS using \\IP the entire SMB session is negotiated and setup without any human interaction between the client, the NAS, or their DC(s). But if they connect to the NAS using \\FQDN it prompts them after some amount of time and if they enter credentials, it works, but this shouldn't be. I can see clearly in the client capture that when this method is used, immediately after the protocol negotiation (which looks identical to the IP method), the client goes into some heavy chatter with the DC, then sends us the RST and starts over from the top. What we cannot tell, nor the support guys analyzing the captures, is what or why these clients seem to not go into phase 2 of the session setup. Sounds like the NAS "may" be telling the client some thing that causes the client to confirm said thing with the local domain controller, and after that exchange, the client thinks things are cool, then starts over from the top only to eventually timeout if no credentials are passed. We have other NAS's with this exact same code base connecting all flavors of Windows up to 2012, etc. and never had any such problems. Very weird indeed.
Rainer_EMC
8.6K Posts
0
February 16th, 2016 01:00
What is the service request number ?
downhill2
157 Posts
0
February 16th, 2016 05:00
77116994
thanks
Rainer_EMC
8.6K Posts
0
February 16th, 2016 06:00
To me this smells like a config problem on your AD, DC, Kerberos or client config
When you are connecting via
\\ IP> then NTLM is uses whereas \\ name uses Kerberos
Could be related to DNS / SPN config – .i.e using a DNS alias that doesnt have a SPN
you could try to enable cifs.LanmanServer.disableNameChecking
Or try server_cifs setspn
Running server_cifssupport to check for config problems doesn’t hurt either
Rainer
Rainer_EMC
8.6K Posts
0
February 16th, 2016 13:00
please disregard my SPN comment - if it was an issue with SPN then auth should fail and resort to NTLM