Windows Server 2003 > clustering 服务

服务器群集：Windows 2000 和 Windows Server 2003 安全性最佳实践

发布日期： 2004年08月16日
*
本页内容
一般性假设一般性假设
部署和操作管理部署和操作管理

一般性假设

应该为基础结构设置一些一般性假设和可行的最佳操作，以确保服务器群集运行环境的安全。

1.

服务器和存储器应处于真正安全的地方。

2.

设置检测不规则流量的实用安全实施，例如防火墙、网络探测器和管理工具。

3.

在诸如管理、日志存储、备份和恢复这样的领域，遵循安全方面的最佳实践/常识。

4.

在分配管理权限、ACL 资源和其他内务处理角色方面，坚持平台级安全性最佳实践。

5.

Active Directory、DNS、DHCP、WINS 等网络基础结构服务必须是安全的。任何危及这些基础结构服务安全的做法均会导致危及群集服务自身的安全。

6.

群集管理员必须确保在受信任的计算机上运行调用群集 API（ClusAPI）的应用程序。对正在执行这些应用程序（由群集管理员运行）的计算机的任何妥协方案均会危及群集的安全。例如，如果在运行管理工具的工作站上存在具有提升权限的不受信任的用户，群集管理员可能会在本人毫无察觉的情况下对群集运行不可信赖代码或恶意代码。

7.

对于由群集服务创建和维护的对象集，切勿将这些对象的默认设置调整为限制较少的设置，以免危及其访问安全。群集服务可利用操作系统中的一系列对象，例如：文件、设备、注册表项等。这些对象都具有默认安全设置，可确保非特权用户无法影响群集配置或群集上运行的应用程序。将这些安全设置改为限制较少的安全设置可能导致危及群集的安全并损坏应用程序数据。

返回页首返回页首

部署和操作管理

群集管理员

管理员可以指定组或个人，允许他们对群集进行管理。在服务器群集的当前版本中，控制的精度并不高；用户要么具有管理群集的权限，要么不具有这些权限。要授予用户或组管理群集的权限，必须将该用户或组添加到群集安全描述符中。此操作可以由群集管理员执行，或通过 cluster.exe 命令行工具来完成。

请注意：除节点上的本地管理员组外，群集安全配置的所有其他成员还必须是域用户帐户或全局组。这是为了确保帐户在群集中的所有节点上都相同、已正确定义并已授权。

默认情况下，本地管理员组会被添加到群集服务安全描述符中。

将用户或组添加到群集安全描述符中意味着该用户可以对该群集配置进行全面管理，其中包括（但不限于）：

•

使资源脱机和联机

•

关闭节点上的群集服务

•

向群集中添加节点或从群集中删除节点

•

向群集中添加资源或从群集中删除资源

由于群集中运行的应用程序和服务的影响范围，在向群集安全描述符中添加用户时必须特别注意。

群集服务可运行与群集服务域用户帐户（不要将该帐户与用于管理该群集的帐户相混淆）下的资源相关联的代码。由于群集管理员可以向群集添加新的资源，而且这些资源作为群集服务帐户运行，因此群集管理员可以安装那些将用计算机上的本地管理员权限运行的代码。

最佳实践

•

群集管理员应使用群集服务帐户以外的其他帐户来管理群集。这会将不同的策略（如：密码过期等）分别应用于群集服务帐户和用于管理群集的域帐户。

•

您应该只将具有本地管理员权限的用户添加到群集服务安全描述符中。

请注意： 将域用户或全局组添加到本地管理员组，则该组或帐户将自动成为群集管理员。

•

不要将本地管理员组从群集服务安全性配置中删除。

远程管理和配置群集

调用服务器群集 API（ClusAPI）的管理工具或其他应用程序可在远程工作站上运行。一般假设群集管理员必须确保在受信任的计算机上运行这些应用程序。对正在执行这些应用程序（由群集管理员运行）的计算机的任何妥协方案均会危及群集的安全。

当创建群集或者更改配置（例如添加新的群集节点）时，“群集配置向导”将在运行该向导的计算机上创建一个日志文件，以便在出现故障时，管理员可以使用日志进行调试和故障诊断。日志文件可包含群集配置数据，例如群集 IP 地址、网络名称等。如果未经授权的用户读取了数据，则此数据就可能被用来扩大攻击面。

群集服务帐户

群集服务帐户是用来启动群集服务的帐户。该帐户的凭据存储于服务控制管理器（SCM）中，服务控制管理器（SCM）是一个 Windows 组件，负责在群集节点引导时启动群集服务。

群集服务帐户在群集中的所有节点上都必须相同，而且必须属于域级帐户，对群集中的每个节点都具有本地管理权限。必须存在域帐户才能创建群集，“群集配置向导”将提示您输入所要使用的现有帐户。如果该帐户尚不是本地管理员组的成员，在创建群集时“群集配置向导”会自动将该帐户添加到本地管理员组中。同样，将节点添加到群集时，群集服务帐户也将被添加到本地管理员组中。如果节点从群集中脱离或最后一个节点被删除，并不会从本地管理员组中删除群集服务帐户。

您需要知道这些语义，以免不小心将域帐户本地管理员权限授予一组假设的节点。

请注意：从群集中脱离节点时不会将群集服务帐户从本地管理员组中删除。将节点从群集中删除后，应当手动将群集服务帐户从本地管理员组中删除，以免接纳对计算机具有本地管理员权限的过期帐户。

服务器群集中的节点可使用经过身份验证的通信机制，以确保在群集内的协议中只有该群集的有效成员可以参与。群集中每个节点都具有相同的群集服务帐户，这一点非常重要，因为这样才能提供身份验证的一致性。这也是 Microsoft Windows Server 2003 中引入的群集服务帐户密码实用程序的要求。

必备权限

除了作为本地管理员组的成员外，群集服务帐户还需要一组本地授权的附加权限：

•

