Windows 2016 Shares Not Working via Hostname

Windows Server 2016 Version 1607

Some versions of Windows 2016 have an authentication issue which causes shares to not work via hostname. Shares continue to work via IP, but a registry change must be made for the share to work via hostname. You should first verify that you are definitely not experiencing a DNS issue or a cached credential issue; most of the time, it is a DNS issue.

At least one other post reports similar issues in Windows 10. When this issue arises, a dialog box prompting for credentials will pop-up, but any network credentials will return “Access is denied” and ask you to enter credentials again. The only credentials that will work are local accounts on the server.

Conditions for the Issue

  • Windows Server 2016 Version 1607
  • Enable-SMB1Protocol:  False
  • SmbServerNameHardeningLevel:  1 or 2

You can check the second two items by running the below command from PowerShell.

Get-SmbServerConfiguration

Get-SmbServerConfiguration

The Solution for Shares not Working via Hostname

We fixed this issue with one registry change. Edit the RequiredPrivileges entry in the below path and append SeTcbPrivelege to the end of the list. Additional details about the SeTcbPrivilege parameter are available from Microsoft. Microsoft has claimed that this solution is only a “workaround”, and there should be a hotfix for it in the future.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer
LanmanServer RequiredPrivileges

The Cause

The shares do not work via hostname because of a Kerberos authentication issue. IP shares still work because it uses NTLM authentication, whereas FQDN hostname shares use Kerberos. The latest hotfixes have fixed this in most versions of Windows 10 and 2016. However, in Version 1607, it has not been addressed yet by the 2017-08 Update (KB4035631) or Security Update (KB4034658).

We discovered this by poring over many traces and logs while trying to access the shares. A packet analysis shows “STATUS_ACCESS_DENIED” replies to the Session Setup Requests from the Client. An SRV trace reveals an “SPN (cifs/SERVER.DOMAIN.com) is invalid” error.

Cisco Meraki DHCP Reservations and VLANs

Cisco Meraki VLAN 1

DHCP is easy to configure on a Cisco Meraki in smaller environments without a dedicated server. Meraki DHCP reservations and settings can be tricky though if you switch between enabling/disabling VLANs.

Unless you are sure you will never use VLANs, you should Enable VLANs before creating any DHCP reservations and settings. Although the subnet and MX IP will be the same under both configurations, none of the previously added reservations will carry over; they must be re-added.

Addressing and VLANs Enabled or Disabled

The DHCP reservations do not carry over because the network with VLANs Disabled is technically the “Main Subnet”, whereas with VLANs Enabled, the network is “VLAN 1 (Default)”, as seen in the pictures below.  Since the settings do not carry over, we recommend Enabling VLANs even if you only use a single subnet.

Meraki DHCP Reservations with VLANs Disabled
Meraki VLANs Main Subnet

Meraki DHCP Reservations with VLANs Enabled
Cisco Meraki VLAN 1