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
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
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.