![当共享位于群集的同一节点上时,为什么群集 Windows 服务无法通过机器名称进行共享身份验证](https://linux22.com/image/620316/%E5%BD%93%E5%85%B1%E4%BA%AB%E4%BD%8D%E4%BA%8E%E7%BE%A4%E9%9B%86%E7%9A%84%E5%90%8C%E4%B8%80%E8%8A%82%E7%82%B9%E4%B8%8A%E6%97%B6%EF%BC%8C%E4%B8%BA%E4%BB%80%E4%B9%88%E7%BE%A4%E9%9B%86%20Windows%20%E6%9C%8D%E5%8A%A1%E6%97%A0%E6%B3%95%E9%80%9A%E8%BF%87%E6%9C%BA%E5%99%A8%E5%90%8D%E7%A7%B0%E8%BF%9B%E8%A1%8C%E5%85%B1%E4%BA%AB%E8%BA%AB%E4%BB%BD%E9%AA%8C%E8%AF%81.png)
我有一个 Windows 2012 故障转移群集,其中设置了多个角色,一个文件共享角色,另一个是用于托管配置为以网络服务身份登录的通用 Windows 服务的通用角色。该共享为两个主机节点(技术上是包含两个节点的域组)定义了 NTFS 权限。通用服务通过 unc 路径连接到群集 SMB 共享。
当通用服务角色由共享所属节点以外的节点拥有时,请求会获得批准,并有证据表明该角色正确使用了计算机 SID。但是,当两个角色在同一台计算机上运行时,请求会失败(指定网络服务)。
我主要在寻找权限问题的解决方案,但解释一下为什么自 Windows 2003(此方法有效)以来这种情况发生了变化,这也是有益的。
失败日志(当两个角色位于同一节点时)检查网络共享对象以查看是否可以授予客户端所需的访问权限。
主题: 安全 ID:网络服务 帐户名称:QAAPPCLUS1$ 帐户域:ECORESOURCE 登录 ID:0x3E4
网络信息:
对象类型:文件源地址:###源端口:50905
成功日志(当两个角色位于不同节点时)检查网络共享对象以查看是否可以授予客户端所需的访问权限。
主题: 安全 ID:ECORESOURCE\QAAPPCLUS1$ 帐户名称:QAAPPCLUS1$ 帐户域:ECORESOURCE 登录 ID:0x15E7A9
网络信息:
对象类型:文件源地址:###源端口:50993
答案1
不确定为什么网络服务不再在 Windows 2012 中的本地框中包含具有共享请求的机器标识,而只是授予 NT Authority\Network Service 对共享的访问权限并明确配置 NTFS 权限,并且服务现在将能够连接,无论共享驻留在哪个节点上。