这个问题令我很困惑，我很难制定正确的问题。所以低于我的最大努力。如果你能帮我改进这个问题，我很高兴。
背景： 我通过Chocolatey管理安装在Windows 10客户端上的软件，而后者又由Ansible远程调用。 Chocolatey Packages的存储库驻留在NAS上的Windows共享上。我首先遇到了第二跳问题，这个问题通过使用kerberos门票成功解决（见https://github.com/ansible/ansible/issues/15682）。客户和Synology加入AD域。
我现在面临的问题是，如果存储库是Synology Diskstation上的Windows共享，如果通过Ansible远程调用，Chocolatey不会看到包。该命令实际上成功运行但返回一个空列表。如果在本地调用相同的命令（choco list），一切都很好。如果存储库位于OpenMediaVault（OMV）NAS上托管的共享上，则它与Ansible一起使用，但前提是Samba选项允许guest虚拟机启用。我试图在Synology上找到类似的设置。我启用了访客访问，这似乎也起作用，因为客户端可以连接到共享而无需提供用户名/密码。
通过使用Wireshark我发现当在本地运行choco list时，提供了用户名/域（这是预期的）。如果通过Ansible远程调用该命令，则不提供用户名/域（值为NULL）（这不是真正期望的）。这解释了为什么只有在启用了访客访问权限的情况下才能在OMV上运行。
目前我看到两种可能的解决方案路径：
获取远程执行的choco命令，以便在访问共享时发送用户凭据（首选解决方案更安全）
让Synology Diskstation接受远程执行脚本中没有用户名的登录
我很乐意提供更多信息......
答案 0 :(得分：2)
WinRM会话作为“批处理”登录运行，这意味着凭据缓存不会使用您的用户名/密码进行播种，而且Microsoft很难这样做。我们计划在Ansible中添加Windows become支持以部分解决该问题（在运行Ansible模块之前在WinRM会话中创建一个新的交互式登录会话，这样事情会更直观）。如果Synology了解Kerberos，您可以通过在pywinrm上启用kerberos授权（在pywinrm 0.2.0和Ansible 2.1+上的库存中设置ansible_winrm_kerberos_delegation=true）来实现目标。否则，你就像小溪一样 - 有些模块通过添加自己的身份验证（参见win_package）来解决这个问题，但这是不可持续的 - 我们想要解决它整个问题，而不是模块逐个模块