2

Here's a situation that came up yesterday: we have a share on a machine we have to access using an alias (CNAME). The machine is running Windows Server 2012 R2, and services Windows 7 and 8 clients.

Windows 7 clients have no issues opening the share \SHARECNAME or \IP.AD.DR.ESS Windows 8 clients can only open the share by \IP.AD.DR.ESS

What worked eventually was to create SPN records for the CNAME to point to the HOSTNAME (setspn -S HOST/CNAME HOSTNAME, etc.) and suddenly the share was usable.

The HOSTNAME machine did log an error:

"The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server HOSTNAME$. The target name used was cifs/CNAME." for which I haven't found that much information, but did point me in the direction of setting the proper SPN records.

What I'm trying to understand is why the difference in client experience?

Thank you.

Fred Woodbridge
  • 21
  • 5

2 Answers2

0

Not exactly sure, but did you happen to set the DisableStrictNameChecking registry setting?

http://www.md3v.com/enable-windows-server-smb-2-0-alias-cname

The IP vs CName along with the SPN is obviously indicating that Kerberos is involved. Perhaps it's the SMB 3.0 encryption that's showing itself. This would only be on a Server2012 to Win8 connection, but that's one of the major differences between SMB 2 and SMB 3. I don't believe that encryption on the shares is enabled by default, but by moving to SMB 3, the protocol might be requiring a Kerberos authentication.

http://blogs.technet.com/b/josebda/archive/2013/10/02/windows-server-2012-r2-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-smb-3-0-or-smb-3-02-you-are-using.aspx

Christopher_G_Lewis
  • 3,647
  • 21
  • 27
  • @christopher-g-lewis SMB2 and above don't need DisableStrictNameChecking to be set in order to access file shares using an alias. This is only applicable to SMB1. If the server and all clients are SMB2+ capable then this step isn't necessary. Info on this is hard to find on Google, but the "More Information" section in this KB explains - https://support.microsoft.com/en-us/kb/281308 – Steve365 Jan 07 '16 at 10:39
0

We had a similar issue with a new NetApp. All W10/2012 clients were not able to access the CNAME share, but W7/2008R2 clients were able to do so. We didn't have to create the CNAME SPN. What we did is remove all SPNs for the CNAME that showed up with setspn -l cname.

NOTE: We had the CNAME as AD computer account as well and it stayed there after.

Kliment
  • 11
  • 1
  • 4