充当操作系统的一部分（Windows 2000 和更高版本中需要）。

•

备份文件和目录。

•

增加配额。

•

提高调度优先级。

•

加载和卸载设备驱动程序。

•

将页锁定在内存中。

•

以服务登录。

•

还原文件和目录。

不能从群集服务帐户中删除任何这些权限。如果删除这些必需权限中的任何权限，群集服务可能无法启动或正确操作。

在设置群集服务器过程中，这些权限会在本地授予帐户。无论何时需要手动重新创建群集服务帐户，都必须授予这些附加权限。知识库文章269229：如何手动重新创建群集服务帐户描述了重新创建群集服务帐户所需的步骤。

密码策略

群集服务帐户与任何其他域帐户都类似，同样具有密码，而且密码也可以与密码过期策略相关联。如果已为密码分配了过期策略，则在群集帐户密码过期前必须更改该密码。否则，当密码过期时将造成群集停止工作（因为无法再顺利地对群集内的通信进行身份验证）。

更改密码

在大多数产品部署中，域帐户都具有密码过期策略，强制相对频繁地更改密码（如：每 30 天更改一次）。更改群集帐户密码需要仔细规划。

Windows 2000

群集中所有节点上的群集服务帐户都必须匹配，以确保可以成功地对群集内的通信进行身份验证。在各种条件下群集服务本身会在群集节点之间发送消息，如果有任何一项通信失败，群集节点将从群集中删除（即群集服务将被停止）。由于无法确定群集服务何时建立通信，因此没有明确的窗口可用来以可靠的方式更改群集服务帐户，同时确保群集仍然运行。

在 Windows 2000 中，只能使用以下步骤可靠地更改群集帐户密码：

1.

停止群集中所有节点上的群集服务

2.

更改域控制器中的群集服务帐户的密码

3.

更新所有群集节点上的服务控制管理器密码

4.

重新启动所有群集节点上的群集服务

Windows Server 2003

Windows Server 2003 中的 cluster.exe 命令能够动态更改群集帐户密码，而无需关闭任何节点上的群集服务。cluster.exe 命令可更改域帐户密码并更新群集中所有节点上的服务控制管理器帐户信息。

请注意：此命令仅适用于 Windows Server 2003 节点。如果群集中有任何 Windows 2000 节点，则这些节点的群集服务帐户密码将不被更改。

Cluster /cluster:cluster_name1[,cluster_name2,] /changepassword[:new_password[,old_password]] [/skipdc] [/force] [/options]

这些命令参数具有下列含义：

参数描述

cluster:cluster_name1 [,cluster_name2,]

标识要对其更改帐户密码的群集。如果指定了多个群集，则这些群集必须使用相同的群集服务帐户。如果某些节点不可用，在所有节点或域控制器上的密码都不会被更改。

/changepassword [:new_password [,old_password]]

将域控制器和所有群集节点上的群集服务帐户密码由 old_password （旧密码）更改为 new_password（新密码）。如果命令行中没有提供密码，将会提示您提供密码。

/skipdc

只更改群集节点上的群集服务帐户密码。

/force

强制更改可用节点上的密码，即使某些节点不可用。

请注意：不可用节点上的密码将不被更新。在使用计算机管理手动更新这些节点上的群集服务帐户密码之前，这些节点将无法加入群集。

“群集管理器”工具的联机帮助文档中介绍了该命令的详细信息。

最佳实践

•

群集服务帐户不能是域管理员帐户。

•

应该授予所有帐户尽可能少的权限和特权，以免给定帐户泄漏时出现潜在的安全问题。

•

使用委派为群集中所有节点上的特定帐户授予管理权限。

•

如果单个域中有多个群集，在所有节点上使用同一群集服务帐户可简化管理工作。

•

对多个群集使用单个帐户既可以简化管理，同时又带来潜在的安全风险，您需要在这二者之间做出权衡。如果帐户泄漏，受影响的范围取决于涉及到多少个群集。

•

使用 Windows Server 2003，可以同时更改多个群集中的群集服务帐户密码。

•

如果已经在群集服务帐户上设置了密码过期策略，则不应对其他服务使用此帐户。

•

例如，如果已经设置了密码过期策略，不要对 SQL Server 2000 或 Exchange 2000 使用群集服务帐户。如果有多个服务使用同一个帐户，在群集服务和其他服务之间协调密码更改将会非常复杂，并导致密码轮换期间整个群集和/或服务不可用。最好对每项服务使用一个专用帐户，以便可以独立维护各个帐户。

•

使用 Windows Server 2003，可以联机更改群集服务帐户密码，而不必仅当没有服务使用同一服务帐户时关闭群集。

•

更改 Windows 2000 上的群集服务帐户需要完全关闭群集，然后才能更改帐户密码。关闭并重新启动群集可能意味着群集无法满足可用性要求。例如，对应用程序和服务来说，99.999% 的运行时间要求每年的停机时间少于五分钟。如果群集由于密码循环而关闭，则无法达到此可用性级别。使用 Windows 2000 时，在这些高可用性环境中，群集服务帐户的密码过期策略应设为永不过期。

•

通过 Windows 2000 SP3 和 Windows Server 2003，群集服务可以发布虚拟服务器作为 Active Directory 中的计算机对象。如要确保操作正确，群集服务帐户应有适当的访问权限或特权以便能够创建和操作 Active Directory 计算机容器中的这些对象。

请参见“在服务器群集中使用 Kerberos 身份验证”一节。

•

如果打算使用不同的群集服务帐户部署多个群集，则应创建一个实施上述所有策略并具有上述所有特权的全局组或通用组。然后，应该将每个群集服务帐户放入该组中。

•

通过为所有群集服务帐户提供一个容器并提供一个管理位置来更改帐户策略，从而简化了群集服务帐户的管理。

在服务器群集中使用 Kerberos 身份验证

