![镜像 Windows 工作站上的 RPCSS Kerberos 问题](https://linux22.com/image/534744/%E9%95%9C%E5%83%8F%20Windows%20%E5%B7%A5%E4%BD%9C%E7%AB%99%E4%B8%8A%E7%9A%84%20RPCSS%20Kerberos%20%E9%97%AE%E9%A2%98.png)
在进行一些不相关的故障排除时(至少我是这样认为的,共享打印机问题),我遇到了一组令我担心的事件日志条目。
Machine Name: labcomputer82
Source: Security-Kerberos
Event ID: 4
Event Description:
Kerberos 客户端从服务器 labcomputer143$ 收到 KRB_AP_ERR_MODIFIED 错误。使用的目标名称为 RPCSS/imagemaster4.ad.domain.edu。这表明目标服务器无法解密客户端提供的票证。当目标服务器主体名称 (SPN) 在目标服务正在使用的帐户以外的帐户上注册时,可能会发生这种情况。请确保目标 SPN 在服务器使用的帐户上注册,并且仅在该帐户上注册。当目标服务使用的目标服务帐户密码与 Kerberos 密钥分发中心 (KDC) 为目标服务帐户设置的密码不同时,也会出现此错误。请确保服务器上的服务和 KDC 都已更新为使用当前密码。如果服务器名称不是完全限定的,并且目标域 (AD.DOMAIN.EDU) 与客户端域 (AD.DOMAIN.EDU) 不同,请检查这两个域中是否存在同名的服务器帐户,或使用完全限定的名称来标识服务器。
此消息中使用了三个计算机名称。它是在 labcomputer82 上生成的,它试图与另一个名为 labcomputer143 的实验室工作站通信,而相关服务 (RPCSS) 指的是此计算机映像来源的计算机名称(也可能是 labcomputer143 的名称,我不确定)。让我大吃一惊的是,名为的计算机labcomputer82
正试图使用 SPN RPCSS/imagemaster4.ad.domain.edu
。
AD 中计算机对象的 SPN 属性看起来不错。它具有应有的所有名称。
这些机器使用 Ghost 进行映像处理,并且(至少在这个特定情况下)使用 sysprep不是使用。在我们的 AD 域中的 3,000 多个计算机对象中,大约有 1,700 个是经常进行映像处理的计算机实验室席位,截至 9 月,大多数都是使用 Ghost/Profile-Copy 方法而不是 Microsoft 推荐的 Ghost/sysprep 方法进行映像处理的。如果此错误报告是 Windows 正在悄悄解决的重要问题,那么这些机器的 kerberos 可能已损坏并且正在恢复到 NTLMv2,我想知道,这样我就可以增加对 sysprep 采用的压力。
答案1
您绝对应该执行 Sysprep 以确保每台机器都有唯一的 ID。Sysprep 还会执行其他操作,如果不执行 Sysprep,可能会导致各种 Windows 组件意外失败。
只需查看消息(减去您的 sysprep 详细信息),我们就可以推断出这一点。在 labcomputer82 上运行的一个进程正在尝试与 imagemaster4 通信。但它解析并最终与之通信的名称似乎表明它自己是 labcomputer143。您这里可能存在 DNS 问题。也许应该比较 imagemaster4 和 labcomputer143 的 nslookup 输出,以确保它们不使用相同的 IP 地址。
labcomputer82 请求的 RPCSS/imagemaster4.ad.domain.edu SPN 被提供给 labcomputer 82 认为是 imagemaster4 的计算机。然而,它实际上是一台自称是 labcomputer143 的机器/服务。显然,labcomputer143 和 imagemaster4 的计算机帐户密码会有所不同。因此,使用 imagemaster4 加密的票据不会被 labcomputer143 解密。因此出现错误。
我建议做两件事。1. 排除对 sysprep 使用的任何怀疑。确保每台机器都有自己唯一的 ID,并在 AD 中将自己与唯一的计算机帐户关联。2. 阅读 kerberos 故障排除博客条目http://blogs.technet.com/askds了解如何解决这些问题以及常见/可能的原因。
答案2
细节大体上与 maweeras 的猜测一致。由于在生成驱动器映像时缺少 Sysprep,RPCSS 服务误以为它的 SPN 是RPCSS/imagemaster4.ad.domain.edu
。当它尝试获取其 TGT 时,它正在联系imagemaster4.ad.domain.edu
,而当时该 TGT 被一台名为 的计算机占用labcomputer143
。但失败了。
这导致这些站点回退到 NTLM。
作为一种解决方法,我在 imagemaster4.ad.domain.edu(当前未使用)的域 DNS 中将可抢占 DNS 条目添加到 127.0.0.1。在检查了几个受影响工作站的事件日志后,它们现在在 Kerberos 中正常运行。这是一种解决方法,当 imagemaster4 加入域并注册其 DNS 条目时,它将停止工作。但至少我现在有一种方法了。
为未来做好 Sysprep。