为什么进程作为本地系统访问被视为NT AUTHORITY \ ANONYMOUS LOGON的UNC共享运行？

我有一个Windows服务作为SERVER_X上的本地系统运行，它试图访问SERVER_Y上托pipe的UNC共享上的脚本。

根据下面的链接，我已经在SERVER_Y上授予SERVER_X计算机帐户访问UNC的权限。

如何授予对LocalSystem帐户的networking访问权限？

如何授予访问域networking中本地SYSTEM帐户的共享文件夹的权限

但是，Windows服务无法访问该文件（访问被拒绝的错误）。

dir \\SERVER_X\share Access is denied.

在安全事件日志（在SERVER_Y上），我看到SERVER_X试图以NT AUTHORITY \ ANONYMOUS LOGON身份访问UNC共享。我会认为我应该在安全事件日志中看到计算机帐户（即DOMAIN \ SERVER_X）。

安全事件

两台服务器都是Windows Server 2003 SE SP2。

任何帮助将不胜感激！

我发现这个微博客让我看着使用服务器的主机名与CNAME。

具体来说，下面的片段：

如果你回答了DNS名称parsing，你会是正确的。 如果名称parsing在环境中不能正常工作，则会导致请求Kerberos票证的应用程序实际请求错误的服务主体名称的服务票证 。因此，如果您记得远程文件服务器，我试图连接到“ltwre-chd-mem1.chd.litwareinc.com”，但DNS服务器find了“ltwre-chd-mem1.litware.com”的logging。由于我们在“litwareinc.com”域中find了远程文件服务器，因此Kerberos客户机请求Kerberos票据请求中指出的“cifs / ltwre-chd-mem1.litwareinc.com”服务票证，KDC响应KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN 。

和…

实际上，有几种不同的方法可以“解决”问题：

一个。找出DNS为什么错误地parsing机器名称。

一世。 有这个名字的HOST或CNAMElogging吗？

II。你configuration了WINS查找的DNS区域吗？

和…

如果您发现修复DNS问题是不可能的，那么下一个最好的解决scheme就是让应用程序使用服务器的FQDN。 请记住，应用程序供应商需要参与使用此修复程序。

注意：在Windows Server 2008主机上，我可以成功执行使用CNAME的dir命令。

解决scheme1：

使用主机名而不是CNAME。

我证实，如果从Windows Server 2003主机访问UNC共享与主机名（即\\HOSTNAME\share ）而不是CNAME（即\\CNAME\share ），访问将正常工作。

示例 – 已处理：

 dir \\HOSTNAME\share

示例 – 不工作：

 dir \\CNAME\share Access is denied.

解决scheme2：

为CNAME设置一个SPN（服务主体名称）。

 setspn -a HOST/CNAME SERVER

完成后， dir \\CNAME\share工作。

另请参阅如何将Windows计算机configuration为允许使用DNS别名进行文件共享以获取更多信息。

因为当您访问UNC共享而没有先前build立的networking凭据时，您最终会以匿名身份login。本地系统帐户显然不是一个有效的networkinglogin。

在用户帐户下运行该服务以绕过该问题。