PowerShell DSC文件资源中Credential可用、PsDscRunAsCredential失效的原因及差异

我来给你把这俩属性的区别讲透，再结合你的文件共享复制场景说清楚为啥会出现这种差异：

1. Credential：资源专属的远程访问凭据 #

这个属性是File资源特有的，它的作用非常明确：就是专门用来访问远程文件共享时的身份验证凭据。

当你配置File资源从\\fileserver\share复制文件到目标节点时，DSC会在目标节点上，直接使用你指定的Credential去连接这个共享服务器——相当于你手动在目标节点上用net use \\fileserver\share /user:xxx命令指定凭据的效果。这个过程不需要把凭据“传递”到其他地方，所以只要这个Credential有共享的访问权限，就能正常读取文件并完成复制，完全不受目标节点自身账户权限的限制。

2. PsDscRunAsCredential：运行整个资源的执行身份 #

这个属性是DSC的通用属性，所有资源都可以用，它的作用是让整个DSC资源的执行过程，在目标节点上以你指定的凭据身份运行。

但问题出在Windows的Kerberos双跳限制上：当你在目标节点用PsDscRunAsCredential的身份运行资源时，这个身份默认无法将自己的凭据传递到第三台服务器（也就是你的文件共享服务器）。简单说就是：

• 第一跳：你用PsDscRunAsCredential让目标节点以这个账号运行
• 第二跳：目标节点要去访问共享服务器，这时候它没法把PsDscRunAsCredential的凭据传给共享服务器，只能用自己的计算机账户去访问——而你的目标节点计算机账户刚好没权限，所以就失败了。

总结你的场景 #

• 用Credential：直接针对共享访问授权，绕开了双跳问题，所以正常工作
• 用PsDscRunAsCredential：触发了双跳限制，导致共享访问时用的还是目标节点计算机账户，自然没权限

如果非要用PsDscRunAsCredential的话，你需要给目标节点配置Kerberos约束委派，允许它把PsDscRunAsCredential的凭据传递到共享服务器，但这配置起来比较麻烦，远不如直接用File资源的Credential属性来得直接。

内容的提问来源于stack exchange，提问作者Matt