Windows 2000 中的 Kerberos 身份验证作为 Windows 平台的一部分予以发布。其是 Windows 平台能够向前发展的主要（和默认）安全机制，并且与以前的身份验证机制（例如：NTLM）相比，具有许多优点：

•

提供客户端和服务器之间的相互身份验证：服务器确保客户端可以访问服务器上提供的服务或应用程序，而客户端可以确保正与之通信的服务器确实是其所需的那台服务器。

•

允许在多台计算机之间进行委派身份验证：在多层应用程序部署中，允许与原始请求关联的基于凭据的端对端模拟。例如，一个 Web 站点中可能包含一个 IIS Web 服务器前端、在中间层的业务对象和一个后端的数据库。Kerberos 允许在所有 Web 服务器到数据库的所有层之间执行原始客户身份验证，以实现端到端的身份验证和授权。

•

这是一种允许在多个平台之间实现通用身份验证机制的工业标准。

有关 Kerberos 及其工作原理的更多信息，请访问 TechNet 网站：http://www.microsoft.com/windows2000/techinfo/howitworks/security/kerberos.asp

在服务器群集中，应用程序部署在虚拟服务器中。虚拟服务器是一个服务器群集资源组，包含 IP 地址资源和网络名称资源以及给定的服务或应用程序所需的任何资源。客户端使用与服务关联的 IP 地址或网络名称连接到群集服务。当应用程序从一个节点故障转移到另一个节点时，IP 地址和网络名称资源也会相应地转移过去，因此，不论客户端当前是由群集中的哪台计算机承载的，客户端都将继续使用服务或应用程序原来的目标位置。

对于 Windows 2000（SP2 及早期版本）中的服务器群集，可用于根据虚拟服务器名称对客户端进行身份验证的唯一机制是 NTLM，因此 Kerberos 提供的优点对于包含服务器群集的部署不可用。

在 Windows 2000 SP3 和 Windows Server 2003 中，Kerberos 身份验证将可用于群集服务器应用程序，允许在高度可用的部署中实现端对端模拟。

虚拟服务器计算机对象

Kerberos 身份验证需要在 Active Directory 中发布一个后备计算机对象（CO）。在 Windows 2000 SP3 和更高版本中，网络名称群集资源可以在 Active Directory 中为虚拟服务器发布计算机对象。这可通过新资源属性 RequireKerberos 的下列值进行控制：

•

RequireKerberos = 0

网络名称资源不在 Active Directory 中创建对象。这提供了与 Windows 2000（SP2 以下）相同的语义，并且是默认值，可确保实现向后兼容以及滚动升级过程中的正确操作1：

•

RequireKerberos = 1

网络名称资源在 Active Directory 中创建对象，从而能够根据虚拟服务器计算机名称进行 Kerberos 身份验证。

本节的稍后部分将介绍此属性的完整语义。

请注意：虽然网络名称资源在 Active Directory 中发布计算机对象，但是不应该将此计算机对象用于管理任务，如：应用组策略。Windows 2000 和 Windows Server 2003 中虚拟服务器计算机对象的唯一作用就是使识别群集和 Active Directory 的服务（例如 MSMQ）能够使用 Kerberos 身份验证和委派，以发布服务提供程序信息

计算机对象的寿命

网络名称资源根据某些因素（包括资源属性设置和资源自身的寿命）控制计算机对象的创建和删除。

创建计算机对象

当 RequireKerberos 资源属性设置为 1（默认值为 0）时，网络名称资源将创建计算机对象。将此值设置为 1 要求群集服务帐户必须能够访问 Active Directory，这可以通过具有将工作站添加到域的特权或授予访问 Active Directory 的特定权限来实现。如果帐户没有访问权限，则网络名称资源将无法实现联机。

域管理员可以预先为虚拟服务器（在独立的组织单位中，如果需要）创建计算机对象，以免将工作站添加到域特权授予群集帐户。在这种情况下，计算机对象必须有一个访问控制限制（ACL），以允许群集服务帐户重新设置密码并写入 DnsHostName 和 ServicePrincipalName 属性（它们具有单独的访问权限）。

如果与虚拟计算机名称对应的 Active Directory 中存在孤立计算机对象或由域管理员创建的计算机对象，同时群集服务帐户具有该对象的访问权限，而且该对象未被禁用，则网络名称资源将截获该现有计算机对象。如果向域中添加新计算机，而该域包含具有相同名称的尚未使用的旧的计算机对象，则会出现同样的问题。

网络名称资源将计算机对象的 DnsHostName 属性设置为网络名称资源 Name 属性的完全合格的 DNS 名称加上节点的主 DNS 后缀2：

禁用计算机对象

当不再需要 Kerberos 身份验证（RequireKerberos 属性由 1 变为 0）或者当资源本身被删除时，计算机对象将被禁用。如果计算机对象仍然存在，但是网络名称资源在没有启用 Kerberos 身份验证的情况下进行联机，则客户端身份验证将失败。当从网络名称资源中删除 Kerberos 身份验证时，系统管理员必须删除相应的计算机对象。注意，虚拟服务器中驻留的识别 Active Directory 的应用程序（例如：Exchange Server 和 MSMQ）可能已将自己的信息附加到计算机对象中。如果删除计算机对象，那些属性也将被删除，应用程序可能无法再正常运行。从网络名称中删除 Kerberos 身份验证时要十分小心。

当删除网络名称资源或 Kerberos 身份验证时，网络名称资源会尽量一次性禁用计算机对象。所有禁用操作及其最后的状态都将记录到群集和系统事件日志中。如果由于任何原因禁用计算机对象失败，将不再尝试禁用。

重命名计算机对象

计算机对象与网络名称资源公开的虚拟网络名称联系密切。如果更改网络名称资源的 Name 属性，这种更改一定会在计算机对象中反映出来。这些变化紧密搭配并实现了同步，因此，仅当网络名称资源脱机时才能更改 Name 属性。如果由于任何原因重命名计算机对象失败，对 Name 属性的更改也将失败。

