Why can't I access an administrative share on my local machine?

Question

I'm working on a Windows Server 2008 R2 (x64) VirtualBox image that I've set up as a CI/deployment testing environment. I've got VirtualBox set to use Internal-Only networking. I've set up hosts file redirects for the names of my production machines/database:

127.0.0.1      webserv1
127.0.0.1      webserv2
127.0.0.1      dbserv1
etc.

And my deployment script will then attempt to deploy to each address in turn.

My problem is that when I try to hit \\webserv1\d$\deployment-directory, or even \\webserv1\d$\, I'm getting an authorization prompt and I'm denied access. I'm running as administrator on the VirtualBox console; I can't get any more authorized. I can hit \\127.0.0.1\d$\deployment-directory.

I've even disabled the network adapter to make sure I wasn't somehow hitting the real production boxes (and I verified that I can still hit localhost with the machine in that condition).

Any tips?

How are you running your script? Is it like a DOS batch file, PowerShell, something else? — Coding Gorilla, Sep 23 '10 at 20:29
You are using _the_ Administrator account or an account that is an administrator? Only the former (or a full Domain Admin) works on W2K8\R2. — Helvick, Sep 23 '10 at 20:33
It's *the* Administrator account. The fix was registry-based - I'll post an answer. — Matt Mills, Sep 23 '10 at 22:13

score 3 · Accepted Answer · edited Oct 07 '16 at 10:06

This ended up being related to name resolution and permissions. The details are found in this post: http://forums.techarena.in/server-networking/1195474.htm

Basically there are several registry entries which must be created in order to enable this configuration - out of the box Windows does not support it.

Copy&Paste from the now defunct website (via WebArchive):

Allowing other machines to use filesharing via the DNS Alias (DisableStrictNameChecking)

This change alone will allow other machines on the network to connect to the machine using any arbitrary hostname. (However this change will not allow a machine to connect to itself via a hostname, see BackConnectionHostNames below).

Edit the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\lanmanserver\parameters and add a value DisableStrictNameChecking of type DWORD set to 1.

Allowing server machine to use filesharing with itself via the DNS Alias (BackConnectionHostNames)

This change is necessary for a DNS alias to work with filesharing from a machine to find itself. This creates the Local Security Authority host names that can be referenced in an NTLM authentication request.

To do this, follow these steps for all the nodes on the client computer:

To the registry subkey HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Control\Lsa\MSV1_0, add new Multi-String Value BackConnectionHostNames
In the Value data box, type the CNAME or the DNS alias, that is used for the local shares on the computer, and then click OK.
Note: Type each host name on a separate line.

Providing browse capabilities for multiple NetBIOS names (OptionalNames)

Allows ability to see the network alias in the network browse list.

Edit the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\lanmanserver\parameters and add a value OptionalNames of type Multi-String
Add in a newline delimited list of names that should be registered under the NetBIOS browse entries
Names should match NetBIOS conventions (i.e. not FQDN, just hostname)

Register the Kerberos service principal names (SPNs) for other Windows functions like Printing (setspn)

NOTE: Should not need to do this for basic functions to work, documented here for completeness. We had one situation in which the DNS alias was not working because there was an old SPN record interfering, so if other steps aren't working check if there are any stray SPN records.

You must register the Kerberos service principal names (SPNs), the host name, and the fully-qualified domain name (FQDN) for all the new DNS alias (CNAME) records. If you do not do this, a Kerberos ticket request for a DNS alias (CNAME) record may fail and return the error code KDC_ERR_S_SPRINCIPAL_UNKNOWN.

To view the Kerberos SPNs for the new DNS alias records, use the Setspn command-line tool (setspn.exe). The Setspn tool is included in Windows Server 2003 Support Tools. You can install Windows Server 2003 Support Tools from the Support\Tools folder of the Windows Server 2003 startup disk.

How to use the tool to list all records for a computername:

setspn -L computername

To register the SPN for the DNS alias (CNAME) records, use the Setspn tool with the following syntax:

setspn -A host/your_ALIAS_name computername
setspn -A host/your_ALIAS_name.company.com computername

It's OK to mark this Accepted. It lets people know that this problem has been solved. — sysadmin1138, Sep 23 '10 at 22:20
+1. Good catch. This is a fairly common occurrence. It wasn't evident in your question that this was the problem you were running in to, but after reading your solution and re-reading your question the light bulb went on. ;) — joeqwerty, Sep 23 '10 at 22:22
I'll mark it accepted when it lets me - there's a 2-day waiting period for self-answers. — Matt Mills, Sep 23 '10 at 22:27

Why can't I access an administrative share on my local machine?

1 Answers1