Powershell 的 -UseDefaultCredentials 是否使用 Kerberos？

如何解决Powershell 的 -UseDefaultCredentials 是否使用 Kerberos？

在 Azure DevOps 服务中，当您将代理连接到服务器时，您可以通过不同类型的方式对服务器进行身份验证。例如，您可以https://i.stack.imgur.com/OPo6t.png关于连接 Linux 代理，您有以下 4 种类型：

• 备用（基本身份验证）
• PAT
• 协商 - 通过 Kerberos 或 NTLM 等方案以登录用户以外的用户身份进行连接。
• 集成 - Linux 不支持

集成类型在 see here 中被称为“Windows 默认凭据”

请不要打扰我。

在我的组织中，我们有一个带有单点登录的 Active Directory 域，我想它使用 Kerberos 作为身份验证协议。有时我使用 Powershell 脚本来访问我们内部 Azure DevOps 服务器的 API，我使用 -UseDefaultCredentials 标志这样用户就不必输入用户名和密码 - 它只会根据登录用户进行身份验证.

这让我想到 -UseDefaultCredentials 标志正在使用 Kerberos 进行身份验证。

但从上面看来，Integrated 似乎使用了“默认凭据”，这与使用 Kerberos 的“协商”不同。

有人能帮我理解这个吗？

解决方法

UseDefaultCredentials 标志告诉底层系统尝试使用调用者的 SSO 凭据，在大多数情况下，该凭据是用于以交互方式或其他方式登录系统的凭据。

严格来说，它并不表示使用哪种协议。它实际上说的是“亲爱的系统内部人员：请帮我弄清楚”。其工作方式是选择 negotiate 协议，顾名思义，该协议根据客户端凭据以及来自服务器的信息协商特定身份验证协议的使用。这称为 SPNEGO 协议。它对调用者是透明的。

SPNEGO 本质上相当简单。客户端有一个已知身份验证协议（Kerberos、NTLM 等）的列表，并将该列表发送到服务器并说“请选择一个”。服务器可以选择其中的任何一个并响应告诉他们使用什么，然后客户端去使用它。鳍。

SPNEGO 也相对智能，因为它可以合理地预测它认为服务器将接受的内容，并会尝试使用列表中的第一个协议预先提供令牌。因此，如果它认为需要 Kerberos，它会提前获取 Kerberos 票证并首先发送。服务器可能认为这很好，或者它可能会失败并返回一个响应说 “不，我真的需要 NTLM”，因此客户端再次尝试使用 NTLM。