你好，针对你遇到的域服务账户s_automate在两台Win10 1909 PC上访问SMB共享被拒的问题，我结合域环境下SMB共享的常见故障点，整理了几个针对性的排查方向，你可以逐一尝试：

• 排查Kerberos身份验证相关问题
  域环境下SMB默认依赖Kerberos进行身份验证，票据异常或权限限制很可能导致访问失败：

  1. 在两台问题PC上打开命令提示符，执行klist purge清除当前用户的Kerberos票据，之后重新尝试访问共享；
  2. 在AD用户和计算机中找到s_automate账户，查看属性->账户选项卡，确认是否勾选了「敏感账户，不能被委派」——如果勾选了，可能会影响服务账户跨主机访问共享的权限，尝试取消后测试。

• 检查本地安全策略的用户权限分配
  虽然两台PC和正常机器在同一个OU，但不排除本地策略出现异常：

  1. 运行secpol.msc打开本地安全策略，定位到本地策略->用户权限分配：
     • 确认「从网络访问此计算机」列表中包含域用户组（比如Domains/Users）或s_automate账户；
     • 检查「拒绝从网络访问此计算机」列表中是否误添加了s_automate账户或相关域组；
  2. 查看安全选项中的「网络访问：本地账户的共享和安全模型」，建议设置为「经典 - 本地用户以自己的身份验证」（对域账户影响较小，但可以排除本地模型干扰）。

• 排查SMB客户端配置与残留凭据
  客户端的SMB协议配置或残留错误凭据也可能导致访问失败：

  1. 在问题PC上执行Get-SmbClientConfiguration（需要PowerShell），查看支持的SMB协议版本，对比正常PC的配置，确认是否开启了SMB2/SMB3（当前多数共享已不再支持SMB1）；
  2. 打开「控制面板->用户账户->凭据管理器->Windows凭据」，检查是否存在对应共享路径的错误凭据，删除后重新输入s_automate的账户信息尝试访问。

• 启用详细日志获取精准错误信息
  既然Graylog未捕获到有效日志，建议直接在本地和服务器端开启SMB详细日志：

  1. 在问题PC的事件查看器中，定位到应用程序和服务日志->Microsoft->Windows->SMBClient/Operational，右键启用日志；
  2. 在共享服务器的事件查看器中，开启SMBServer/Operational日志；
  3. 重新尝试访问共享后，查看日志中的具体错误代码（比如0xc0000022代表权限不足，0xc0000133代表Kerberos票据过期），这些代码能帮助精准定位问题；
  4. 也可以在命令提示符中执行net use \\共享路径 /user:域名\s_automate手动映射，获取比图形界面更详细的错误提示。

• 确认服务账户本身的状态
  最后再检查账户本身的状态是否正常：

  1. 在AD中查看s_automate账户的属性，确认是否存在「账户已锁定」或「密码过期」的情况；
  2. 尝试在问题PC上执行gpupdate /force强制更新组策略，之后重新登录s_automate账户测试。

如果以上步骤都无法解决，你可以补充日志中捕获到的错误代码，或者s_automate账户的具体权限配置细节，我再帮你进一步分析。

备注：内容来源于stack exchange，提问作者Astra