此处有一点需要注意：当网络名称资源联机时允许更改其属性值；在这种情况下，重命名操作将被推迟，直到名称脱机。如果重命名尝试失败，作为联机过程的一部分将重试此操作。名称不会联机，直到重命名操作成功。

请注意：诸如 MSMQ 和 SQL Server 等许多应用程序和服务都不支持更改网络名称资源的 Name 属性。

密码轮换

当颁发 Kerberos 权证时计算机对象维护用于身份验证的密码。在最新的 Windows 2000 SP3 和 Windows Server 2003 实施中，在计算机对象创建之后，其中的密码将不会更改。

警告、问题和注意事项

孤立计算机对象

许多操作系统服务和应用程序都使用Negotiate（协商）安全程序包，后者是 Windows 平台提供的一个组件，允许客户端通过某项服务进行身份验证。此程序包隐藏任何给定身份验证方案的细节，并且允许客户端尝试 Kerberos 身份验证，如果 Kerberos 身份验证不可用，则恢复到 NTLM 身份验证。如果 Active Directory 中有一个计算机对象与客户端正在使用的目标名称相对应，则协商程序包将假定 Kerberos 身份验证是必须的。3：如果 Active Directory 中存在虚拟计算机对象（已禁用或未禁用），则将来与该虚拟服务器名称的客户端连接不会恢复到 NTLM。

如果对虚拟服务器的身份验证失败，并且该虚拟服务器使用的应该是 NTLM，那么应检查与该虚拟服务器名称对应的 Active Directory 中是否有孤立或旧的计算机对象。

识别群集和识别 Active Directory 的服务

有些服务既识别群集又识别 Active Directory，例如：SQL Server 2000、Exchange 2000 和 MSMQ。其中有些服务会将服务信息附加到计算机对象。例如，MSMQ 会将服务信息附加到虚拟服务器计算机对象。

从网络名称资源中删除 Kerberos 身份验证时，计算机对象将被禁用，系统管理员必须明确决定是否删除计算机对象。如果计算机对象被删除，由识别 Active Directory 的应用程序附加的属性也将被删除，从而导致应用程序可能无法再正常运行。从网络名称资源中删除 Kerberos 身份验证时要格外小心。

Active Directory 复制延迟

到目前为止，我们都将 Active Directory 作为一个高度一致的基础结构进行讨论。在生产环境中，可部署多个域控制器以确保域基础结构高度可用。对 Active Directory 的更改会在多个节点之间进行复制，有些情况下复制延迟时间可能很长。这可能导致出现一些看上去不一致的情况，这点您需要注意：

•

客户端无法看到网络名称资源的计算机对象

不同的节点可能访问不同的域控制器。如果在某个域控制器上创建计算机对象，客户端可能无法看到该对象，直到其被复制到其他域控制器。

最佳实践

•

在群集中使用 Kerberos 身份验证时，请仔细规划：

•

在那些对您的部署有意义的虚拟服务器上启用 Kerberos 身份验证。

•

除非您完全了解使用虚拟服务器的服务以及虚拟服务器对该服务的影响，否则不要禁用虚拟服务器上的 Kerberos 身份验证。计算机对象和附加到其中的任何服务信息都将被删除（假设有正确的特权），这可能导致服务不可用或无法恢复。

•

群集服务帐户应具有将工作站添加到域特权，以允许该帐户在 Active Directory 中创建计算机对象。如果您不想将该特权授予群集服务帐户，必须在启用 Kerberos 身份验证之前在 Active Directory 中手动创建计算机对象。

请注意：将工作站添加到域特权允许从该帐户创建 10 个默认的计算机对象。另外，将工作站添加到域本身不允许删除该帐户或重命名计算机对象。

•

群集服务帐户应该具有写入所有属性访问权限，以允许该帐户重命名计算机对象。

•

许多服务（包括 MSMQ 和 SQL Server 2000）都不支持更改网络名称资源的 Name 属性。仅当您完全理解更改此属性的含义时，才能更改此属性。有些情况下，更改网络名称资源的 Name 属性可能导致数据丢失或服务失败。

•

在允许客户端访问新创建的与网络名称资源相关联的计算机对象之前，或将资源故障转移到群集中的其他节点之前，应该确保域控制器有机会复制这些计算机对象。否则，可能导致无法预料的结果（请参见“Active Directory 复制延迟”一节）。

网络安全性

网络泛洪

群集服务使用 UDP 端口 3343 进行群集内部通信。这种通信包括检测节点故障和群集控制操作的检测信号通信。其中某些操作（例如，检测信号）对时间很敏感。如果由于网络泛洪攻击，端口负担过重，可能导致检测到错误的节点故障，从而导致不必要的故障转移操作，这将导致应用程序无法运行。

端口抢占

不良应用程序可能劫持或“抢占”端口 3343，从而使群集服务无法启动。在这种情况下，唯一的选择就是终止使用此端口的进程。端口 3343 仅针对群集服务进行注册。

恶意服务器

群集服务通过群集 API 提供远程管理功能，以便可以从管理站管理群集。群集 API 使用 NTLM 进行服务器身份验证。这使服务器能够验证客户端是否具有足够的权限和特权来管理群集，但不提供相互身份验证。也就是说，客户端不能完全确保其所连接的节点或群集是真正的群集。如果恶意计算机使用相同的 IP 地址或网络名称出现在网络上（如果 DNS 信息遭到入侵），则该欺诈计算机可能会伪装成群集。如果该恶意计算机看起来还实施了群集服务 API，则发送到群集的任何管理命令都将被该欺诈计算机截获。许多情况下，这并不代表存在威胁，因为管理员只会收到一个关于操作是否已执行的虚假报告。但是，在有些敏感的操作中（例如，更改群集配置），未经授权的接收方可能暗中收集群集配置数据，而这可能会助长扩大攻击面。

这种类型的攻击需要许多因素才可能发生：

