虽然做了一些不相关的故障排除（至less我认为是这样，共享打印机的问题），我遇到了一系列让我担心的事件日志条目。
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）是指这台机器的机器名称（也可能是labcomputer的机器名称），我不确定）。 让我labcomputer82是，名为labcomputer82的机器正在尝试使用RPCSS/imagemaster4.ad.domain.edu的SPN。
AD中计算机对象上的SPN属性看起来很好。 它应该有所有的名字。
这些机器使用Ghost映像，并且（至less在这个特定的情况下）sysprep 没有被使用。 在我们的AD域中超过3000个计算机对象中，大约有1,700个是计算机实验室席位，通常是成像的，而到9月为止，大部分都是使用Ghost / Profile-Copy方法而不是Ghost / sysprep方法成像。 。 如果这个错误报告是Windows安静地工作的一个主要问题，也许这些机器上的Kerberos被破坏了，并且它回退到NTLMv2，我想知道，所以我可以给我的驱动器增加压力，以便sysprep通过。
你应该绝对做Sysprep，以确保每台机器都有一个唯一的ID。 Sysprep也做其他的东西，而不做Sysprep会导致各种Windows组件不可预知的失败。
只要看看这个消息（减去你的sysprep的细节），我们就可以推断出来。 在labcomputer82上运行的进程正在尝试与imagemaster4进行通信。 但它似乎解决了这个名字，并最终与自己的实验室计算机联系在一起。 这很可能是你的DNS问题。 也许应该比较imagemaster4和labcomputer143的nslookup输出，以确保它们不使用相同的IP地址。
实验室计算机82请求的RPCSS / imagemaster4.ad.domain.edu SPN被呈现给实验室计算机82认为的imagemaster4。 然而，事实certificate，这是一台机器/服务，将自己标识为labcomputer143。 显然，labcomputer143和imagemaster4的计算机帐户密码将有所不同。 因此使用imagemaster4encryption的票不会被labcomputer143解密。 因此，错误。
我推荐2件事。 1.你排除任何有关sysprep用法的猜疑。 确保每台机器都有自己的唯一ID，并将自己与AD关联到一个唯一的计算机帐户。 2.阅读http://blogs.technet.com/askds上的Kerberos疑难解答博客条目，了解解决这些问题和常见/可能的原因。
细节大部分是怀疑的maweeras。 在生成驱动器映像时缺lessSysprep，RPCSS服务确信它的SPN是RPCSS/imagemaster4.ad.domain.edu 。 当它试图得到它的TGT时，它正在联系imagemaster4.ad.domain.edu ，当时它被一台名为labcomputer143的计算机labcomputer143 。 哪个失败了。
这是造成这些台站回落到NTLM的原因。
作为一种解决方法，我在域DNS中为imagemaster4.ad.domain.edu（当前不在服务中）向127.0.0.1添加了可抢先的DNS条目。 在检查了几个受影响工作站的事件日志之后，它们现在可以正常运行Kerberos。 这是一种解决方法，当imagemaster4join域并注册其DNS项时将停止工作。 但至less我现在有一个方法。
面向未来的Sysprep。