Subscribe

Unable to connect to CIFS via DNS from some computers to Homedrive

Hello,

I have run into this twice now on two computers with different users and I fear that it may continue to happen so I am trying to get to the bottom of it.  I use Windows AD Homedrives to map a personal drive for each user.  This drive is located on a CIFs Share on a FAS2020.

If I tried to connect the user to the share via \\DNS\Share1 it fails, however if I do it via \\IP\Share1 or \\DNS.Domain.local\Share1 it will work.  So figuring a DNS issue I did a DNS flush and register, etc.  Did not work, If I do a nslookup or ping via DNS it works fine I just cannot get the share to browser.  However here is the even crazier part that makes no sense to me.  I have other shares on the same FAS2020 and they work PERFECT and 99% of my users work without issues.  So on the others shares \\DNS\Share2 works just fine from the same computer!  To me it almost seems as if the credentials that the PC is sending when using \\DNS\Share1 are different than the credentials that the PC is sending when using \\IP\Share1.  Any thoughts on this or other areas I could check?  The only difference I can see is the other shared drives are mapped via standard logon scripts and the Homeshare is mapped via AD. 

Thanks,

Greg

Re: Unable to connect to CIFS via DNS from some computers to Homedrive

I saw this behaviour, when smb2 was enabled.

connecting over IP or another DNS name (like FQDN) gives a Kerberos host mismatch and falls back to NTLM authentication, which normally works.

maybe the home share mapped with AD tries Kerberos auth and the logon scripts do NTLM auth.

which Ontap version do you have? there have been some bugs with Kerberos token sizes. one is still open and will be fixed in 8.2.2, but on FAS2020 the latest you can go is afaik 7.3.7P4.

Re: Unable to connect to CIFS via DNS from some computers to Homedrive

Dominic,

Thanks for the reply...   I remember making changes in the past to SMB2 but could not remember exactly what I did and I think it was disabling it that fixed it.  We are running 8.1.4 P1 right now, Netapp recommended not going to 8.2 in my environment.  I may give that a try turning that off and seeing what results I end up seeing with that.