使用自定义 UPN 后缀从未加入域的计算机进行 Kerberos 身份验证

使用自定义 UPN 后缀从未加入域的计算机进行 Kerberos 身份验证

我正在尝试从未加入域的 Windows 10 计算机访问 Active Directory 域内的资源。域是ad.example.com,但还有备选 UPN 后缀example.com

例如,当我使用具有默认 UPN 后缀的用户(例如[email protected])访问文件共享时,Kerberos 身份验证可以正常工作,因为它会自动猜测正确的领域(ad.example.com),执行 DNS 解析以找出 DC,执行 LDAP ping,然后先获取 TGT,再获取 TGS。

当我尝试对使用非默认 UPN 后缀(例如[email protected])的用户执行相同操作时,它会尝试将领域猜测为example.com,这当然无法在 DNS 中解析。我通过为_msdcs.example.comto创建 DNAME 记录_msdcs.ad.example.com并让 DNS 部分以这种方式工作来修复此问题。问题是现在 LDAP ping 仍然不起作用,因为它当然会查询网络登录属性example.com(给出零个结果)而不是ad.example.com(给出一个结果)。这会导致身份验证回退到 NTLM,这是我绝对不希望的,因为我计划在不久的将来完全禁用 NTLM。

当您使用非默认 UPN 后缀时,有没有办法让 Kerberos 在未加入域的机器上工作?

答案1

当您使用非默认 UPN 后缀时,有没有办法让 Kerberos 在未加入域的机器上工作?

不幸的是,不行。虽然这在 Linux 实现中很常见,但 Windows 目录架构和附加系统集成产品的复杂性通常会阻碍这种做法的实用性。有关更多信息,请参阅这篇详细的文章,其中描述了解析和定位器过程中的步骤。

https://serverfault.com/a/1025351/20701
对不在域中的工作站进行 Kerberos 身份验证

请注意,在大型、复杂的目录拓扑中,UPN 通常是不是AD 域的 FQDN。这是为了让登录更加友好和容易([电子邮件保护]对比[电子邮件保护]或 CHILDDOMAINNAME\jsmith)。这也使得在域之间移动主体变得透明,因此登录用户名不会改变。

但是,如果 AD 上的主体名称和密码与客户端登录会话相同,则可以恢复到 NTLM。

相关内容