1.

必须能够在与目标群集相同的子网中看到恶意计算机，并且恶意计算机必须能够响应群集 IP 地址的流量（这可能是物理计算机的 IP 地址，也可能是此计算机承载的虚拟服务器的 IP 地址）。

2.

在典型环境中，只有群集节点或虚拟服务器未运行时，恶意计算机才能占用它们的 IP 地址。

3.

恶意计算机看起来必须实现群集 API。对于典型的管理操作，客户端应用程序对服务器进行多次调用，有些情况下，将返回后续调用的句柄。

4.

管理员/操作过程必须更改包括机密数据的配置（例如，管理员必须更改群集帐户密码）。

最佳实践

危害群集安全的攻击通常与群集位于同一子网上。如要防止这些攻击，应该保护子网：

•

客户端访问网络

群集节点使用的子网不应超出节点集（可受物理保护或受信任）。必须确保恶意或潜在不安全的计算机无法挂接入包含群集的子网。由于此网络可能包括域控制器、DNS 服务器、WINS 服务器、DHCP 服务器和其他网络基础结构，所以您必须采取措施以确保这些结构服务器也是安全的。

典型的网络安全步骤应该执行到位，如只允许特定应用程序请求的防火墙等。保护网络和基础结构服务器的安全不属于本文档的讨论范围。

•

专用网络

在专用网络中应该只能看到群集中的节点（多个群集可以使用同一个专用网络）。其他网络基础结构服务器或其他应用程序服务器不应该位于专用子网上。这可以通过以下两种方法之一来实现：

•

物理限制网络本身（例如，专用网络是只连接到群集节点的局域网）。

•

使用支持虚拟局域网的交换机隔离群集专用网络。

NTLM V1 和 NTLM V2

Windows 2000

Windows 2000 群集（SP2 及早期版本）必须在群集节点之间使用的 NTLM V1 身份验证。有几种锁定工具和策略（如：HiSecDC）可对节点应用不同的策略，强制将 NTLM V2 作为默认安全配置文件。如果将这些策略或工具应用于 Windows 2000 群集，则群集服务将失败。必须重新设置默认安全配置文件才能发送 LM 和 NTLM 响应。这将在知识库文章 295091 和 272129 中予以详细说明。

Windows Server 2003 和 Windows 2000 SP3（和更高版本）

在 Windows 2000 SP3 和更高版本以及 Windows Server 2003 中，群集服务可以使用 NTLM V2。启用 NTLM V2 的安全策略不会危及群集的安全。

NetBIOS

系统的安全性取决于有多少种进入系统的方法。在 Windows Server 2003 中，群集服务不需要 NetBIOS，但是如果禁用 NetBIOS，许多服务都将受到影响。您应该注意以下事项：

•

默认情况下，当配置群集时，群集 IP 地址资源中将启用 NetBIOS。创建群集后，应通过取消选择群集 IP 地址资源属性页的参数页上的复选框以禁用 NetBIOS。

•

当创建其他 IP 地址资源时，应取消选择 NetBIOS 复选框。

•

如果禁用 NetBIOS，当打开与群集的连接时，将无法使用群集管理器中的“浏览”功能。群集管理器使用 NetBIOS 枚举域中的所有群集。

•

“打印”和“归档”服务被禁用，任何虚拟名称都不作为重定向器终结点进行添加。

•

如果指定了群集名称，则群集管理器将无法工作。群集管理器调用使用远程注册表 API 的 GetNodeClusterState，而远程注册表 API 则使用基于虚拟名称的命名管道。

IPSec

虽然可以将 Internet 协议安全性（IPSec）用于可在服务器群集中执行故障转移的应用程序，但是 IPSec 并不针对故障转移而设计，因此建议您不要将 IPSec 用于服务器群集中的应用程序。

主要问题在于：如果发生故障转换，Internet 密钥交换（IKE）安全关联（SA）不会从一台服务器传输到另一台服务器，因为其存储在每个节点的本地数据库中。

在受到 IPSec 保护的连接中，在第一阶段协商中将创建一个 IKE SA。在第二阶段协商中将创建两个 IPSec SA。超时值与 IKE 和 IPSec SA 关联。如果不使用“主密钥完整转发安全性”（Master Perfect Forward Secrecy），则使用 IKE SA 中的密钥材料创建 IPSec SA。如果这样的话，客户端必须等待入站 IPSec SA 的默认超时或寿命结束，然后等待与 IKE SA 相关联的超时或寿命结束。

安全关联空闲计时器的默认超时时间为五分钟。在故障转移的情况下，直到所有资源至少联机五分钟以后，客户端才能够使用 IPSec 重新建立连接。

虽然 IPSec 不是非常适合群集环境，但是如果您对安全连接的业务需求比发生故障转移时的客户端停机时间更重要，则可以使用它。

群集磁盘

通常，群集磁盘（即在群集配置中具有相应资源的磁盘）与 Windows 中的任何其他磁盘一样；但是在使用群集磁盘时，您需要了解一些其他注意事项：

常规最佳实践

•

群集服务器仅支持群集磁盘中的 NTFS 文件系统。这确保可以使用文件保护来保护群集磁盘中的数据。由于群集磁盘可以在节点之间进行故障转移，您必须只使用域用户帐户（或本地系统、网络服务或本地服务）来保护文件。一台计算机上的本地用户帐户对群集中的其他机器没有意义。

•

定期检查群集磁盘，确保其运作正常。群集服务帐户必须具有对所有群集磁盘的顶级目录的写入访问权限。如果群集帐户没有写入访问权限，磁盘可能显示为出现故障。

仲裁磁盘

•

