☰

镜像 Windows 工作站上的 RPCSS Kerberos 问题

tag-icon • tag-icon active-directory windows-7 kerberos imaging ghost
镜像 Windows 工作站上的 RPCSS Kerberos 问题

在进行一些不相关的故障排除时（至少我是这样认为的，共享打印机问题），我遇到了一组令我担心的事件日志条目。

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。

相关内容