服务器群集：Windows 2000 和 Windows Serv ……

[71419] 主题：服务器群集：Windows 2000 和 Windows Serv ……

	作者： little (渺小)
	标题：服务器群集：Windows 2000 和 Windows Serv ……[转载]
	来自： 211.154..
	发贴时间： 2003年07月12日 00:19:21
	长度： 37690字

	http://www.microsoft.com/china/TechNet/prodtechnol/windowsnetser ver/maintain/ security/SRCLSCBP.asp 服务器群集：Windows 2000 和 Windows Server 2003 安全性最佳做法 Microsoft Corporation 发布时间：2003 年 7 月 8 日摘要本文介绍与服务器群集安全性相关的最佳做法。本文提供了与服务器群集的管理、操作和编写应用程序相关的准则和最佳做法，适用于 Windows 2000 及更高版本。本文分两部分介绍安全性最佳做法：一部分针对负责部署和管理服务器群集的管理员，一部分针对负责编译识别群集的应用程序或将要部署在群集上的应用程序的开发人员。一般性假设应该为基础结构设置一些一般性假设和可行的最佳操作，以确保服务器群集运行环境的安全。服务器和存储器应处于真正安全的位置。设置检测不规则通信的实用安全实现，例如防火墙、网络探测和管理工具。在类似管理、日志存储、备份和恢复这样的领域，坚持安全方面的最佳做法/常识。在分配管理权限、ACL 资源和其他内务处理角色方面，坚持平台级安全性最佳做法。 Active Directory、DNS、DHCP、WINS 等网络基础结构服务必须是安全的。任何危及这些基础结构服务安全的做法均可导致危及群集服务自身的安全。群集管理员必须确保在受信任的计算机上运行调用群集 API (ClusAPI) 的应用程序。危及执行这些应用程序（由群集管理员运行）的计算机的安全均可危及群集的安全。例如，如果在运行管理工具的工作站上存在具有提升权限的不受信任的用户，群集管理员可能会在本人毫无察觉的情况下对群集运行不可信代码或恶意代码。对于由群集服务创建和维护的对象集，切勿将这些对象的默认设置调整为限制较少的设置，以免危及它们的访问安全。群集服务可利用操作系统中的一系列对象，例如文件、设备、注册表项等。这些对象都具有默认的安全设置，可确保非特权用户无法影响群集配置或群集上运行的应用程序。将这些安全设置改为限制较少的安全设置可能导致危及群集的安全并损坏应用程序数据。部署与操作管理群集管理员管理员可以指定组或个人，允许他们对群集进行管理。在服务器群集的当前版本中，控制的精度并不高；用户要么具有管理群集的权限，要么不具有这些权限。要授予用户或组管理群集的权限，必须将该用户或组添加到群集安全描述符中。此操作可以由群集管理员或通过 cluster.exe 命令行工具来完成。备注除节点上的本地管理员组外，群集安全配置的所有其他成员还必须是域用户帐户或全局组。这是为了确保帐户在群集中的所有节点上都相同、已正确定义并已授权。默认情况下，本地管理员组会添加到群集服务安全描述符中。将用户或组添加到群集安全描述符中意味着该用户可以管理该群集配置的所有方面，其中包括（但不限于）：使资源脱机和联机关闭节点上的群集服务向群集中添加节点或从群集中删除节点向群集中添加资源或从群集中删除资源由于群集中运行的应用程序和服务的影响范围，在向群集安全描述符中添加用户时必须特别注意。群集服务可运行与群集服务域用户帐户（不要将该帐户与用于管理该群集的帐户相混淆）下的资源关联的代码。由于群集管理员可以向群集添加新的资源，而且这些资源作为群集服务帐户运行，因此群集管理员可以安装那些将用计算机上的本地管理员权限运行的代码。最佳做法群集管理员应使用群集服务帐户以外的其他帐户来管理群集。这会将不同的策略（例如密码过期等）分别应用于群集服务帐户和用于管理群集的域帐户。您应该只将具有本地管理员权限的用户添加到群集服务安全描述符中。备注将域用户或全局组添加到本地管理员组，则该组或帐户将自动成为群集管理员。不要将本地管理员组从群集服务安全性配置中删除。远程管理和配置群集调用服务器群集 API (ClusAPI) 的管理工具或其他应用程序可在远程工作站上运行。常规假设是群集管理员必须确保在受信任的计算机上运行这些应用程序。对正在执行这些应用程序（由群集管理员运行）的计算机的任何妥协方案均可危及群集的安全。当创建群集或者更改配置（例如添加新的群集节点）时，“群集配置向导 ”将在运行该向导的计算机上创建一个日志文件，以便在出现故障时，管理员可以使用日志进行调试和排除故障。日志文件可包含群集配置数据，例如群集 IP 地址、网络名称等。如果未经授权的用户读取了数据，则此数据就可能被用来扩大攻击面。群集服务帐户群集服务帐户是用来启动群集服务的帐户。该帐户的凭据存储于服务控制管理器 (SCM) 中，服务控制管理器 (SCM) 是一个 Windows? 组件，它负责在群集节点引导时启动群集服务。群集服务帐户在群集中的所有节点上都必须相同，而且必须是域级帐户，对群集中的每个节点都具有本地管理权限。必须存在域帐户才能创建群集，“群集配置向导”将提示您输入要使用的现有帐户。如果该帐户尚不是本地管理员组的成员，在创建群集时“群集配置向导”会自动将该帐户添加到本地管理员组中。同样，将节点添加到群集时，群集服务帐户也将被添加到本地管理员组中。如果节点从群集中脱离或最后一个节点被删除，并不会从本地管理员组中删除群集服务帐户。您需要知道这些语义，以免不小心将域帐户本地管理员权限授予一组假设的节点。备注从群集中脱离节点时不会将群集服务帐户从本地管理员组中删除。将节点从群集中删除后，应当手动将群集服务帐户从本地管理员组中删除，以免接纳对计算机具有本地管理员权限的过期帐户。服务器群集中的节点可使用经过身份验证的通信机制，以确保在群集内的协议中只有该群集的有效成员可以参与。群集中每个节点都具有相同的群集服务帐户是非常重要的，因为这样才能提供身份验证的一致性。这也是 Microsoft? Windows Serv er 2003 中引入的群集服务帐户密码实用程序的要求。必需的权限除了作为本地管理员组的成员外，群集服务帐户还需要一组附加的、本地授予的权限：充当操作系统的一部分（Windows 2000 和更高版本中需要）。备份文件和目录。增加配额。增加调度优先级。加载和卸载设备驱动程序。将页锁定在内存中。以服务登录。还原文件和目录。不能从群集服务帐户中删除任何这些权限。如果删除这些必需权限中的任何权限，群集服务可能无法启动或正确操作。在设置群集服务器过程中，这些权限会在本地授予帐户。无论何时需要手动重新创建群集服务帐户，都必须授予这些附加权限。知识库文章 269229：How to Ma nually Re-Create the Cluster Service Account（如何手动重新创建群集服务帐户）描述了重新创建群集服务帐户所需的步骤。密码策略群集服务帐户与任何其他域帐户都类似，它也具有密码，而且密码也可以与密码过期策略相关联。如果已为密码分配了过期策略，则在群集帐户密码过期前必须更改该密码。否则，当密码过期时将造成群集停止工作（因为无法再对群集内通信成功进行身份验证）。更改密码在大多数产品部署中，域帐户都具有密码过期策略，强制相对频繁地更改密码（例如每 30 天）。更改群集帐户密码需要仔细规划。 Windows 2000 群集中所有节点上的群集服务帐户都必须匹配，以确保可以成功地对群集内通信进行身份验证。在各种条件下群集服务本身会在群集节点之间发送消息，如果这些通信中的任何一个失败，群集节点将从群集中被删除（即群集服务将被停止）。不可能确定群集服务何时建立通信，因此没有明确的窗口可用来以可靠的方式更改群集服务帐户，同时确保群集仍然运行。在 Windows 2000 中，只能使用以下步骤可靠地更改群集帐户密码：停止群集中所有节点上的群集服务更改域控制器中的群集服务帐户的密码更新所有群集节点上的服务控制管理器密码重新启动所有群集节点上的群集服务 Windows Server 2003 Windows Server 2003 中的 cluster.exe 命令能够动态地更改群集帐户密码，而无须关闭任何节点上的群集服务。cluster.exe 命令可更改域帐户密码并更新群集中所有节点上的服务控制管理器帐户信息。备注此命令仅适用于 Windows Server 2003 节点。如果群集中有任何 Windows 2000 节点，则这些节点的群集服务帐户密码将不被更改。 Cluster /cluster:cluster_name1 /changepassword] 这些命令参数具有下列含义：参数说明 cluster:cluster_name1 标识要更改帐户密码的群集。如果指定了多个群集，则这些群集必须使用相同的群集服务帐户。如果某些节点不可用，在所有节点或域控制器上的密码都不会更改。 /changepassword ] 将域控制器和所有群集节点上的群集服务帐户密码从 old_password 更改为 new_password。如果命令行中没有提供密码，将会提示您提供密码。 /skipdc 只更改群集节点上的群集服务帐户密码。 /force 强制更改可用节点上的密码，即使某些节点不可用。备注不可用节点上的密码将不被更新。在使用计算机管理手动更新这些节点上的群集服务帐户密码之前，这些节点将无法加入群集。 “群集管理器”工具的联机帮助文档中介绍了该命令的详细信息。最佳做法群集服务帐户不能是域管理员帐户。应该授予所有帐户尽可能少的权限和特权，以免给定帐户泄漏时出现潜在的安全问题。使用委派为群集中所有节点上的特定帐户授予管理权限。如果单个域中有多个群集，在所有节点上使用同一群集服务帐户可简化管理工作。对多个群集使用单个帐户既可以简化管理，同时又带来潜在的安全风险，您需要在这二者之间做出权衡。如果帐户泄漏，受影响的范围取决于涉及到多少个群集。使用 Windows Server 2003，可以同时更改多个群集中的群集服务帐户密码。如果已经在群集服务帐户上设置了密码过期策略，则不应对其他服务使用此帐户。例如，如果已经设置了密码过期策略，不要对 SQL Server 2000 或 Exch ange 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 允许在所有 We b 服务器到数据库的所有层之间执行原始客户身份验证，以实现端到端的身份验证和授权。它是一种允许在多个平台之间实现通用身份验证机制的工业标准。有关 Kerberos 及其工作原理的详细信息，请访问 TechNet Web 站点：h ttp://www.mic rosoft.com/technet/treeview/default.asp?url=/TechNet/tcevents/it events/kerber os.asp 在服务器群集中，应用程序部署在虚拟服务器中。虚拟服务器是一个服务器群集资源组，它包含 IP 地址资源和网络名称资源以及给定的服务或应用程序所需的任何资源。客户端使用与服务关联的 IP 地址或网络名称连接到群集服务。当应用程序从一个节点故障转移到另一个节点时，IP 地址和网络名称资源也会相应地转移过去，因此，不论客户端当前是由群集中的哪台计算机承载的，客户端都将继续使用服务或应用程序原来的目标位置。对于 Windows 2000（SP2 以下）中的服务器群集，可用于根据虚拟服务器名称对客户端进行身份验证的唯一机制是 NTLM，因此 Kerberos 提供的好处对于包含服务器群集的部署不可用。在 Windows 2000 SP3 和 Windows Server 2003 中，Kerberos 身份验证将可用于群集服务器应用程序，允许在高度可用的部署中实现端对端模拟。虚拟服务器计算机对象 Kerberos 身份验证需要在 Active Directory 中发布一个后备计算机对象 (CO)。在 Windows 2000 SP3 和更高版本中，网络名称群集资源可以在 Active Dir ectory 中为虚拟服务器发布计算机对象。这是通过新资源属性 RequireKerberos 的下列值控制的： RequireKerberos = 0 网络名称资源不在 Active Directory 中创建对象。这提供了与 Windows 2000（SP2 以下）相同的语义，并且是默认值，可确保实现向后兼容以及滚动升级过程中的正确操作1 。 RequireKerberos = 1 网络名称资源在 Active Directory 中创建对象，从而能够根据虚拟服务器计算机名称进行 Kerberos 身份验证。本节的稍后部分将介绍此属性的完整语义。备注虽然网络名称资源在 Active Directory 中发布计算机对象，但是不应该将此计算机对象用于管理任务，如应用组策略。Windows 2000 和 Windows Serv er 2003 中虚拟服务器计算机对象的唯一作用就是使识别群集和 Active Directory 的服务（例如 MSMQ）能够使用 Kerberos 身份验证和委派，以发布服务提供程序信息。计算机对象的寿命网络名称资源根据某些因素（包括资源属性设置和资源自身的寿命）控制计算机对象的创建和删除。创建计算机对象当 RequireKerberos 资源属性设置为 1（默认值为 0）时，网络名称资源将创建计算机对象。将此值设置为 1 要求群集服务帐户必须能够访问 Active Directo ry，这可以通过具有将工作站添加到域特权或授予访问 Active Directory 的特定权限来实现。如果帐户没有访问权限，则网络名称资源将无法联机。域管理员可以预先为虚拟服务器（在独立的组织单位中，如果需要）创建计算机对象，以免将将工作站添加到域特权授予群集帐户。在这种情况下，计算机对象必须有一个存取控制单元 (ACL)，以允许群集服务帐户重新设置密码并写入 DnsHostNa me 和 ServicePrincipalName 属性（它们有单独的访问权限）。如果与虚拟计算机名称对应的 Active Directory 中存在孤立计算机对象或由域管理员创建的计算机对象，同时群集服务帐户具有该对象的访问权限，而且该对象没有禁用，则网络名称资源将截获该现有计算机对象。如果向域中添加新计算机，而该域包含具有相同名称的旧的、并且未使用的计算机对象，则会出现同样的问题。网络名称资源将计算机对象的 DnsHostName 属性设置为网络名称资源 Na me 属性的完全合格的 DNS 名称加上节点的主 DNS 后缀2。禁用计算机对象当不再需要 Kerberos 身份验证（RequireKerberos 属性由 1 变为 0）或者当资源本身被删除时，计算机对象将被禁用。如果计算机对象仍然存在，但是网络名称资源在没有启用 Kerberos 身份验证的情况下联机，则客户端身份验证将失败。当从网络名称资源中删除 Kerberos 身份验证时，系统管理员必须删除相应的计算机对象。注意，虚拟服务器中驻留的识别 Active Directory 的应用程序（例如 Exchange Serv er 和 MSMQ）可能已将它们自己的信息附加到计算机对象。如果删除计算机对象，那些属性也将被删除，应用程序可能无法再正常运行。从网络名称中删除 Kerberos 身份验证时要十分小心。当删除网络名称资源或 Kerberos 身份验证时，网络名称资源会尽量一次性禁用计算机对象。所有禁用操作及其最后的状态都将记录到群集和系统事件日志中。如果由于任何原因禁用计算机对象失败，将不再尝试禁用。重命名计算机对象计算机对象与网络名称资源公开的虚拟网络名称联系密切。如果更改网络名称资源的 Name 属性，这种更改一定会在计算机对象中反映出来。这些变化是紧密搭配并且是同步的，因此，仅当网络名称资源脱机时才能更改 Name 属性。如果由于任何原因重命名计算机对象失败，对 Name 属性的更改也将失败。此处有一点需要注意：当网络名称资源联机时允许更改其属性值；在这种情况下，重命名操作将被推迟，直到名称脱机。如果重命名尝试失败，作为联机过程的一部分将重试此操作。名称不会联机，直到重命名操作成功。备注诸如 MSMQ 和 SQL Server 等许多应用程序和服务都不支持更改网络名称资源的 Name 属性。密码轮换当颁发 Kerberos 票证时计算机对象维护用于身份验证的密码。在最新的 Windows 2000 SP3 和 Windows Server 2003 实现中，在计算机对象创建之后，其中的密码将不会更改。警告、问题和注意事项孤立计算机对象许多操作系统服务和应用程序都使用协商安全程序包，它是 Windows 平台提供的一个组件，允许客户端通过某项服务进行身份验证。此程序包隐藏任何给定身份验证方案的细节，并且允许客户端尝试 Kerberos 身份验证，如果 Kerberos 身份验证不可用，则恢复到 NTLM 身份验证。如果 Active Directory 中有一个计算机对象与客户端正在使用的目标名称相对应，则协商程序包将假定 Kerberos 身份验证是必需的 3。如果 Active Directory 中存在虚拟计算机对象（已禁用或未禁用），则将来与该虚拟服务器名称的客户端连接不会恢复到 NTLM。如果对虚拟服务器的身份验证失败，并且该虚拟服务器使用的应该是 NTL M，那么应检查与该虚拟服务器名称对应的 Active Directory 中是否有孤立或旧的计算机对象。识别群集和识别 Active Directory 的服务有些服务既识别群集又识别 Active Directory，例如 SQL Server 2000、 Exchange 2000 和 MSMQ。其中有些服务会将服务信息附加到计算机对象。例如，MS MQ 会将服务信息附加到虚拟服务器计算机对象。从网络名称资源中删除 Kerberos 身份验证时，计算机对象将被禁用，系统管理员必须明确决定是否删除计算机对象。如果计算机对象被删除，由识别 Active Directory 的应用程序附加的属性也将被删除，从而导致应用程序可能无法再正常运行。从网络名称资源中删除 Kerberos 身份验证时要格外小心。 Active Directory 复制延迟到目前为止，我们都是将 Active Directory 作为一个高度一致的基础结构进行讨论的。在生产环境中，会部署多个域控制器以确保域基础结构高度可用。对 A ctive Directory 的更改会在多个节点之间复制，有些情况下复制延迟时间可能很长。这可能导致出现一些看上去不一致的情况，这是您需要注意的：客户端无法看到网络名称资源的计算机对象不同的节点可能访问不同的域控制器。如果在某个域控制器上创建计算机对象，客户端可能无法看到该对象，直到它被复制到其他域控制器。最佳做法在群集中使用 Kerberos 身份验证时，请仔细规划：在那些对您的部署有意义的虚拟服务器上启用 Kerberos 身份验证。除非您完全理解使用虚拟服务器的服务以及虚拟服务器对该服务的影响，否则不要禁用虚拟服务器上的 Kerberos 身份验证。计算机对象和附加到其中的任何服务信息都将被删除（假设有正确的特权），这可能导致服务不可用或无法恢复。群集服务帐户应具有将工作站添加到域特权，以允许该帐户在 Active D irectory 中创建计算机对象。如果您不想将该特权授予群集服务帐户，必须在启用 Ker beros 身份验证之前在 Active Directory 中手动创建计算机对象。备注将工作站添加到域特权允许从该帐户创建 10 个默认的计算机对象。另外，将工作站添加到域本身不允许删除该帐户或重命名计算机对象。群集服务帐户应该具有写入所有属性访问权限，以允许该帐户重命名计算机对象。许多服务（包括 MSMQ 和 SQL Server 2000）都不支持更改网络名称资源的 Name 属性。仅当您完全理解更改此属性的含义时，才能更改此属性。有些情况下，更改网络名称资源的 Name 属性可能导致数据丢失或服务失败。在允许客户端访问新创建的与网络名称资源相关联的计算机对象之前，或将资源故障转移到群集中的其他节点之前，应该确保域控制器有机会复制这些计算机对象。否则，可能导致无法预料的结果（请参阅“Active Directory 复制延迟”一节）。网络安全性网络信息充斥群集服务使用 UDP 端口 3343 进行群集内部通信。这种通信包括检测节点故障和群集控制操作的检测信号通信。这些操作中的某些（例如，检测信号）对时间很敏感。如果由于网络信息充斥攻击，端口负担过重，可能导致检测到错误的节点故障，从而导致不必要的故障转移操作，这将导致应用程序无法运行。端口抢占流氓应用程序可能劫持或“抢占”端口 3343。这将使群集服务无法启动。在这种情况下，唯一的选择就是终止使用此端口的进程。端口 3343 是仅为群集服务注册的。流氓服务器群集服务通过群集 API 提供远程管理功能，以便可以从管理站管理群集。群集 API 使用 NTLM 进行服务器身份验证。这使服务器能够验证客户端是否具有足够的权限和特权来管理群集，但是它不提供相互身份验证。也就是说，客户端不能完全确保它连接到的节点或群集是真正的群集。如果流氓计算机使用相同的 IP 地址或网络名称出现在网络上（如果 DNS 信息的安全被打破），则该流氓计算机可能会伪装成群集。如果该流氓计算机看起来还实现了群集服务 API，则发送到群集的任何管理命令都将被该流氓计算机截获。许多情况下，这并不代表威胁的存在，因为管理员只会收到一个虚假的关于操作是否已执行的报告。但是，在有些敏感的操作（例如，更改群集配置）中，未经授权的接收方可能潜在地收集群集配置数据，而这可能会助长扩大攻击面。这种类型的攻击需要许多因素才可能发生：必须能够在与目标群集相同的子网中看到流氓计算机，并且流氓计算机必须能够响应群集 IP 地址的通信（这可能是物理计算机的 IP 地址，也可能是此计算机承载的虚拟服务器的 IP 地址）。在典型环境中，只有群集节点或虚拟服务器没有运行时，流氓计算机才能占用它们的 IP 地址。流氓计算机看起来必须实现群集 API。对于典型的管理操作，客户端应用程序对服务器进行多次调用，有些情况下，将返回后续调用的句柄。管理员/操作过程必须更改包括机密数据的配置（例如，管理员必须更改群集帐户密码）。最佳做法危害群集安全的攻击通常与群集位于同一子网上。要防止这些攻击，应该保护子网：客户端访问网络群集节点使用的子网不应超出节点集（可以受到物理保护或受信任）。必须确保流氓或潜在不安全的计算机无法挂接到包含群集的子网。由于此网络可能包括域控制器、DNS 服务器、WINS 服务器、DHCP 服务器和其他网络基础结构，所以您必须采取措施以确保这些结构服务器也是安全的。典型的网络安全步骤应该到位，如只允许特定应用程序请求的防火墙等。保护网络和基础结构服务器的安全不在本文档的讨论范围之内。专用网络在专用网络中应该只能看到群集中的节点（多个群集可以使用同一个专用网络）。其他网络基础结构服务器或其他应用程序服务器不应该位于专用子网上。这可以通过以下两种方法之一来实现：物理限制网络本身（例如，专用网络是只连接到群集节点的局域网）。使用支持虚拟局域网的交换机隔离群集专用网络。 NTLM V1 和 NTLM V2 Windows 2000 Windows 2000 群集（SP2 之前和 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 并不是为故障转移设计的，因此建议您不要将 IPSe c 用于服务器群集中的应用程序。主要问题是如果发生故障转换，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，您必须执行许多任务，以正确配置环境：只有当虚拟服务器已启用 Kerberos 时，才能在文件共享上启用 EFS。默认情况下，虚拟服务器上不启用 Kerberos。要启用 Kerberos，您必须选中网络名称资源（将用于连接到群集文件共享）中的“启用 Kerberos 身份验证”复选框。备注在选中此复选框之前，应该确保已完全了解对网络名称启用 Kerb eros 的诸多含义。必须信任所有群集节点计算机帐户以及虚拟服务器计算机帐户进行委派。请参见联机帮助了解操作方法。为了确保用户的私钥可以用于群集中的所有节点，必须为要使用 EFS 存储数据的用户启用漫游配置文件。请参见联机帮助了解如何启用漫游配置文件。创建群集文件共享并执行上述的配置步骤后，可以将用户数据存储在加密的文件中，以增强安全性。管理群集中的文件共享常规文件共享就安全性而言，常规文件共享是最灵活和最容易理解的一种方法。唯一真正的区别就是您使用群集用户界面而不是 Windows 资源管理器来管理共享级安全。使用标准 Windows 工具（如 Windows 资源管理器）管理群集磁盘上文件的 NTFS 安全设置。有关管理群集文件共享的更多信息，请参阅服务器群集的联机文档。通过群集管理器创建的文件共享与单个节点具有相同的默认保护，除非 A CL 是使用群集管理工具设置的。有关文件共享的默认 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 Serv er 2003 域之间都没有链接，则必须将群集节点作为域控制器配置，以便总是能够验证群集服务帐户，使群集功能得以正常运行。如果群集节点和域控制器之间的连接速度较慢或不可靠，应考虑使域控制器与群集共存，或将群集节点配置为域控制器。Microsoft 不建议将群集节点用作域控制器。如果必须将群集节点配置为域控制器，请注意以下重要说明：如果 2 节点群集中的一个群集节点是域控制器，则所有节点都必须是域控制器。建议您将 4 节点数据中心群集中的至少两个节点配置为域控制器。运行域控制器会涉及到开销。闲置的域控制器可能占用 130 到 140 MB 的内存，其中包括运行服务器群集所需的内存。如果这些域控制器必须与域内或域外的其他域控制器进行复制，还会有复制通信问题。大多数公司群集部署中的节点都有上 GB 的内存，因此这通常不成问题。如果 Windows 2000 群集节点是唯一的域控制器，则它们每一个也都必须是 DNS 服务器，而且它们应指向对方进行主 DNS 解析，并指向它们自身进行辅助 DNS 解析。您必须解决如何才能不在 DNS 中注册专用接口这个问题，特别是当它通过交叉电缆连接时（仅 2 节点）。有关如何配置信号检测接口的信息，请参考知识库文章 25 8750。不过，在执行知识库文章 258750 中的第 12 步之前，您必须先修改其他配置设置，知识库文章 275554 中概述了这些设置。如果群集节点是唯一的域控制器，则它们每一个都必须是“全局目录”服务器，或者您必须实现 domainlet（小域）。有关实现 domainlet 的更多信息，请参考下面 Microsoft Web 站点中的以下文档： http://www.microsoft.com/windows2000/library/operations/cluster/ domainlets.as p 林中的第一个域控制器承担所有灵活的单个主机操作角色（请参考知识库文章 192132）。您可以将这些角色重新分配给各个节点。但是，如果节点进行故障转移，该节点所承担的灵活的单个主机操作角色将不再有效。您可以使用 Ntdsutil 强行移走角色，并将它们分配给仍在运行的节点（请参考知识库文章 223787）。有关灵活单一主机操作角色在域中的位置的信息，请查看知识库文章 223346。如果域控制器太忙，导致群集服务在需要时无法访问仲裁驱动器，则群集服务可能会将这种情况解释为资源故障，并导致群集组故障转移到其他节点。如果仲裁驱动器位于其他组中（尽管不应该是这样）并且被配置为影响组，那么如果出现故障，所有的组资源可能都会移到其他节点，而这可能不是您所希望的。有关“仲裁”配置的更多信息，请参考“参考”部分中列出的知识库文章 280345。当节点同时也是域控制器的情况下，由于资源限制，集聚 SQL 或 Exchan ge 等其他程序可能不会产生最佳性能。在部署此配置之前，应该在实验室环境中对其进行彻底测试。在创建服务器群集或向群集添加节点之前，必须通过使用 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\Administ rators:F BUILTIN\Administrators:(OI)(CI)(IO)F CREATOR OWNER:(OI)(CI)(IO)F <quorum_drive>:\MSCS\* 仲裁目录中的文件 BUILTIN\Administra tors: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 提供了一种新的能够进行仲裁的资源，称为多数节点集。此资源的主要目的是保持群集中数据的多个副本永远同步。可使用它在群集中提供仲裁资源，而不使用仲裁数据的共享磁盘，主要针对以下情况：地理上分散的群集
	========== * * * * * ==========