仲裁磁盘的状态决定整个群集的状态。如果仲裁磁盘出现故障，则所有群集节点上的群集服务都将不可用。群集服务将检查仲裁磁盘是否正常，并且仲裁对使用标准 I/O 操作的物理驱动器的独占访问。这些操作与到该设备的任何其他 I/O 一起列队。如果由于流量太大而导致群集服务 I/O 操作被延迟，则群集服务会将仲裁磁盘显示为出现故障，并且强制重新分组以使仲裁磁盘在群集中的其他位置重新进行联机。为了防止恶意应用程序用 I/O 充斥仲裁磁盘，应该保护仲裁磁盘。应该将对仲裁磁盘的访问权限制为本地管理员组和群集服务帐户。

•

如果仲裁磁盘已满，群集服务可能无法记录所需的数据。在此情况下，所有群集节点上的群集服务可能都将失败。要防止恶意应用程序充斥仲裁磁盘，应该将访问限制为本地管理员组和群集服务帐户。

•

由于以上两个原因，不应将仲裁磁盘用于存储其他应用程序数据。

群集数据磁盘

•

与对待仲裁磁盘一样，使用同样的方法定期检查其他群集磁盘。如果恶意应用程序用 I/O 充斥群集应用程序磁盘，则群集服务状态检查可能失败，因此将导致此磁盘（和依赖于此磁盘的任何应用程序）故障转移到其他群集节点。要避免此类拒绝服务攻击，应将对群集磁盘的访问限制为那些在特定磁盘中存储数据的应用程序。

EFS 和服务器群集

对于 Windows Server 2003，加密文件系统（EFS）在群集文件共享中受支持。要对群集文件共享启用 EFS，您必须执行许多任务，以正确配置环境：

1.

只有当虚拟服务器已启用 Kerberos 时，才能在文件共享上启用 EFS。默认情况下，虚拟服务器上不启用 Kerberos。如要启用 Kerberos，您必须选中网络名称资源（将用于连接到群集文件共享区）中的“启用 Kerberos 身份验证”复选框。

请注意： 在选中此复选框之前，应该确保已完全了解对网络名称启用 Kerberos 的诸多含义。

2.

必须信任所有群集节点计算机帐户以及虚拟服务器计算机帐户进行委派。请参见联机帮助了解具体操作方法。

3.

为了确保用户的私钥可用于群集中的所有节点，必须对将使用 EFS 存储数据的用户启用漫游配置文件。请参见联机帮助了解如何启用漫游配置文件。

创建群集文件共享并执行上述配置步骤后，可以将用户数据存储在加密的文件中，以增强安全性。

管理群集中的文件共享

常规文件共享

就安全性而言，常规文件共享是最灵活和最容易理解的一种方法。唯一真正的区别就是您使用群集用户界面而不是 Windows 资源管理器来管理共享级安全性。使用标准 Windows 工具（如：Windows 资源管理器）管理群集磁盘上文件的 NTFS 安全设置。有关管理群集文件共享的更多信息，请参见服务器群集的联机文档。

通过群集管理器创建的文件共享与单个节点具有相同的默认保护，除非 ACL 采用群集管理工具设置。有关文件共享的默认 ACL，请参见文件服务文档。

请注意：请始终使用群集管理工具更改群集文件共享的安全性。如果使用文件共享管理工具，当文件共享故障转移到群集中的其他节点时，所有配置都将丢失。

共享子目录

高于 Windows NT 4.0 Service Pack 4 的 Windows 版本都提供了子目录共享。使用共享子目录，管理员可以使用一种群集资源快速创建能够承载大量共享的目录，如：主目录。系统会指定根目录共享，指定根目录的下一级的所有子目录都被创建为常规文件共享。

无法为每个共享子目录分别指定不同的安全属性，因此每个共享都继承与根目录共享相同的共享级权限。由于各个共享通常都由不同的用户使用，因此应该对每个人分别授予共享级权限，并且应在文件系统级别使用基于文件的安全性来控制哪些人能够访问哪些文件。

DFS 根目录

DFS 根目录在 Windows 2000 以后的版本中可用。服务器群集仅支持将独立的 DFS 根目录用作群集资源4：可以通过群集管理器用户界面来使用根目录的共享级权限，并且可以通过相应服务器上的文件共享权限来管理每个链接。不过，这种控制访问的方法对于跨越许多服务器和链接的 DFS 树可能很难实现。建议您通过将文件共享级权限保留为开放来管理 DFS 树，并使用 NTFS 文件系统权限限制访问。

作为域控制器的群集服务器节点

为使服务器群集正常工作（其中每个节点上都启动群集服务），组成群集的节点必须能够验证群集服务域帐户，该帐户是您配置群集时所设置的帐户。为此，每个节点都必须能够与域控制器建立安全通道，以验证此帐户。如果无法验证此帐户，群集服务将无法启动。对于必须验证帐户才能启动服务的其他群集程序（如：Microsoft SQL Server 和 Microsoft Exchange）也是如此。

如果群集部署与 Windows NT 4.0 域、Windows 2000 域或 Windows Server 2003 域之间都没有链接，则必须将群集节点作为域控制器配置，以便总能够验证群集服务帐户，使群集功能得以正常运行。

如果群集节点和域控制器之间的连接速度较慢或不可靠，应考虑使域控制器与群集共存，或将群集节点配置为域控制器。Microsoft 不推荐把群集节点用作域控制器。

如果必须将群集节点配置为域控制器，请注意以下重要说明：

•

如果双节点群集中的一个群集节点是域控制器，则所有节点都必须是域控制器。建议您将四节点数据中心群集中的至少两个节点配置为域控制器。

•

运行域控制器将涉及开销。闲置的域控制器可能占用 130 到 140 MB 的内存，其中包括运行服务器群集所需的内存。如果这些域控制器必须与域内或域外的其他域控制器进行复制，还存在复制流量问题。大多数公司群集部署中的节点都有上 GB 的内存，因此这通常不成问题。

•

