3

My company is currently in the process of replacing any Alias or IP reference with FQDNs in our code. Anything that has an IP or Computer Name will be replaced with something like fileserver.example.com, databaseserver.example.com, etc.

This process is working for database connections, web service references, API references. Where we are having issues is with file share access through UNC paths. Accessing files through an UNC path like this \\fileserver.example.com\path\to\files does not work IN SOME CASES.

The IN SOME CASES is the important part here.

The UNC path can be accessed successfully in the following cases

  1. When viewing manually through windows explorer with FQDN path.
  2. When running a process that accesses the files that DOES NOT use the FQDN and instead uses the computer name (\\COMPUTER_NAME\path\to\files).

The UNC path CANNOT be accessed in the following case

  1. When running a process that accesses the files that DOES use the FQDN (\\fileserver.example.com\path\to\files).

I get the following error message.

Logon failure: unknown user name or bad password.

This error message leads you to believe it is an access issue but I don't think that is the case because the service user running the process can access the file using the COMPUTER_NAME in the path and that points to the same location as the FQDN.

Does anyone have experience with this issue?

Are FQDNs even supposed to be used to access file shares through UNC paths?

Clayton
  • 4,483
  • 16
  • 24
Nick Rubino
  • 151
  • 1
  • 5
  • Which client and server OS versions are you using? Is there a pattern to the client OS's experiencing the error? On the error machines, are those clients clocks in sync with the server time? – Clayton Apr 19 '18 at 16:15
  • The Client and Server are actually on the same box a windows 2008 R2. – Nick Rubino Apr 19 '18 at 21:13
  • Just as a note and a general rule of thumb: Do not ever (or at least seriously avoid) hard coding any kind of IP, hostname, FQDN, or other address that is subject to change upon infrastructure change in your code. That's what variables are for, and it's quite easy to source a config file for variable insertion at the top of your code. There should always be a stark difference between modifying configuration and publishing new/different code. – Spooler Apr 19 '18 at 22:15

3 Answers3

2

After reading Claytons post and looking through the security logs in the event viewer we realized this was only an issue when a machine was trying to access a file with an UNC path pointed at itself.

This led me to the loopback check documented in the following article on microsoft.com. https://blogs.technet.microsoft.com/sharepoint_foxhole/2010/06/21/disableloopbackcheck-lets-do-it-the-right-way/

We used Method 1: Specify host names (Preferred method if NTLM authentication is desired)

  1. Disabled DisableStrictNameChecking in registry

  2. Entered fileserver.example.com into the BackConnectionHostNames in registry

Nick Rubino
  • 151
  • 1
  • 5
0

When you use a short name, it falls back to using NTLM authencation. But with a FQDN it has to use Kerberos authentication. The issue is for Kerberos to work, you need a DNS name and a SPN (Service Principal Name) which you are missing. You have 2 options:

Option1: Keep the alias and disable the "Strict Name Checking" feature of windows by creating the following reg key on the server. Also need to reboot.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
DWORD name: DisableStrictNameChecking
DWORD value: 1

Option2: Remove the alias, and create an "alternate" name via Windows that will also create a Kerberos Service Principal Name so the altername name is valid for Kerberos authentcation.

NETDOM NEWNAME /ADD

Replace NEWNAME with the FQDN of the alias you had previously created. This should be run from the actual server that the will service the alias.

https://support.microsoft.com/en-us/help/3181029/smb-file-server-share-access-is-unsuccessful-through-dns-cname-alias

Clayton
  • 4,483
  • 16
  • 24
-1

Started to research the issue as it seemed interesting. I started to browse using the FDQN of the domain in differing environments (I work for an MSP so have access to a fair few domains).

The short version is that I was experiencing something I had never really seen/noticed before. Browsing via windows explorer using the FDQN of the domain would display the file share(s) root folder but nothing else. Browsing using the IP / computer name would display the same share(s) and display the folders/files within the shares as it should.

A bit more Googling found this

What should happen when I browse to my Windows domain name via UNC?.

It does partly answer your question and a reason, but it’s not an exact match of your problem.

Personal I think that implementing the file shares via DFS would allow you use a namespace (similar concept to FDQN) and when it comes to bring in retiring\implementing new file servers it means you would not need to refactor code to point to a new server name file server.

It should also bypass the problem you are experiencing.

Hope this helps.

Overview of DFS https://en.wikipedia.org/wiki/Distributed_File_System_(Microsoft)

DifferentMistake
  • 1
  • 2