对不在域中的工作站进行 Kerberos 身份验证

Question 1

在这种情况下使用 NTLM...

http://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx

http://en.wikipedia.org/wiki/NTLM

Answer

在这种情况下使用 NTLM...

http://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx

http://en.wikipedia.org/wiki/NTLM

Question 2

老问题，但答案不是特别准确。

Windows 并不特别关心您的计算机是否已加入域。此身份验证阶段的域加入实际上只是一个提示，用于告诉客户端在信息不足的情况下可能应该尝试联系哪个域。

Kerberos 身份验证的工作方式是查看身份验证期间提供给它的凭据。如果提供的用户名有足够的信息来解析域控制器，它将立即尝试 Kerberos。只有当用户提供的信息不足以让客户端找到 DC 时，它才会回退到 NTLM。它基本上是这样工作的：

用户类型\\foo\share
系统提示用户输入凭据，输入[电子邮件保护]和密码
Windows 看到 bar.domain.com 并执行称为 DC 定位的操作，其中包括尝试SRV _kerberos._tcp.bar.domain.com从 DNS 解析，DNS 要么指向域控制器，要么不指向。
如果返回了 DC，Windows 将尝试使用 (2) 中输入的凭据从 DC 获取 TGT。
如果失败，它可能会根据返回的错误执行以下操作之一：

a) 回到（3）并进行循环赛

b) 恢复到 NTLM

c) 彻底失败
现在它有了用户的 TGT，并将其填充到票证缓存中（参见klist.exe）。
通过与 TGT 和 DC 进行通信，它可以为 SPN 请求服务票证cifs/foo。
如果 DC 找到具有该 SPN 的服务帐户，它将返回服务票证，否则它将返回错误并且 Windows 回退到 NTLM。
服务票证已被缓存。
客户端发送服务票证\\foo\share，然后 SMB 执行其工作。

这或多或少就是它在工作组或域加入计算机上的工作方式。唯一的区别是步骤 2 和步骤 3 不同。在域加入的计算机上，凭据已知，域也已知，因此它使用本机 SSO 凭据。仍会尝试 DC 位置，但无需推断用户的域，因为它已经知道了。

因此，这里的技巧是将凭据输入步骤 (2)，以便 Windows 有足够的信息来查找 DC。这意味着使用完全合格的域名，而不是您添加的任何自定义友好 UPN。这也意味着传统的 NetBIOS 方法bar\user可能行不通。如果您有足够的传统基础设施来支持它（还记得 NetBEUI 吗？），也许它会起作用。

Answer

老问题，但答案不是特别准确。

Windows 并不特别关心您的计算机是否已加入域。此身份验证阶段的域加入实际上只是一个提示，用于告诉客户端在信息不足的情况下可能应该尝试联系哪个域。

Kerberos 身份验证的工作方式是查看身份验证期间提供给它的凭据。如果提供的用户名有足够的信息来解析域控制器，它将立即尝试 Kerberos。只有当用户提供的信息不足以让客户端找到 DC 时，它才会回退到 NTLM。它基本上是这样工作的：

用户类型\\foo\share
系统提示用户输入凭据，输入[电子邮件保护]和密码
Windows 看到 bar.domain.com 并执行称为 DC 定位的操作，其中包括尝试SRV _kerberos._tcp.bar.domain.com从 DNS 解析，DNS 要么指向域控制器，要么不指向。
如果返回了 DC，Windows 将尝试使用 (2) 中输入的凭据从 DC 获取 TGT。
如果失败，它可能会根据返回的错误执行以下操作之一：

a) 回到（3）并进行循环赛

b) 恢复到 NTLM

c) 彻底失败
现在它有了用户的 TGT，并将其填充到票证缓存中（参见klist.exe）。
通过与 TGT 和 DC 进行通信，它可以为 SPN 请求服务票证cifs/foo。
如果 DC 找到具有该 SPN 的服务帐户，它将返回服务票证，否则它将返回错误并且 Windows 回退到 NTLM。
服务票证已被缓存。
客户端发送服务票证\\foo\share，然后 SMB 执行其工作。

这或多或少就是它在工作组或域加入计算机上的工作方式。唯一的区别是步骤 2 和步骤 3 不同。在域加入的计算机上，凭据已知，域也已知，因此它使用本机 SSO 凭据。仍会尝试 DC 位置，但无需推断用户的域，因为它已经知道了。

因此，这里的技巧是将凭据输入步骤 (2)，以便 Windows 有足够的信息来查找 DC。这意味着使用完全合格的域名，而不是您添加的任何自定义友好 UPN。这也意味着传统的 NetBIOS 方法bar\user可能行不通。如果您有足够的传统基础设施来支持它（还记得 NetBEUI 吗？），也许它会起作用。

Question 3

不在域内的系统（笔记本电脑）如何仅使用活动目录用户的用户名和密码来访问相同的网络资源？

这取决于涉及哪些“网络资源”。在您登录的已加入域的 Windows 计算机上，至少有两个客户端 Kerberos 身份在起作用：

您，用户@DOMAIN
计算机，工作站$@DOMAIN

还有 host/workstation@DOMAIN，但这通常是主机上运行的服务的标识，可以从其他地方访问。如果主机上的特权进程想要执行某项操作（例如，使用 Kerberos 认证的动态 DNS 将其名称添加到 DNS），它将使用其身份来执行此操作，即工作站$@DOMAIN。但是，如果您在登录会话中自己访问某些资源（例如 CIFS 网络共享或经过认证的 HTTP URL），则客户端身份是你的主体名称，user@DOMAIN（使用您输入的登录密码自动获取其凭证）。从您的问题来看，您似乎认为其中涉及某种组合；但事实并非如此，它们是分开的。

这就是为什么使用 Kerberos 从其他平台访问基于 Windows 的资源没有任何问题的原因。您也可以在 Linux 机器上键入“kinit user”，输入密码以从域控制器获取 Kerberos 凭据 (TGT)，然后使用 Firefox 访问 IIS 上经过 Kerberos 身份验证的网页。所有这些协议都是标准的，除了您的用户凭据外，您不需要任何东西。

先前的答案声称在这种情况下需要 NTLM；这是错误的（尽管当然可以使用）。但是，当您从非域计算机访问某些资源并提示您输入用户名和密码时，您不一定知道实际使用的是什么身份验证方法。它可能使用 Kerberos。它也可能只是回退到基于密码的机制，即将您的用户名和密码发送到服务器进行验证，然后缓存您的密码，这样您就不必重新输入它。许多协议都允许通过 SASL 等抽象方案同时进行这两种操作。您必须在线查看才能知道发生了什么。

Answer