如果 Windows 2000 群集节点是唯一的域控制器，则都必须是 DNS 服务器，而且应指向对方进行主 DNS 解析，并指向自身进行辅助 DNS 解析。您必须解决如何才能不在 DNS 中注册专用接口这个问题，有其当通过交叉电缆建立连接时（仅对双节点而言）。有关如何配置信号检测接口的信息，请参见知识库文章 258750。不过，在贯彻知识库文章258750之前，您必须先修改其他配置设置，知识库文章 275554 概述了这些设置。

•

如果群集节点是唯一的域控制器，则必须是“全局目录”服务器，或者您必须实施 domainlet（小域）。有关实施 domainlet 的更多信息，请参见下面 Microsoft 网站中的以下文档：

http://www.microsoft.com/windows2000/techinfo/administration/cluster/domainlets.asp

•

森林中的第一个域控制器承担所有灵活的单主机操作角色（请参见知识库文章 192132）。您可以将这些角色重新分配给各个节点。但是，如果节点进行故障转移，该节点所承担的灵活的单个主机操作角色将不再有效。您可以使用 Ntdsutil 强行移走角色，并将其分配给仍在运行的节点（请参见知识库文章 223787）。有关灵活单一主机操作角色在域中的位置的信息，请查看知识库文章 223346 。

•

如果域控制器太忙，导致群集服务在需要时无法访问仲裁驱动器，则群集服务可能会将这种情况解释为资源故障，并导致群集组故障转移到其他节点。如果仲裁驱动器位于其他组中（尽管不应该是这样）并且被配置为影响组，那么如果出现故障，所有的组资源可能都会移到其他节点，而这可能不是您所希望的。有关“仲裁”配置的更多信息，请参见“参考资料”部分中列出的知识库文章 280345 。

•

当节点同时也是域控制器的情况下，由于资源限制，集聚 SQL 或 Exchange 等其他程序可能不会产生最佳性能。在部署此配置之前，应该在实验室环境中对其进行彻底测试。

•

在创建服务器群集或向群集添加节点之前，必须通过使用 Dcpromo 工具将群集节点提升为域控制器（有关更多信息，请参见知识库文章 247720）。

•

将同时身为群集节点的域控制器降级时，要非常小心。将域控制器降级为节点时，安全设置和用户帐户会彻底更改（例如，用户帐户被降级为本地帐户）。如果要降级同时身为群集节点的域控制器，请参见知识库文章 247720。

通用资源

使用通用资源类型（通用应用程序、通用服务和通用脚本 5），可以很轻松地监控现有的不支持群集的应用程序并对它们进行故障转移。文件名路径被用来标识应用程序或脚本。群集服务在群集服务帐户下运行资源 DLL，因此它们以提升的（本地管理员）特权运行。

在使用通用资源时，应确保包含代码/脚本和由脚本、应用程序或服务使用的任何注册表项的文件不会受到攻击。

•

通用脚本

•

确保使用 NTFS 文件系统保护来保障脚本文件的安全。

•

为脚本指定完全限定的路径，以避免出现与 PATH 变量有关的入侵问题。

•

通用应用程序

•

确保应用程序受信任，并且需要进行检查点操作的文件、注册表项以及运行应用程序所需的任何其他资源都是安全的。

•

为应用程序指定完全限定的路径，以避免出现与 PATH 变量有关的入侵问题。

•

通用服务

•

确保服务受信任，并且运行服务所需的任何注册表项或其他资源都是安全的。

请注意：通常，Windows 服务的参数和配置被存储在注册表的 HKEY_LOCAL_MACHINE 中。本文假定该注册表配置单元已受到保护，不会遭到攻击。HKLM 配置单元的默认安全属性可确保该配置单元的安全。

安全属性总结

本节概述了为确保群集服务成功运行所需的各种对象及其所关联的安全属性。并列出了最低的安全要求。如果设置的安全属性限制性较高，群集服务可能无法运行。如果安全属性限制性较低，可能导致出现恶意攻击，危害群集的安全或损坏最终用户数据。建议您不要更改对象安全属性的默认设置。

目录和文件保护

对象描述推荐的最低安全属性

%windir%\help

群集帮助文件

BUILTIN\Users:R
BUILTIN\Administrators:F

%windir%\cluster

群集目录（和子目录）

BUILTIN\Administrators:F

BUILTIN\Administrators:(OI)(CI)(IO)F

NT AUTHORITY\SYSTEM:F

NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F

CREATOR OWNER:(OI)(CI)(IO)F

%windir%\cluster\*

群集目录中的文件

BUILTIN\Administrators:F

NT AUTHORITY\SYSTEM:F

<quorum_drive>

包含仲裁数据的卷

BUILTIN\Administrators:F

BUILTIN\Administrators:(OI)(CI)(IO)F

NT AUTHORITY\SYSTEM:F

NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F

<quorum_drive>:\MSCS

仲裁目录（和子目录）

BUILTIN\Administrators:F

BUILTIN\Administrators:(OI)(CI)(IO)F

CREATOR OWNER:(OI)(CI)(IO)F

<quorum_drive>:\MSCS\*

仲裁目录中的文件

BUILTIN\Administrators:F

群集磁盘上的卷

BUILTIN\Administrators:F

BUILTIN\Administrators:(OI)(CI)(IO)F

NT AUTHORITY\SYSTEM:F

NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F

系统资源

群集服务使用默认情况下受保护的其他系统资源。

对象描述推荐的最低安全属性

HKLM\*

HKLM 注册表配置单元

SYSTEM:完全控制

BUILTIN\Administrators:完全控制

群集服务帐户策略

•

不要让密码过期。在 Windows Server 2003 中，可以使用密码更改机制确保密码定期循环。

•

对群集服务帐户使用强密码。

Active Directory

•

要确保 Kerberos 身份验证能够按预期的方式工作，群集服务帐户必须能够访问 Active Directory。“在服务器群集中使用 Kerberos 身份验证”一节讨论了这方面的内容。

DNS

•

