2

I have a Windows Service running as Local System on SERVER_X which is attempting to access a script on a UNC share hosted on SERVER_Y.

Per the links below, I've granted the computer account of SERVER_X access to the UNC on SERVER_Y.

How to grant network access to LocalSystem account?

How do I grant access to shared folder for local SYSTEM account in domain network

But, the Windows Service is unable to access the file (access denied errors).

dir \\SERVER_X\share
Access is denied.

In the Security Event log (on SERVER_Y) I see that SERVER_X is trying to access the UNC share as NT AUTHORITY\ANONYMOUS LOGON. I would think that I should see the computer account (i.e. DOMAIN\SERVER_X) in the Security Event log.

Security Event

Both servers are Windows Server 2003 SE SP2.

Any help would be greatly appreciated!

Community
  • 1
Jesse
  • 316
  • 1
  • 4
  • 12

3 Answers3

2

I found this Microsoft Blog which got me looking at using the server's hostname vs. CNAME.

Specifically, the below snippets:

If you answered DNS name resolution you would be correct. If name resolution is not working properly in the environment it will cause the application requesting a Kerberos ticket to actually request a Service ticket for the wrong service principal name. So if you remember the remote file server I am attempting to connect to “ltwre-chd-mem1.chd.litwareinc.com”, however the DNS Server found a record for “ltwre-chd-mem1.litware.com”. Since we found the remote file server in the “litwareinc.com” domain the Kerberos client requests a service ticket for “cifs/ltwre-chd-mem1.litwareinc.com” as noted in the Kerberos ticket request, and the KDC responds with KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.

And...

Actually, there are several different ways to “fix” the problem:

a. Find out why DNS is resolving the machine name incorrectly.

i. Is there a HOST or CNAME record for this name?

ii. Did you configure the DNS Zone for WINS lookup?

And...

If you find that fixing the DNS problem is not possible, then the next best solution would be to make the application use the FQDN of the server. Keep in mind that the application vendor would need to be involved to use this fix.

Note: When on a Windows Server 2008 host I could execute the dir command using the CNAME successfully.

SOLUTION 1:

Use hostname instead of CNAME.

I verified that if from a Windows Server 2003 host I accessed the UNC share with the hostname (i.e. \\HOSTNAME\share) instead of the CNAME (i.e. \\CNAME\share), the access would work fine.

Example - WORKED:

dir \\HOSTNAME\share

Example - DID NOT WORK:

dir \\CNAME\share
Access is denied.

SOLUTION 2:

Set a SPN (service principal name) for the CNAME.

setspn -a HOST/CNAME SERVER

After doing this the dir \\CNAME\share worked.

Also see How to Configure Windows Machine to Allow File Sharing with DNS Alias for more information.

Community
  • 1
Jesse
  • 316
  • 1
  • 4
  • 12
  • 1
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters DWORD:DisableStrictNameChecking = 1 can help you, but is it the answer of your question you posted ? – yagmoth555 Jan 14 '15 at 20:52
  • @yagmoth555 Thank you. I checked the server hosting the UNC and it already had that registry key set with 1. Per this [KB](http://support.microsoft.com/kb/281308), I think your registry suggestion plus the SPN is needed. – Jesse Jan 14 '15 at 21:18
0

Because when you access a UNC share without previously established network credentials, you end up as anonymous. The local SYSTEM account obviously isn't a valid network login.

psusi
  • 3,247
  • 1
  • 16
  • 9
  • 1
    Microsoft has [documentation](http://msdn.microsoft.com/en-us/library/ms677973%28VS.85%29.aspx) stating this: _When a service runs under the LocalSystem account on a computer that is a domain member, the service has whatever network access is granted to the computer account, or to any groups of which the computer account is a member._ – Jesse Jan 13 '15 at 19:52
  • Yes, but @psusi is right, as the fallback is anonymous user, why? because the SMB share is validated in user-space, this is not a NFS's share. You want the computer account to login, you will have to enter the computeraccount in the 'local admin' group of that remote computer. – yagmoth555 Jan 13 '15 at 20:23
  • 1
    Microsoft's documentation is correct. Please see the links in my OP. I've granted Full Control Security access to the UNC share to the computer account DOMAIN\SERVER_X$ like mentioned in the links. Giving this Security access to the computer account will give Local System on SERVER_X access to the UNC. I'm successfully doing this with other servers. I'm just looking for ideas why this is not working for a specific server. – Jesse Jan 13 '15 at 20:58
  • @Jesse check your local gpo on the remote server if you allowed anonymous enumeration of share – yagmoth555 Jan 13 '15 at 23:31
0

Run the service under an user account to bypass the problem.

yagmoth555
  • 16,300
  • 4
  • 26
  • 48