关于受信任的根密钥
应用到: System Center Configuration Manager 2007, System Center Configuration Manager 2007 R2, System Center Configuration Manager 2007 R3, System Center Configuration Manager 2007 SP1, System Center Configuration Manager 2007 SP2
不考虑 Configuration Manager 站点模式，客户端需要在建立通信之前对其管理点进行身份验证，以防止攻击者插入恶意管理点并将客户端重定向到他们。创建管理点时，管理点创建了用于签名的证书。证书为自签名证书，有效时间为 99 年。在管理点上的证书存储中创建和保存它。管理点始终创建此自签名证书，即使站点在纯模式下运行并且拥有 PKI 颁发的证书。
当 Configuration Manager 客户端接收来自管理点的消息时，客户端有几个选项用于验证消息是否来自有效的管理点。如果客户端可以查询站点服务器林中的 Active Directory 域服务，则可以验证管理点是否为受信任的管理点。如果客户端不能查询 Active Directory 域服务以验证受信任的管理点，则客户端将使用受信任的根密钥。
什么是受信任的根密钥？
如果客户端不能查询 Active Directory 域服务，则受信任的根密钥将为客户端提供一种用以验证管理点及其证书的真实性的机制。每个主站点服务器生成一个受信任的根密钥，即使站点正在纯模式下运行或启用了 Active Directory 域服务发布。如果主站点被加入父站点中，则子站点会清除它自己的受信任的根密钥，转而信任父站点的受信任的根密钥。受信任的根密钥的功能与公钥基础结构中的根证书略有相同，即在层次结构中进一步向下信任受信任的根密钥的私钥所签署的任何内容。通过使用受信任的根密钥对的私钥签署管理点证书并复制客户端可用的受信任的根密钥对的公钥，客户端可以区分有效的管理点和恶意的管理点。只有客户端不能查询全局编录以获取有关 Configuration Manager 2007 的信息时才需要受信任的根密钥，因为他们位于工作组或远程林中，或因为没有为 Configuration Manager 2007 扩展 Active Directory 域服务架构。受信任的根密钥保存在 root\ccm\locationservices 命名空间的 WMI 中。
管理点如何获得受信任的根密钥？
创建新的管理点时，它会在证书存储中创建自签名证书，而不考虑站点模式。在混合模式下，自签名证书将随后保存到注册表中的位置。在纯模式下，由 PKI 颁发的管理点证书将保存到注册表位置。站点组件管理器从注册表中收集证书并将其证书发送到其站点服务器。如果其站点服务器不是中央站点，则在层次结构中向上传递证书，直到证书到达保存受信任的根密钥所在的中央站点。中央站点服务器使用受信任的根密钥的私钥签署管理点的证书，并在层次结构中将它和受信任的根密钥的公钥副本向下发送回管理点。当管理点接收受信任的根密钥的公钥副本时，用它自己的私钥签署受信任的根密钥。这有助于提高可恢复性，如本节后面部分所述。在这点上，管理点有几个密钥可用于受信任的根密钥过程：
管理点的证书（对于混合模式为自签字证书；对于纯模式为由 PKI 颁发的证书）
受信任的根密钥签署的管理点证书
来自中央站点的受信任的根密钥的公钥副本
管理点的私钥签署的受信任的根密钥的公钥副本
客户端如何对管理点进行身份验证？
客户端将以下密钥和证书信息保存在 WMI 的类中：
有关管理点列表中每个管理点的信息，包括管理点的证书
受信任的根密钥的公钥副本
客户端与其通信的管理点列表
备注
如果管理点位于 NLB 群集中，则客户端信任的管理点列表将包含群集中的所有站点系统。如果站点中没有 NLB 群集，则该列表只包含默认的管理点。
当客户端向管理点发出请求时，会尝试验证响应。客户端检查站点代码的管理点是否位于 WMI 的管理点列表中。如果位于列表中，则客户端尝试从 WMI 检索管理点证书的副本。假定它找到了证书，就会验证消息。每条消息都必须经过验证，否则会被放弃。
如果客户端没有管理点证书保存在 WMI 中，则检查上次更新管理点的时间。如果上次更新时间大于 5 分钟，则客户端检索新的管理点列表。如果 WMI 中没有管理点列表，则客户端必须检索管理点。客户端在何处检索管理点列表取决于客户端模式以及是否为 Configuration Manager 2007 扩展 Active Directory 域服务架构。
可以通过运行安装属性为 SMSDIRECTORYLOOKUP=<开关> 的客户端安装，在三种模式中的任意一种模式下配置客户端。下表描述了每种模式及其关联的管理点身份验证过程。
| 模式 | 开关 | 管理点身份验证过程 |
|---|---|---|
仅限于 Active Directory |
NOWINS |
在此模式中，客户端不能从 WINS 检索管理点列表。如果客户端不能从全局编录服务器或从 DNS 检索列表，则查询失败，客户端将不能与管理点通信。 |
安全 WINS |
WINSSECURE |
在此模式下，客户端首先尝试从 Active Directory 域服务检索管理点列表。如果该尝试失败，则客户端使用 WINS 查找站点的默认管理点，然后向默认管理点请求管理点列表。客户端还向默认管理点请求其证书，然后通过检查 WMI 中受信任的根密钥的副本来验证该证书是否已由受信任的根密钥签署。如果证书有效，则客户端信任它并可将其用于验证来自管理点的消息。如果管理点证书上的签名与客户端受信任的根密钥的副本不匹配，则丢弃来自该管理点的消息。 |
任何 WINS |
WINSPROMISCUOUS |
在任何 WINS 模式下，客户端首先尝试从 Active Directory 域服务检索管理点列表。如果该尝试失败，则客户端使用 WINS 查找站点的默认管理点，然后向默认管理点请求管理点列表。客户端信任管理点，不进行任何证书检查。 |
如果没有指定开关，则客户端在安全 WINS 模式下安装。依赖于 Active Directory 域服务的基础安全的查询过程的“仅限于 Active Directory”模式是最安全的，但只有当客户端可以查询全局编录时才可以使用它，因此，对于远程林或工作组中的客户端不应使用此模式。“任何 WINS”模式不安全，不建议使用。
客户端如何获得受信任的根密钥？
如果已经扩展 Active Directory 域服务并为 Configuration Manager 启用发布，则与站点服务器位于相同林的客户端可以通过查询全局编录服务器检索受信任的根密钥的公共副本。如果客户端不能从 Active Directory 域服务检索受信任的根密钥的初始副本，则您可以在客户端安装过程中在客户端上预设置受信任的根密钥。
如果客户端没有受信任的根密钥会怎么样？
如果客户端没有受信任的根密钥，他们将信任与其通信的第一个管理点显示的受信任的根密钥，这就意味着客户端可能被错误定向到攻击者的管理点，在此管理点上客户端将接收恶意管理点的策略。这可能是老练攻击者的操作，它仅在有限时间内出现 - 在客户端从有效的管理点检索受信任的根密钥之前。为了降低攻击者将客户端错误定向到恶意管理点的风险，您可以为客户端预设置受信任的根密钥。有关详细信息，请参阅如何在客户端上预设置受信任的根密钥。
备注
如果新客户端不能查询 Active Directory 域服务，那么，要降低新客户端被错误定向到恶意管理点的风险，则应给客户端预设置受信任的根密钥。
客户端如何刷新受信任的根密钥？
客户端获得受信任的根密钥的副本后，会将该副本保存在注册表中。如果客户端不能对来自管理点的消息进行身份验证，则客户端会刷新受信任的根密钥，丢弃当前管理点证书，并获得由受信任的根密钥签署的新的管理点证书副本。
客户端如何从中央站点失败中恢复？
如果需要恢复中央站点服务器，该服务器将生成新的受信任的根密钥。系统将收集层次结构中其他站点的所有管理点的证书，将其发送到中央站点，然后由受信任的根密钥签署，最后返回到每个管理点。由于另一站点中的客户端信任管理点，因此它将接收新的受信任的根密钥。如果客户端联系尚未受信任的管理点并且不能通过查询 Active Directory 域服务验证管理点，那么，它将不接收来自管理点的信息。直到客户端可以验证管理点时才能受管理。
如果客户端没有可联系的受信任的管理点，则会出现问题。例如，客户端可能会报告同时执行站点管理点功能的中央站点服务器，并报告该站点服务器已关闭。在只有一个站点的小型部署中，且站点服务器执行站点的所有角色时，这一问题经常发生。如果站点服务器上发生系统故障，则在站点服务器恢复过程中将创建一个新的受信任的根密钥，且管理点通过创建自签字证书（在混合模式下）或获取由 PKI 颁发的新证书（在纯模式下）以接收新证书。客户端既没有管理证书的当前副本和受信任的根密钥的副本，也没有获取它们的自动机制。如果客户端不能查询 Active Directory 域服务以验证管理点，则在管理员将旧的受信任的根密钥从客户端删除并预设置新的受信任的根密钥或允许客户端从与其联系的第一个管理点获得密钥之前，客户端不能与站点进行通信。
如果您的受信任的根密钥被泄露，您应该做什么？
如果客户端可以查询 Active Directory 域服务，它们就不会依赖受信任的根密钥，因此，泄露不会带来严重的风险。在纯模式下运行需要由 PKI 颁发的管理点证书，因此，纯模式下受信任的根密钥的泄露与混合模式下的泄露相比，风险要低。
如果怀疑您的受信任的根密钥被泄露，您应监视站点审核客户端状态消息，以指示未经授权的站点活动，如运行未识别的包。
如果重新安装并还原中央站点服务器，您将生成一个新的受信任的根密钥。如果重新调整站点层次结构以将子站点提升为新的中央站点，则 Configuration Manager 2007 会为层次结构创建一个新的受信任的根密钥。如前所述，您可以预设置客户端以使用新的受信任的根密钥，但是，您的网络仍将暴露在风险之中，因为攻击者已经在您的系统中建立了后门。要真正从受信任的根密钥泄露中恢复，您应考虑重新安装所有站点服务器、管理点和客户端计算机。
关于操作系统部署中受信任的根密钥
在启用分发点以支持多播之后，分发点在本地证书存储中创建自签名证书并将证书签名置于注册表中。站点组件管理器查找注册表中的签名，通知其已被受信任的根密钥签名，然后将其转发到层次结构管理器，以便通过站点的受信任根密钥进行签名。通过受信任的根密钥签名证书之后，签名存储回注册表。签名过程完成之后，分发点准备支持多播客户端。如果自签名的证书到期，分发点创建新的证书并再次开始签名过程。
另请参阅
任务
如何在客户端上预设置受信任的根密钥
如何删除受信任的根密钥
如何验证受信任的根密钥
有关其他信息，请参阅 Configuration Manager 2007 Information and Support。
要与文档团队联系，请将电子邮件发送至 SMSdocs@microsoft.com。