群集服务帐户需要能够发布记录。在由 DNS 支持的安全区域中，DNS 管理员可以选择限制用户的访问权限。必须授予群集服务帐户创建记录的权限，或者可以预先创建记录。如果预先创建记录，则不应该将区域设置为动态更新。

多数节点集注意事项

Windows Server 2003 提供了一种新的能够进行仲裁的资源，称为多数节点集。此资源的主要目的是保持群集中数据的多个副本永远同步。可使用其在群集中提供仲裁资源，而不使用仲裁数据的共享磁盘，主要针对以下情况：

•

地理上分散的群集 – 为多站点群集配置提供一个通用的仲裁机制，以使供应商能够生成解决方案，而无须考虑仲裁要求。

•

设备群集 – 一组现成的计算机，它们没有对应用程序和/或用户数据使用某种其他的数据复制方法，将共享磁盘绑定到单个群集中。

在多数节点集群集中，存在一种多数节点集资源。它负责提交对每个群集节点上存储的仲裁数据的更改。每个群集节点都有自己的仲裁数据副本。为了访问群集中其他节点上的仲裁数据（即承载资源的节点以外的节点），多数节点集资源使用文件共享基础结构。创建多数节点集资源时，将在每个群集节点（以及添加到群集中的节点）上创建一个文件共享。

此文件共享是隐藏的文件共享，其名称结构如下所示：

\\<node_name>\<resource_GUID>$

此文件共享的默认安全设置为：

BUILTIN\Administrators:F（此文件夹、子文件夹和文件）CREATOR OWNER:F（仅限于子文件夹和文件）

确保多数节点集群集的正确运转：

•

不要删除此文件共享。

•

不要从能够访问此共享的帐户组中删除群集服务帐户。

•

不要更改此文件共享的默认访问控制

•

文件共享目标是 %windir%\Cluster\MSCS 目录中的目录。不要更改文件或目录的默认访问权限。

•

永远不要将其他文件放入 MNS 目标目录 %windir%\Cluster\MSCS\MNS.<guid-representation> 中。如果将其他文件放入该目录，在删除 MNS 资源后进行清理时，它们将被删除。

升级到 Windows Server 2003 时的注意事项

Windows 2000 和 Windows NT4 的默认安全属性存储在 %windir%\Cluster 目录和仲裁目录中，这两个目录允许任何已通过身份验证的用户读取其中的内容。在 Windows Server 2003 中，这两个目录的安全性已得到加强，以防止非管理员用户访问，并确保未经授权的用户无法获取有关群集配置的信息。但是，在升级到 Windows Server 2003 时，这些安全属性不会修改，因此在升级后的 Windows Server 2003 计算机上，所有通过身份验证的用户可能都具有对这两个目录的读取权限。您可能需要考虑手动设置权限，以符合最低的访问要求。

开发识别群集的应用程序

资源 DLL 在群集服务帐户上下文中运行。此帐户具有许多提升的特权，并且在群集中的每个节点上该帐户都属于本地管理员组的成员。开发识别群集的应用程序时，应考虑如何以最佳的方式将应用程序在资源 DLL 和独立服务或可执行文件之间进行拆分，以确保该应用程序能够以最少的特权和必需的权限运行。

以不必要的权限级别运行应用程序和服务时，如果该应用程序的安全受到威胁，将会引起潜在的安全风险。

调用服务器群集 API

服务器群集 API 是受保护的，使任意不受信任的用户不能影响群集的状态或应用程序的可用性。群集服务维护一个安全描述符以便控制访问。只有属于安全描述符的帐户才能调用群集 API（实际上，安全描述符控制哪些帐户能够打开群集的句柄，由于其他群集服务器 API 需要群集的句柄，因此这可以有效地限制访问）。

使用此机制时有一点需要注意。Windows Server 2003 中提供的群集配置机制要求向群集中添加节点的用户必须在群集中的每个节点上都具有本地管理员权限。如果用户在现有群集节点上没有本地管理员权限，则该用户无法将新节点成功添加到群集中。因此，为了赋予帐户对群集的管理权限，您应该：

1.

将该帐户添加到群集服务安全描述符中。

2.

确保该帐户在群集中的所有计算机上都属于本地管理员组的成员。

这些操作可以通过使用群集 API 和安全性 API 以编程方式完成。有关更多详细信息，请参见 Platform SDK。

安全检查通过 OpenCluster API 予以实现。如果调用成功返回，说明调用方具有有效的句柄并且能够任意更改群集配置或枚举群集配置。没有以可读方式打开或以可写入方式打开的概念。

备份/恢复 API

指定的备份 API 的备份路径应该受到保护。此 API 返回的数据中包含群集配置信息，这些信息可能被用于扩大攻击面（例如，列出所有群集 IP 地址）。

在恢复操作中，备份 API 接受要注入的群集配置。这些数据必须受到保护，因为它们将用于通过覆盖当前存在的任何配置来恢复群集。

安装资源

识别群集的应用程序可以安装群集资源。安装资源时要小心，因为它们将以提升的特权执行，因此安装时，默认情况下必须保护它们不受恶意行为的攻击：

•

确保资源 DLL 在文件系统级别受到保护，只允许本地管理员和群集服务帐户访问。

•

对于指定的任何路径都要非常小心。关于路径存在几个已知问题，特别是包含空格的路径（请遵照 419 页上“编写安全代码”中的建议操作）。创建资源类型时，如果没有把握，应指定完全限定的资源 DLL 路径。

1对于 MSMQ 所需的网络名称，默认情况下将启用 RequireKerberos，以确保在升级完成后 MSMQ 能够继续按预期的方式工作。

2群集中的所有节点必须位于同一 NT 和 DNS 域中。

3在整个 Windows Server 2003 域中，这将按预期的方式工作。

4注意，这并不意味着您无法在群集节点上创建域根目录，因为群集节点就像任何其他服务器一样，但是它们不是群集资源。

5通用脚本仅在 Windows Server 2003 中可用


返回页首返回页首