Jenkins Slave执行PowerShell脚本时Invoke-WebRequest的UseDefaultCredentials凭证来源问题

首先得把-UseDefaultCredentials的作用讲透：这个参数本质是让PowerShell使用当前运行该PowerShell进程的Windows安全上下文对应的默认网络凭据——简单说，就是你的PowerShell脚本是以哪个Windows用户身份跑的，就用哪个用户的集成身份验证凭据（比如域账号的Kerberos/NTLM凭证）。

针对你遇到的问题：明明Jenkins Slave是用用户A的Windows服务运行，但脚本报错用户B权限不足，这里大概率是「你以为的运行身份」和「实际的运行身份」不一致，给你列几个最常见的排查方向：

1. 先确认脚本实际运行的用户是谁 #

别光看Slave的服务配置，直接在你的stage里加一行命令验证：

powershell('whoami')

执行完看Jenkins的控制台输出，这会直接告诉你脚本到底是以哪个用户身份在跑——很多时候问题就出在这，比如你以为服务是用户A，但实际脚本跑的时候用的是用户B。

2. 排查Jenkins Slave的启动方式 #

• 如果是Windows服务运行的Slave：右键打开服务管理器，找到你的Jenkins Slave服务→「属性」→「登录」标签，确认登录账号确实是用户A，并且服务已经重启过（修改账号后必须重启服务才会生效）。
• 如果是JNLP方式启动的Slave：比如有人在Slave机器上双击了slave-agent.jnlp，那这个代理进程的身份就是当前登录Windows的用户——如果当时是用户B登录的机器并启动了代理，那脚本自然会用用户B的凭据。

3. 有没有被Jenkins插件/配置修改了运行身份 #

有些Jenkins插件或者Job配置会临时切换脚本的运行身份：

• 比如你有没有用「Run as specific user」这类插件，强制让Job以某个特定用户运行？
• 或者有没有用Credentials Binding插件的某些特殊配置，导致身份被模拟？

4. 目标服务器日志的细节要注意 #

有时候目标服务器日志里显示的「用户B」可能是个误导：

• 如果是域环境，可能是Slave机器的机器账户（格式一般是DOMAIN\机器名$），有时候会被简写或者误显示为用户B，仔细看日志里的用户名全称就能区分。
• 另外，如果遇到Kerberos双跳问题（比如Slave要访问的目标服务器需要再访问其他资源），可能会导致凭据无法委派，这时候也可能回退到机器账户或者其他身份。

总结一下：-UseDefaultCredentials不会随便用其他用户的凭据，核心就是当前执行脚本的PowerShell进程的运行身份。先通过whoami确认实际身份，再顺着上面的方向排查身份不一致的原因，基本就能解决问题了。

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