Home / server / Questions / 659212
Accepted
Jesse
Asked: 2015-01-14 10:32:24 +0800 CST

Why process running as Local System accessing a UNC share being seen as NT AUTHORITY\ANONYMOUS LOGON?

  • 772

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!

windows-server-2003

3 Answers

  1. Best Answer

    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.

    • 2

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

    • 0

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

    • 0