如果更改安全设置和用户权限分配，可能会出现客户端、服务和程序问题

Windows XP

若要提高对配置错误的安全设置的认识，请使用组策略对象编辑器工具更改安全设置。 使用组策略对象编辑器时，会在以下操作系统上增强用户权限分配：

• Windows XP 专业服务包 2 (SP2)

• Windows Server 2003 Service Pack 1 (SP1)

增强功能是包含本文链接的对话框。 将安全设置或用户权限分配更改为兼容性较低且限制性更强的设置时，将显示该对话框。 如果通过使用注册表或使用安全模板直接更改相同的安全设置或用户权限分配，则效果与更改组策略对象编辑器中的设置相同。 但是，不显示包含本文链接的对话框。

本文包含受特定安全设置或用户权限分配影响的客户端、程序和操作的示例。 但是，对于所有 Microsoft 操作系统、所有第三方操作系统或所有受影响的程序版本，这些示例都不具有权威性。 本文中未包含所有安全设置和用户权限分配。

建议先验证测试林中所有与安全相关的配置更改的兼容性，然后再在生产环境中引入这些更改。 测试林必须以以下方式镜像生产林：

• 客户端和服务器操作系统版本、客户端和服务器程序、服务包版本、修补程序、架构更改、安全组、组成员身份、文件系统中对象的权限、共享文件夹、注册表、Active Directory 目录服务、本地和组策略设置以及对象计数类型和位置

• 执行的管理任务、使用的管理工具以及用于执行管理任务的操作系统

• 执行的操作，例如：

  • 计算机和用户登录身份验证

  • 用户、计算机和管理员重置密码

  • 浏览

  • 在所有帐户或资源域的所有客户端操作系统中使用 ACL 编辑器，为文件系统、共享文件夹、注册表和 Active Directory 资源设置权限

  • 从管理帐户和非管理员帐户打印

Windows Server 2003 SP1

用户权限

以下列表描述用户权限，标识可能导致问题的配置设置，描述为何应应用用户权限，以及为何要删除用户权限，并提供在配置用户权限时可能发生的兼容性问题的示例。

1. 从网络访问此计算机

   1. 背景
      
      能够与基于 Windows 的远程计算机进行交互需要从网络用户右侧访问此计算机。 此类网络操作的示例包括：

      • 在公共域或林中的域控制器之间复制 Active Directory

      • 从用户和计算机向域控制器发出的身份验证请求

      • 访问位于网络上的远程计算机上的共享文件夹、打印机和其他系统服务

      
      
      用户、计算机和服务帐户通过显式或隐式添加或从已授予此用户权限的安全组中删除，从而从网络用户中获取或失去访问此计算机的权利。 例如，用户帐户或计算机帐户可能由管理员显式添加到自定义安全组或内置安全组，或者操作系统可能隐式添加到计算安全组，例如域用户、经过身份验证的用户或企业域控制器。
      
      默认情况下，当计算组（例如“所有人”）或“经过身份验证的用户”以及“企业域控制器”组等计算组在默认域控制器组策略对象 (GPO) 中定义时，用户帐户和计算机帐户将从网络用户处直接访问此计算机。

   2. 有风险的
      
      配置 以下是有害的配置设置：

      • 从此用户权限中删除企业域控制器安全组

      • 删除经过身份验证的用户组或允许用户、计算机和服务帐户用户通过网络连接到计算机的显式组

      • 从此用户权限中删除所有用户和计算机

   3. 授予此用户权限的原因

      • 将此计算机从网络用户授予对企业域控制器组的访问权限满足 Active Directory 复制必须满足的身份验证要求，以便在同一林中的域控制器之间进行复制。

      • 此用户权限允许用户和计算机访问共享文件、打印机和系统服务，包括 Active Directory。

      • 用户使用早期版本的 Microsoft Outlook Web Access (OWA) 访问邮件时需要此用户权限。

   4. 删除此用户权限的原因

      • 可以将其计算机连接到网络的用户可以访问他们有权访问的远程计算机上的资源。 例如，用户需要此用户权限才能连接到共享打印机和文件夹。 如果向 Everyone 组授予此用户权限，并且某些共享文件夹同时配置了共享和 NTFS 文件系统权限，以便同一组具有读取访问权限，则任何人都可以查看这些共享文件夹中的文件。 但是，对于 Windows Server 2003 的新安装，这种情况不太可能发生，因为 Windows Server 2003 中的默认共享和 NTFS 权限不包括“人人”组。 对于从 Microsoft Windows NT 4.0 或 Windows 2000 升级的系统，此漏洞的风险可能更高，因为这些操作系统的默认共享和文件系统权限不像 Windows Server 2003 中的默认权限那样严格。

      • 没有从此用户权限中删除企业域控制器组的有效理由。

      • 通常会删除“人人”组，以支持“经过身份验证的用户”组。 如果删除了“每个人”组，则必须向“已身份验证的用户”组授予此用户权限。

      • Windows NT升级到 Windows 2000 的 4.0 域不会将此计算机从网络用户直接授予“每个人”组、“经过身份验证的用户”组或“企业域控制器”组。 因此，从 Windows NT 4.0 域策略中删除 Everyone 组时，在升级到 Windows 2000 后，Active Directory 复制将失败，并出现“拒绝访问”错误消息。 Windows Server 2003 中的Winnt32.exe通过在升级 Windows NT 4.0 主域控制器 (电脑) 时向该用户授予企业域控制器组权限来避免此错误配置。 如果该用户不在组策略对象编辑器中，则向其授予企业域控制器组权限。

   5. 兼容性问题的示例

      • Windows 2000 和 Windows Server 2003：以下分区的复制将失败，并出现监视工具（如 REPLMON 和 REPADMIN 或事件日志中的复制事件）报告的“拒绝访问”错误。

        • Active Directory 架构分区

        • 配置分区

        • 域分区

        • 全局目录分区

        • 应用程序分区

      • 所有 Microsoft 网络操作系统：从远程网络客户端计算机进行用户帐户身份验证将失败，除非用户所属的用户或安全组已授予此用户权限。

      • 所有 Microsoft 网络操作系统：来自远程网络客户端的帐户身份验证将失败，除非帐户所属的帐户或安全组已授予此用户权限。 此方案适用于用户帐户、计算机帐户和服务帐户。

      • 所有 Microsoft 网络操作系统：从此用户权限中删除所有帐户将阻止任何帐户登录到域或访问网络资源。 如果删除了企业域控制器、所有人或经过身份验证的用户等计算组，则必须显式授予此用户对帐户或帐户所属的安全组的权限，以便通过网络访问远程计算机。 此方案适用于所有用户帐户、所有计算机帐户和所有服务帐户。

      • 所有 Microsoft 网络操作系统：本地管理员帐户使用“空白”密码。 域环境中的管理员帐户不允许使用空白密码的网络连接。 使用此配置，可以预期收到“拒绝访问”错误消息。

2. 允许在本地登录

   1. 背景
      
      尝试在基于 Windows 的计算机的控制台上登录的用户 (使用 CTRL+ALT+DELETE 键盘快捷方式) 尝试启动服务的帐户必须在托管计算机上拥有本地登录权限。 本地登录操作的示例包括登录到成员计算机控制台的管理员，或整个企业和域用户的域控制器，这些用户登录到成员计算机以使用非特权帐户访问其桌面。 使用远程桌面连接或终端服务的用户必须在运行 Windows 2000 或 Windows XP 的目标计算机上拥有本地用户的允许日志，因为这些登录模式被视为托管计算机的本地模式。 登录到启用了终端服务器且没有此用户权限的服务器的用户，如果允许通过终端服务用户权限登录，仍然可以在 Windows Server 2003 域中启动远程交互会话。

   2. 有风险的
      
      配置 以下是有害的配置设置：

      • 从默认域控制器的策略中删除管理安全组，包括帐户运算符、备份运算符、打印运算符或服务器操作员以及内置管理员组。

      • 从默认域控制器的策略中删除组件以及成员计算机上和域控制器上的程序使用的服务帐户。

      • 删除登录到域中成员计算机控制台的用户或安全组。

      • 删除本地安全帐户管理器 (SAM) 成员计算机或工作组计算机数据库中定义的服务帐户。

      • 删除通过域控制器上运行的终端服务进行身份验证的非内置管理帐户。

      • 通过“每个人”组显式或隐式添加域中的所有用户帐户，以向“拒绝”登录本地登录权限。 此配置将阻止用户登录到任何成员计算机或域中的任何域控制器。

   3. 授予此用户权限的原因

      • 用户必须在本地拥有允许日志，用户有权访问工作组计算机、成员计算机或域控制器的控制台或桌面。

      • 用户必须有权通过基于 Windows 2000 的成员计算机或域控制器运行的终端服务会话登录。

   4. 删除此用户权限的原因

      • 如果无法限制对合法用户帐户的控制台访问，则可能导致未经授权的用户下载和执行恶意代码以更改其用户权限。

      • 删除本地用户权限上的“允许”日志可防止在计算机的控制台（如域控制器或应用程序服务器）上进行未经授权的登录。

      • 删除此登录权限可防止非域帐户在域中成员计算机的控制台上登录。

   5. 兼容性问题的示例

      • Windows 2000 终端服务器：用户登录到 Windows 2000 终端服务器需要本地用户权限允许登录。

      • Windows NT 4.0、Windows 2000、Windows XP 或 Windows Server 2003：用户帐户必须授予此用户在运行 Windows NT 4.0、Windows 2000、Windows XP 或 Windows Server 2003 的计算机控制台上登录的权利。

      • Windows NT 4.0 及更高版本：在运行Windows NT 4.0 及更高版本的计算机上，如果在本地用户权限上添加“允许”日志，但隐式或显式还向“拒绝”登录授予本地登录权限，则帐户将无法登录到域控制器的控制台。

3. 绕过遍历检查

   1. 背景
      
      绕过遍历检查用户权限允许用户浏览 NTFS 文件系统或注册表中的文件夹，而无需检查 Traverse 文件夹的特殊访问权限。 绕过遍历检查用户权限不允许用户列出文件夹的内容。 它允许用户仅遍历其文件夹。

   2. 有风险的
      
      配置 以下是有害的配置设置：

      • 删除登录到基于 Windows 2000 的终端服务计算机或基于 Windows Server 2003 的终端服务计算机的非管理帐户，这些计算机无权访问文件系统中的文件和文件夹。

      • 默认情况下，从拥有此用户的安全主体列表中删除“每个人”组。 Windows 操作系统和许多程序的设计预期是，任何能够合法访问计算机的人都拥有“绕过”检查用户的权利。 因此，从默认情况下拥有此用户权利的安全主体列表中删除 Everyone 组可能导致操作系统不稳定或程序故障。 最好将此设置保留为默认设置。

   3. 授予此用户权限
      
      的原因 绕过遍历检查用户权限的默认设置是允许任何人绕过遍历检查。 对于经验丰富的 Windows 系统管理员来说，这是预期的行为，他们相应地配置文件系统访问控制列表 (SACL) 。 默认配置可能导致事故的唯一方案是，配置权限的管理员不了解该行为，并期望无法访问父文件夹的用户无法访问任何子文件夹的内容。

   4. 删除此用户权限
      
      的原因 若要尝试阻止访问文件系统中的文件或文件夹，非常关注安全性的组织可能会试图从具有“绕过”检查用户权限的组列表中删除“每个人”组，甚至“用户”组。

   5. 兼容性问题的示例

      • Windows 2000、Windows Server 2003：如果在运行 Windows 2000 或 Windows Server 2003 的计算机上删除了绕过遍历检查用户权限或配置错误，则 SYVOL 文件夹中的组策略设置不会在域中的域控制器之间复制。

      • Windows 2000、Windows XP Professional、Windows Server 2003：运行 Windows 2000、Windows XP Professional 或 Windows Server 2003 的计算机将记录事件 1000 和 1202，如果删除或配置错误，则从 SYSVOL 树中删除所需的文件系统权限时，将无法应用计算机策略和用户策略。
        
         

      • Windows 2000、Windows Server 2003：在运行 Windows 2000 或 Windows Server 2003 的计算机上，当你查看卷上的属性时，Windows 资源管理器中的 “配额 ”选项卡将消失。

      • Windows 2000：登录到 Windows 2000 终端服务器的非管理员可能会收到以下错误消息：

        Userinit.exe应用程序错误。 应用程序无法正确初始化0xc0000142单击“确定”终止应用。

      • Windows NT 4.0、Windows 2000、Windows XP、Windows Server 2003：计算机运行Windows NT 4.0、Windows 2000、Windows XP 或 Windows Server 2003 的用户可能无法访问共享文件夹或共享文件夹上的文件，如果未向用户授予绕过遍历检查用户权限，则可能会收到“拒绝访问”错误消息。
        
        
         

      • Windows NT 4.0：在基于 Windows NT 4.0 的计算机上，删除绕过遍历检查用户权限将导致文件副本删除文件流。 如果向右删除此用户，则从 Windows 客户端或 Macintosh 客户端将文件复制到运行 Macintosh 服务的 Windows NT 4.0 域控制器时，目标文件流将丢失，该文件将显示为仅文本文件。

      • Microsoft Windows 95、Microsoft Windows 98：在运行 Windows 95 或 Windows 98 的客户端计算机上，如果未向经过身份验证的用户组授予“绕过遍历检查用户权限”，则 Net use * /home 命令将失败并出现“拒绝访问”错误消息。

      • Outlook Web Access：非管理员将无法登录到 Microsoft Outlook Web Access，如果未向其授予“绕过”检查用户权限，他们将收到“拒绝访问”错误消息。

安全设置

以下列表标识安全设置，嵌套列表提供有关安全设置的说明，标识可能导致问题的配置设置，描述为何应应用安全设置，然后说明可能要删除安全设置的原因。 然后，嵌套列表为安全设置和安全设置的注册表路径提供符号名称。 最后，提供了配置安全设置时可能发生的兼容性问题的示例。

1. 审核：如果无法记录安全审核，请立即关闭系统

   1. 背景

      • 审核：如果无法记录安全审核设置，则立即关闭系统，确定如果无法记录安全事件，系统是否关闭。 对于受信任的计算机安全评估条件 (TCSEC) 程序的 C2 评估，以及信息技术安全评估的通用标准，需要此设置，以防止审核系统无法记录这些事件时可审核的事件。 如果审核系统失败，系统将关闭，并显示“停止”错误消息。

      • 如果计算机无法将事件记录到安全日志，则在发生安全事件后，可能无法查看关键证据或重要故障排除信息。

   2. 风险配置
      
      下面是一个有害的配置设置：审核：如果无法记录安全审核设置，则会立即关闭系统，并且安全事件日志的大小受“不覆盖事件”的限制 (手动清除日志) 选项、“根据需要覆盖事件”选项或事件查看器中的“覆盖早于天数的事件”选项。 有关运行 Windows 2000、Windows 2000 Service Pack 1 (SP1) 、Windows 2000 SP2 或 Windows 2000 SP3 的原始发布版本的计算机的特定风险的信息，请参阅“兼容性问题示例”部分。

   3. 启用此设置
      
      的原因 如果计算机无法将事件记录到安全日志，则在发生安全事件后，可能无法查看关键证据或重要故障排除信息。

   4. 禁用此设置的原因

      • 启用审核：如果出于任何原因无法记录安全审核，则无法记录安全审核设置会立即关闭系统。 通常，当安全审核日志已满，并且其指定的保留方法是“请勿覆盖事件 (手动清除日志) 选项或覆盖早于 天数 的事件选项时，无法记录事件。

      • 启用“审核：如果无法记录安全审核设置，立即关闭系统”的管理负担可能非常高，特别是如果还打开“不覆盖事件”， (手动清除日志) 安全日志选项。 此设置规定了操作员操作的个人责任。 例如，管理员可以重置组织单位 (OU) 中使用内置管理员帐户或其他共享帐户启用审核的所有用户、计算机和组的权限，然后拒绝重置此类权限。 但是，启用该设置确实会降低系统的可靠性，因为服务器可能会被迫关闭，因为它具有登录事件以及写入安全日志的其他安全事件。 此外，由于关闭不正常，操作系统、程序或数据可能会造成无法弥补的损坏。 虽然 NTFS 保证文件系统的完整性在不重要的系统关闭期间得到维护，但它不能保证当系统重启时，每个程序的每个数据文件仍将处于可用形式。

   5. 符号名称：
      
      CrashOnAuditFail

   6. 注册表路径：

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)

   7. 兼容性问题的示例

      • Windows 2000：由于 bug，运行 Windows 2000、Windows 2000 SP1、Windows 2000 SP2 或 Windows Server SP3 的原始发布版本的计算机可能会在达到安全事件日志的最大日志大小选项中指定的大小之前停止记录事件。 Windows 2000 Service Pack 4 (SP4) 中修复了此 bug。 在考虑启用此设置之前，请确保 Windows 2000 域控制器已安装 Windows 2000 Service Pack 4。
        
         

      • Windows 2000、Windows Server 2003：运行 Windows 2000 或 Windows Server 2003 的计算机可能会停止响应，如果审核：打开无法记录安全审核设置，立即关闭系统，安全日志已满，并且无法覆盖现有事件日志条目，则可能会自发重启。 计算机重新启动时，将显示以下“停止”错误消息：

        STOP： C0000244 {Audit Failed}
        尝试生成安全审核失败。

        若要恢复，管理员必须登录，将安全日志存档 (可选) ，清除安全日志，然后 (可选且所需的) 重置此选项。

      • 适用于 MS-DOS、Windows 95、Windows 98、Windows NT 4.0、Windows 2000、Windows XP、Windows Server 2003 的 Microsoft 网络客户端：尝试登录域的非管理员将收到以下错误消息：

        你的帐户配置为阻止你使用此计算机。 请尝试另一台计算机。

      • Windows 2000：在基于 Windows 2000 的计算机上，非管理员将无法登录到远程访问服务器，并且他们将收到类似于以下内容的错误消息：

        未知用户或密码错误

      • Windows 2000：在 Windows 2000 域控制器上，站点间消息服务 (Ismserv.exe) 将停止，无法重启。 DCDIAG 会将错误报告为“测试服务 ISMserv 失败”，事件日志中将注册事件 ID 1083。

      • Windows 2000：在 Windows 2000 域控制器上，Active Directory 复制将失败，如果安全事件日志已满，将显示“拒绝访问”消息。

      • Microsoft Exchange 2000：运行 Exchange 2000 的服务器将无法装载信息存储数据库，事件 2102 将在事件日志中注册。

      • Outlook、Outlook Web Access：非管理员无法通过 Microsoft Outlook 或 Microsoft Outlook Web Access 访问其邮件，并且会收到 503 错误。

2. 域控制器：LDAP 服务器签名要求

   1. 背景
      
      域控制器：LDAP 服务器签名要求安全设置确定轻型目录访问协议 (LDAP) 服务器是否要求 LDAP 客户端协商数据签名。 此策略设置的可能值如下所示：

      • 无：不需要数据签名即可与服务器绑定。 如果客户端请求数据签名，则服务器支持它。

      • 需要签名：必须协商 LDAP 数据签名选项，除非正在使用传输层安全/安全套接字层 (TLS/SSL) 。

      • 未定义：未启用或禁用此设置。

   2. 有风险的
      
      配置 以下是有害的配置设置：

      • 在客户端不支持 LDAP 签名或客户端 LDAP 签名未在客户端启用的环境中启用“需要登录”

      • 在客户端不支持 LDAP 签名或未启用客户端 LDAP 签名的环境中应用 Windows 2000 或 Windows Server 2003 Hisecdc.inf 安全模板

      • 在客户端不支持 LDAP 签名或客户端 LDAP 签名未启用的环境中应用 Windows 2000 或 Windows Server 2003 Hisecws.inf 安全模板

   3. 启用此设置
      
      的原因 无符号网络流量容易受到中间人攻击，其中入侵者捕获客户端和服务器之间的数据包，修改数据包，然后将其转发到服务器。 在 LDAP 服务器上发生此行为时，攻击者可能会导致服务器根据来自 LDAP 客户端的虚假查询做出决策。 通过实施强大的物理安全措施来帮助保护网络基础结构，可以降低企业网络中的此风险。 Internet 协议安全 (IPSec) 身份验证标头模式有助于防止中间人攻击。 身份验证标头模式对 IP 流量执行相互身份验证和数据包完整性。

   4. 禁用此设置的原因

      • 如果协商了 NTLM 身份验证，并且 Windows 2000 域控制器上未安装正确的服务包，则不支持 LDAP 签名的客户端将无法对域控制器和全局目录执行 LDAP 查询。

      • 将加密客户端和服务器之间 LDAP 流量的网络跟踪。 这使得检查 LDAP 对话变得困难。

      • 基于 Windows 2000 的服务器必须具有 Windows 2000 Service Pack 3 (SP3) 或安装这些服务器时，这些服务器使用支持从运行 Windows 2000 SP4、Windows XP 或 Windows Server 2003 的客户端计算机运行的 LDAP 签名的程序进行管理。  

   5. 符号名称：
      
      LDAPServerIntegrity

   6. 注册表路径：

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)

   7. 兼容性问题的示例

      • 简单绑定将失败，你将收到以下错误消息：

        Ldap_simple_bind_s () 失败：需要强身份验证。

      • Windows 2000 Service Pack 4、Windows XP、Windows Server 2003：在运行 Windows 2000 SP4、Windows XP 或 Windows Server 2003 的客户端上，某些 Active Directory 管理工具将无法针对在协商 NTLM 身份验证时运行早于 SP3 的 Windows 2000 版本的域控制器正确运行。
        
         

      • Windows 2000 Service Pack 4、Windows XP、Windows Server 2003：在运行 Windows 2000 SP4、Windows XP 或 Windows Server 2003 的客户端上，一些面向运行早于 SP3 版本的 Windows 2000 版本的域控制器的 Active Directory 管理工具将无法正常运行（例如，使用 IP 地址 (例如， “dsa.msc /server=x.x.x.x”，其中
        x.x.x.x 是 IP 地址) 。
        
        
         

      • Windows 2000 Service Pack 4、Windows XP、Windows Server 2003：在运行 Windows 2000 SP4、Windows XP 或 Windows Server 2003 的客户端上，针对运行早于 SP3 的 Windows 2000 版本的域控制器的一些 Active Directory 管理工具将无法正常运行。
        
         

3. 域成员：需要强 (Windows 2000 或更高版本) 会话密钥

   1. 背景

      • 域成员：需要强 (Windows 2000 或更高版本) 会话密钥设置确定是否可以使用域控制器建立安全通道，而该控制器无法使用强的 128 位会话密钥加密安全通道流量。 启用此设置可防止使用任何无法使用强密钥加密安全通道数据的域控制器建立安全通道。 禁用此设置允许 64 位会话密钥。

      • 在成员工作站或服务器上启用此设置之前，成员所属域中的所有域控制器都必须能够使用强 128 位密钥加密安全通道数据。 这意味着所有此类域控制器都必须运行 Windows 2000 或更高版本。

   2. 风险配置
      
      启用域成员：需要强 (Windows 2000 或更高版本) 会话密钥设置是有害的配置设置。

   3. 启用此设置的原因

      • 在 Windows 2000 中，用于在成员计算机和域控制器之间建立安全通道通信的会话密钥比早期版本的 Microsoft 操作系统要强大得多。

      • 如果有可能，最好利用这些更强大的会话密钥来帮助保护安全通道通信免受窃听和会话劫持网络攻击。 窃听是恶意攻击的一种形式，其中网络数据在传输过程中被读取或更改。 可以修改数据以隐藏或更改发件人，或重定向数据。

      重要提示运行 Windows Server 2008 R2 或 Windows 7 的计算机仅在使用安全通道时支持强密钥。 此限制可防止任何基于 Windows NT 4.0 的域与任何基于 Windows Server 2008 R2 的域之间的信任。 此外，此限制会阻止运行 Windows 7 或 Windows Server 2008 R2 的计算机Windows NT基于 4.0 的域成员身份，反之亦然。

   4. 禁用此设置
      
      的原因 该域包含运行 Windows 2000、Windows XP 或 Windows Server 2003 以外的操作系统的成员计算机。

   5. 符号名称：
      
      StrongKey

   6. 注册表路径：

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)

   7. 兼容性问题的
      
      示例Windows NT 4.0：在基于 Windows NT 4.0 的计算机上，重置具有 NLTEST 的 Windows NT 4.0 和 Windows 2000 域之间的安全信任关系通道失败。 出现“拒绝访问”错误消息：

      主域与受信任域之间的信任关系失败。
      
      Windows 7 和 Server 2008 R2：对于 Windows 7 及更高版本以及 Windows Server 2008 R2 及更高版本，不再遵守此设置，并且始终使用强密钥。 因此，对 Windows NT 4.0 域的信任不再有效。

4. 域成员：对安全通道数据进行数字加密或签名 (始终)

   1. 背景

      • 启用域成员：对安全通道数据进行数字加密或签名 (始终) 阻止与任何无法对所有安全通道数据进行签名或加密的域控制器建立安全通道。 为了帮助保护身份验证流量免受中间人攻击、重播攻击和其他类型的网络攻击，基于 Windows 的计算机通过 Net Logon 服务创建一个称为安全通道的通信通道，以对计算机帐户进行身份验证。 当一个域中的用户连接到远程域中的网络资源时，也会使用安全通道。 此多域身份验证或直通身份验证允许已加入域的基于 Windows 的计算机访问其域和任何受信任域中的用户帐户数据库。

      • 若要启用域成员：对安全通道数据进行数字加密或签名 (始终) 成员计算机上的设置，该成员所属域中的所有域控制器都必须能够对所有安全通道数据进行签名或加密。 这意味着所有此类域控制器都必须使用 Service Pack 6a (SP6a) 或更高版本运行 Windows NT 4.0。

      • 启用域成员：对安全通道数据进行数字加密或签名 (始终) 设置会自动启用域成员：在可能) 设置时对安全通道数据 (进行数字加密或签名。

   2. 风险配置
      
      启用域成员：对安全通道数据进行数字加密或签名 (始终在域中) 设置，其中并非所有域控制器都可以对安全通道数据进行签名或加密是有害的配置设置。

   3. 启用此设置
      
      的原因 无符号网络流量容易受到中间人攻击，其中入侵者捕获服务器和客户端之间的数据包，然后在将数据包转发到客户端之前对其进行修改。 当此行为发生在轻型目录访问协议 (LDAP) 服务器上时，入侵者可能会导致客户端根据 LDAP 目录中的虚假记录做出决策。 通过实施强大的物理安全措施来帮助保护网络基础结构，可以降低此类攻击企业网络的风险。 此外，实现 Internet 协议安全 (IPSec) 身份验证标头模式有助于防止中间人攻击。 此模式对 IP 流量执行相互身份验证和数据包完整性。

   4. 禁用此设置的原因

      • 本地或外部域中的计算机确实支持加密的安全通道。

      • 并非域中的所有域控制器都具有适当的服务包修订级别，以支持加密的安全通道。

   5. 符号名称：
      
      StrongKey

   6. 注册表路径：

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)

   7. 兼容性问题的示例

      • Windows NT 4.0：基于 Windows 2000 的成员计算机将无法加入Windows NT 4.0 域，并会收到以下错误消息：

        帐户无权从此站登录。

        有关详细信息，请单击以下文章编号以查看 Microsoft 知识库中的文章：

        281648 错误消息：帐户无权从此站登录
         

      • Windows NT 4.0：Windows NT 4.0 域将无法与 Windows 2000 域建立下层信任，并会收到以下错误消息：

        帐户无权从此站登录。

        现有的下层信任可能也不会对受信任域中的用户进行身份验证。 某些用户在登录到域时可能遇到问题，并且可能会收到一条错误消息，指出客户端找不到域。

      • Windows XP：已加入Windows NT 4.0 域的 Windows XP 客户端将无法对登录尝试进行身份验证，并且可能会收到以下错误消息，或者可以在事件日志中注册以下事件：

        Windows 无法连接到域，因为域控制器已关闭或因其他原因不可用，或者因为找不到计算机帐户

      • Microsoft 网络：Microsoft 网络客户端将收到以下错误消息之一：

        登录失败：用户名未知或密码错误。

        指定的登录会话没有用户会话密钥。

5. Microsoft 网络客户端：对通信进行数字签名 (始终)

   1. 背景
      
      服务器消息块 (SMB) 是许多 Microsoft 操作系统支持的资源共享协议。 它是网络基本输入/输出系统的基础 (NetBIOS) 和许多其他协议的基础。 SMB 签名对承载数据的用户和服务器进行身份验证。 如果任何一方的身份验证过程失败，则不会发生数据传输。
      
      在 SMB 协议协商期间开始启用 SMB 签名。 SMB 签名策略确定计算机是否始终以数字方式对客户端通信进行签名。
      
      Windows 2000 SMB 身份验证协议支持相互身份验证。 相互身份验证会关闭“中间人”攻击。 Windows 2000 SMB 身份验证协议还支持消息身份验证。 消息身份验证有助于防止活动消息攻击。 为了提供此身份验证，SMB 签名会将数字签名放入每个 SMB。 客户端和服务器各自验证数字签名。
      
      若要使用 SMB 签名，必须在 SMB 客户端和 SMB 服务器上启用 SMB 签名或要求 SMB 签名。 如果在服务器上启用了 SMB 签名，则还启用 SMB 签名的客户端会在所有后续会话中使用数据包签名协议。 如果服务器上需要 SMB 签名，则客户端无法建立会话，除非启用或需要客户端进行 SMB 签名。
      
      
      在高安全性网络中启用数字签名有助于防止模拟客户端和服务器。 这种模拟称为会话劫持。 有权访问与客户端或服务器相同的网络的攻击者使用会话劫持工具来中断、结束或窃取正在进行的会话。 攻击者可以截获和修改未签名的 SMB 数据包，修改流量，然后转发流量，以便服务器可以执行不需要的操作。 或者，攻击者在进行合法身份验证后，可能会冒充服务器或客户端，然后获取对数据的未经授权访问权限。
      
      在运行 Windows 2000 Server、Windows 2000 Professional、Windows XP Professional 或 Windows Server 2003 的计算机上用于文件共享和打印共享的 SMB 协议支持相互身份验证。 相互身份验证会关闭会话劫持攻击，并支持消息身份验证。 因此，它可防止中间人攻击。 SMB 签名通过在每个 SMB 中放置数字签名来提供此身份验证。 然后，客户端和服务器验证签名。
      
      笔记

      • 作为替代对策，可以使用 IPSec 启用数字签名，以帮助保护所有网络流量。 IPSec 加密和签名的基于硬件的加速器可用于最大程度地减少服务器 CPU 的性能影响。 没有可用于 SMB 签名的此类加速器。
        
        有关详细信息，请参阅 Microsoft MSDN 网站上 的数字签名服务器通信 章节。
        
        通过组策略对象编辑器配置 SMB 签名，因为如果存在重写域策略，对本地注册表值的更改将不起作用。

      • 在 Windows 95、Windows 98 和 Windows 98 第二版中，目录服务客户端使用 NTLM 身份验证通过 Windows Server 2003 服务器进行身份验证时使用 SMB 签名。 但是，这些客户端在使用 NTLMv2 身份验证对这些服务器进行身份验证时不会使用 SMB 签名。 此外，Windows 2000 服务器不会响应来自这些客户端的 SMB 签名请求。 有关详细信息，请参阅项 10：“网络安全：Lan Manager 身份验证级别”。

   2. 风险配置
      
      下面是一个有害的配置设置：同时保留 Microsoft 网络客户端：对通信进行数字签名 (始终) 设置和 Microsoft 网络客户端：如果服务器同意) 设置为“未定义”或已禁用，则对通信 (进行数字签名。 这些设置允许重定向器将纯文本密码发送到在身份验证期间不支持密码加密的非 Microsoft SMB 服务器。

   3. 启用此设置
      
      的原因 启用 Microsoft 网络客户端：对通信进行数字签名 (始终) 要求客户端在联系不需要 SMB 签名的服务器时对 SMB 流量进行签名。 这使得客户端更容易受到会话劫持攻击。

   4. 禁用此设置的原因

      • 启用 Microsoft 网络客户端：对通信进行数字签名 (始终) 阻止客户端与不支持 SMB 签名的目标服务器通信。

      • 将计算机配置为忽略所有未签名的 SMB 通信会阻止早期程序和操作系统连接。

   5. 符号名称：
      
      RequireSMBSignRdr

   6. 注册表路径：

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature

   7. 兼容性问题的示例

      • Windows NT 4.0：无法使用 NLTEST 或 NETDOM 重置 Windows Server 2003 域与 Windows NT 4.0 域之间信任的安全通道，并且会收到“拒绝访问”错误消息。

      • Windows XP：将文件从 Windows XP 客户端复制到基于 Windows 2000 的服务器和基于 Windows Server 2003 的服务器可能需要更多时间。

      • 如果启用了此设置，你将无法从客户端映射网络驱动器，你将收到以下错误消息：

        帐户无权从此站登录。

   8. 重启要求
      
      重启计算机，或重启工作站服务。 为此，请在命令提示符处键入以下命令。 键入每个命令后按 Enter。

      net stop 工作站
      net start Workstation

6. Microsoft 网络服务器：对通信进行数字签名 (始终)

   1. 背景

      • 服务器 Messenger 块 (SMB) 是许多 Microsoft 操作系统支持的资源共享协议。 它是网络基本输入/输出系统的基础 (NetBIOS) 和许多其他协议的基础。 SMB 签名对承载数据的用户和服务器进行身份验证。 如果任何一方的身份验证过程失败，则不会发生数据传输。
        
        在 SMB 协议协商期间开始启用 SMB 签名。 SMB 签名策略确定计算机是否始终以数字方式对客户端通信进行签名。
        
        Windows 2000 SMB 身份验证协议支持相互身份验证。 相互身份验证会关闭“中间人”攻击。 Windows 2000 SMB 身份验证协议还支持消息身份验证。 消息身份验证有助于防止活动消息攻击。 为了提供此身份验证，SMB 签名会将数字签名放入每个 SMB。 客户端和服务器各自验证数字签名。
        
        若要使用 SMB 签名，必须在 SMB 客户端和 SMB 服务器上启用 SMB 签名或要求 SMB 签名。 如果在服务器上启用了 SMB 签名，则还启用 SMB 签名的客户端会在所有后续会话中使用数据包签名协议。 如果服务器上需要 SMB 签名，则客户端无法建立会话，除非启用或需要客户端进行 SMB 签名。
        
        
        在高安全性网络中启用数字签名有助于防止模拟客户端和服务器。 这种模拟称为会话劫持。 有权访问与客户端或服务器相同的网络的攻击者使用会话劫持工具来中断、结束或窃取正在进行的会话。 攻击者可以截获和修改未签名的子网带宽管理器 (SBM) 数据包，修改流量，然后将其转发，以便服务器可以执行不需要的操作。 或者，攻击者在进行合法身份验证后，可能会冒充服务器或客户端，然后获取对数据的未经授权访问权限。
        
        在运行 Windows 2000 Server、Windows 2000 Professional、Windows XP Professional 或 Windows Server 2003 的计算机上用于文件共享和打印共享的 SMB 协议支持相互身份验证。 相互身份验证会关闭会话劫持攻击，并支持消息身份验证。 因此，它可防止中间人攻击。 SMB 签名通过在每个 SMB 中放置数字签名来提供此身份验证。 然后，客户端和服务器验证签名。

      • 作为替代对策，可以使用 IPSec 启用数字签名，以帮助保护所有网络流量。 IPSec 加密和签名的基于硬件的加速器可用于最大程度地减少服务器 CPU 的性能影响。 没有可用于 SMB 签名的此类加速器。

      • 在 Windows 95、Windows 98 和 Windows 98 第二版中，目录服务客户端使用 NTLM 身份验证通过 Windows Server 2003 服务器进行身份验证时使用 SMB 签名。 但是，这些客户端在使用 NTLMv2 身份验证对这些服务器进行身份验证时不会使用 SMB 签名。 此外，Windows 2000 服务器不会响应来自这些客户端的 SMB 签名请求。 有关详细信息，请参阅项 10：“网络安全：Lan Manager 身份验证级别”。

   2. 风险配置
      
      下面是一个有害的配置设置：启用 Microsoft 网络服务器：在服务器和域控制器上进行数字签名通信 (始终) 设置，这些设置由本地或外部域中不兼容的基于 Windows 的计算机和第三方基于操作系统的客户端计算机访问。

   3. 启用此设置的原因

      • 通过注册表或通过组策略设置直接启用此设置的所有客户端计算机都支持 SMB 签名。 换句话说，启用此设置的所有客户端计算机都运行安装了 DS 客户端的 Windows 95、Windows 98、Windows NT 4.0、Windows 2000、Windows XP Professional 或 Windows Server 2003。

      • 如果 Microsoft 网络服务器：数字签名通信 (始终禁用) ，则完全禁用 SMB 签名。 完全禁用所有 SMB 签名会使计算机更容易受到会话劫持攻击。

   4. 禁用此设置的原因

      • 启用此设置可能会导致客户端计算机上的文件复制和网络性能变慢。

      • 启用此设置将阻止无法协商 SMB 签名的客户端与服务器和域控制器通信。 这会导致操作（如域联接、用户和计算机身份验证）或程序的网络访问失败。

   5. 符号名称：
      
      RequireSMBSignServer

   6. 注册表路径：

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)

   7. 兼容性问题的示例

      • Windows 95：未安装目录服务 (DS) 客户端的 Windows 95 客户端将无法进行登录身份验证，并会收到以下错误消息：

        提供的域密码不正确，或者已拒绝对登录服务器的访问。

      • Windows NT 4.0：运行低于 Service Pack 3 Windows NT 4.0 版本的客户端计算机 (SP3) 将无法进行登录身份验证，并会收到以下错误消息：

        系统无法登录。 确保用户名和域正确，然后再次键入密码。

        某些非 Microsoft SMB 服务器仅支持在身份验证期间进行未加密的密码交换。 (这些交换也称为“纯文本”交换。) 对于Windows NT 4.0 SP3 及更高版本，除非添加特定注册表项，否则 SMB 重定向器不会在身份验证期间向 SMB 服务器发送未加密的密码。
        若要在 Windows NT 4.0 SP 3 和更高版本的系统上为 SMB 客户端启用未加密的密码，请按如下方式修改注册表：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters
        
        值名称：EnablePlainTextPassword
        
        数据类型：REG_DWORD
        
        数据：1
        
         

      • Windows Server 2003：默认情况下，将配置运行 Windows Server 2003 的域控制器上的安全设置，以帮助防止恶意用户截获或篡改域控制器通信。 若要使用户能够成功与运行 Windows Server 2003 的域控制器通信，客户端计算机必须同时使用 SMB 签名和加密或安全通道流量签名。 默认情况下，使用 Service Pack 2 运行 Windows NT 4.0 的客户端 (SP2) 或更早安装，并且运行 Windows 95 的客户端未启用 SMB 数据包签名。 因此，这些客户端可能无法向基于 Windows Server 2003 的域控制器进行身份验证。

      • Windows 2000 和 Windows Server 2003 策略设置：根据特定的安装需求和配置，我们建议在 Microsoft 管理控制台组策略编辑器管理单元层次结构中，将以下策略设置设置为必要范围的最低实体：

        • 计算机配置\Windows 安全中心设置\安全选项

        • 发送未加密的密码以连接到第三方 SMB 服务器 (此设置适用于 Windows 2000)

        • Microsoft 网络客户端：将未加密的密码发送到第三方 SMB 服务器 (此设置适用于 Windows Server 2003)

        
        请注意，在某些第三方 CIFS 服务器（如旧版 Samba）中，不能使用加密密码。

      • 以下客户端与 Microsoft 网络服务器不兼容：对通信进行数字签名 (始终) 设置：

        • Apple Computer， Inc.， Mac OS X 客户端

        • 例如，Microsoft MS-DOS 网络客户端 (Microsoft LAN Manager)

        • Microsoft Windows for Workgroups 客户端

        • 未安装 DS 客户端的 Microsoft Windows 95 客户端

        • Microsoft Windows NT没有安装 SP3 或更高版本的基于 4.0 的计算机

        • Novell Netware 6 CIFS 客户端

        • 不支持 SMB 签名的 SAMBA SMB 客户端

   8. 重启要求
      
      重启计算机或重启服务器服务。 为此，请在命令提示符处键入以下命令。 键入每个命令后按 Enter。

      net stop 服务器
      net start server

7. 网络访问：允许匿名 SID/名称转换

   1. 背景
      
      网络访问：允许匿名 SID/名称转换安全设置确定匿名用户是否可以请求其他用户的安全标识号 (SID) 属性。

   2. 风险配置
      
      启用网络访问：允许匿名 SID/名称转换设置是有害的配置设置。

   3. 启用此设置
      
      的原因 如果禁用了网络访问：允许匿名 SID/名称转换设置，则早期操作系统或应用程序可能无法与 Windows Server 2003 域通信。 例如，以下操作系统、服务或应用程序可能不起作用：

      • Windows NT基于 4.0 的远程访问服务服务器

      • 在基于 Windows NT 3.x 的计算机或基于 4.0 的计算机上运行的 Microsoft Windows NT SQL Server

      • 在基于 Windows 2000 的计算机上运行的远程访问服务，这些计算机位于 Windows NT 3.x 域或 Windows NT 4.0 域

      • SQL Server在基于 Windows 2000 的计算机上运行，这些计算机位于 Windows NT 3.x 域或 Windows NT 4.0 域中

      • Windows NT 4.0 资源域中的用户，想要向包含 Windows Server 2003 域控制器的帐户域中的用户帐户授予访问文件、共享文件夹和注册表对象的权限

   4. 禁用此设置
      
      的原因 如果启用此设置，恶意用户可以使用已知的管理员 SID 获取内置管理员帐户的实名，即使帐户已重命名也是如此。 然后，该人员可以使用帐户名称发起密码猜测攻击。

   5. 符号名称：N/A

   6. 注册表路径：无。 路径在 UI 代码中指定。

   7. 兼容性问题的
      
      示例Windows NT 4.0：如果资源（包括共享文件夹、共享文件和注册表对象）受驻留在包含 Windows Server 2003 域控制器的帐户域中的安全主体进行保护，则 Windows NT 4.0 资源域中的计算机将在 ACL 编辑器中显示“帐户未知”错误消息。

8. 网络访问：不允许匿名枚举 SAM 帐户

   1. 背景

      • 网络访问：不允许对 SAM 帐户设置进行匿名枚举，这决定了将向与计算机的匿名连接授予哪些附加权限。 Windows 允许匿名用户执行某些活动，例如枚举工作站和服务器安全帐户管理器的名称 (SAM) 帐户和网络共享。 例如，管理员可以使用此功能向不维护对等信任的受信任域中的用户授予访问权限。 创建会话后，匿名用户可能具有根据网络访问中的设置授予每个人组的相同访问权限：允许“每个人”权限应用于匿名用户设置或自定义访问控制列表 (该对象的 DACL) 。
        
        通常，匿名连接是由早期版本的客户端请求的， (SMB 会话设置期间) 的下层客户端。 在这些情况下，网络跟踪显示 SMB 进程 ID (PID) 是客户端重定向器，例如 Windows 2000 中的0xFEFF或Windows NT中的0xCAFE。 RPC 还可以尝试建立匿名连接。

      • 重要说明此设置对域控制器没有影响。 在域控制器上，此行为由“预 Windows 2000 兼容访问”中的“NT AUTHORITY\ANONYMOUS LOGON”状态控制。

      • 在 Windows 2000 中，名为“匿名连接的其他限制”的类似设置管理 RestrictAnonymous 注册表值。 此值的位置如下所示

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA  

   2. 有风险的
      
      配置 启用网络访问：从兼容性的角度来看，不允许匿名枚举 SAM 帐户设置是有害的配置设置。 从安全角度来看，禁用它是有害的配置设置。

   3. 启用此设置
      
      的原因 未经授权的用户可以匿名列出帐户名称，然后使用这些信息来尝试猜测密码或执行社交工程攻击。 社会工程是行话，意味着欺骗人们泄露他们的密码或某种形式的安全信息。

   4. 禁用此设置
      
      的原因 如果启用此设置，则无法使用 Windows NT 4.0 域建立信任。 此设置还会导致下层客户端 (（例如Windows NT 3.51 客户端和 Windows 95 客户端) 尝试在服务器上使用资源）出现问题。

   5. 符号名称：
      
      
      RestrictAnonymousSAM

   6. 注册表路径：

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)

   7. 兼容性问题的示例

   • SMS 网络发现将无法获取操作系统信息，并将在 OperatingSystemNameandVersion 属性中写入“Unknown”。

   • Windows 95、Windows 98：Windows 95 客户端和 Windows 98 客户端将无法更改其密码。

   • Windows NT 4.0：Windows NT基于 4.0 的成员计算机将无法进行身份验证。

   • Windows 95、Windows 98：基于 Windows 95 的计算机和基于 Windows 98 的计算机将无法通过 Microsoft 域控制器进行身份验证。

   • Windows 95、Windows 98：基于 Windows 95 和基于 Windows 98 的计算机上的用户将无法更改其用户帐户的密码。

9. 网络访问：不允许匿名枚举 SAM 帐户和共享

   1. 背景

      • 网络访问：不允许匿名枚举 SAM 帐户和共享设置 (也称为 RestrictAnonymous) 确定是否允许匿名枚举安全帐户管理器 (SAM) 帐户和共享。 Windows 允许匿名用户执行某些活动，例如枚举 (用户、计算机和组) 和网络共享的域帐户的名称。 例如，当管理员想要向不维护对等信任的受信任域中的用户授予访问权限时，这非常方便。 如果不想允许匿名枚举 SAM 帐户和共享，请启用此设置。

      • 在 Windows 2000 中，名为“匿名连接的其他限制”的类似设置管理 RestrictAnonymous 注册表值。 此值的位置如下所示：

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

   2. 风险配置
      
      启用网络访问：不允许匿名枚举 SAM 帐户和共享设置是有害的配置设置。

   3. 启用此设置的原因

      • 启用网络访问：不允许匿名枚举 SAM 帐户和共享设置，防止使用匿名帐户的用户和计算机枚举 SAM 帐户和共享。

   4. 禁用此设置的原因

      • 如果启用此设置，未经授权的用户可以匿名列出帐户名称，然后使用这些信息来尝试猜测密码或执行社交工程攻击。 社会工程是行话，意味着欺骗人们泄露他们的密码或某种形式的安全信息。

      • 如果启用此设置，则无法使用 Windows NT 4.0 域建立信任。 此设置还会导致下层客户端（例如Windows NT 3.51 和 Windows 95 客户端尝试在服务器上使用资源）出现问题。

      • 将无法授予对资源域用户的访问权限，因为信任域中的管理员将无法枚举其他域中的帐户列表。 匿名访问文件和打印服务器的用户将无法列出这些服务器上的共享网络资源。 用户必须先进行身份验证，然后才能查看共享文件夹和打印机的列表。

   5. 符号名称：
      
      RestrictAnonymous

   6. 注册表路径：

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous

   7. 兼容性问题的示例

      • Windows NT 4.0：当在用户域中的域控制器上启用 RestrictAnonymous 时，用户将无法从Windows NT 4.0 工作站更改其密码。

      • Windows NT 4.0：将受信任的 Windows 2000 域中的用户或全局组添加到用户管理器中的 Windows NT 4.0 本地组将失败，并显示以下错误消息：

        目前没有可用于为登录请求提供服务的登录服务器。

      • Windows NT 4.0：Windows NT基于 4.0 的计算机在设置期间或使用域联接用户界面将无法加入域。

      • Windows NT 4.0：使用 Windows NT 4.0 资源域建立下级信任将失败。 在受信任域上启用 RestrictAnonymous 时，将显示以下错误消息：

        找不到此域的域控制器。

      • Windows NT 4.0：登录到基于 Windows NT 4.0 的终端服务器计算机的用户将映射到默认主目录，而不是用户管理器中为域定义的主目录。

      • Windows NT 4.0：Windows NT 4.0 备份域控制器 (BDC) 将无法启动 Net Logon 服务、获取备份浏览器列表，或从 Windows 2000 或同一域中的 Windows Server 2003 域控制器同步 SAM 数据库。

      • Windows 2000：如果在客户端计算机的本地安全策略中启用了没有显式匿名权限设置的无访问权限，则Windows NT 4.0 域中基于 Windows 2000 的成员计算机将无法在外部域中查看打印机。

      • Windows 2000：Windows 2000 域用户将无法从 Active Directory 添加网络打印机;但是，在从树视图中选择打印机后，他们将能够添加打印机。

      • Windows 2000：在基于 Windows 2000 的计算机上，ACL 编辑器将无法从受信任Windows NT 4.0 域添加用户或全局组。

      • ADMT 版本 2：使用 Active Directory 迁移工具在林之间迁移的用户帐户的密码迁移 (ADMT) 版本 2 将失败。
        
        有关详细信息，请单击以下文章编号以查看 Microsoft 知识库中的文章：

        322981 如何使用 ADMTv2 排查林间密码迁移问题

      • Outlook 客户端：Microsoft Exchange Outlook 客户端的全局地址列表将显示为空。

      • 短信：Microsoft Systems Management Server (短信) 网络发现将无法获取操作系统信息。 因此，它将在发现数据记录的 SMS DDR 属性的 OperatingSystemNameandVersion 属性中写入“Unknown”， (DDR) 。

      • 短信：使用短信管理员用户向导浏览用户和组时，不会列出任何用户或组。 此外，高级客户端无法与管理点通信。 管理点需要匿名访问。

      • 短信：在 SMS 2.0 和远程客户端安装中使用网络发现功能时，启用了拓扑、客户端和客户端操作系统网络发现选项时，可能会发现计算机，但可能不会安装计算机。

10. 网络安全：Lan Manager 身份验证级别

    1. 背景
       
       LAN Manager (LM) 身份验证是用于对 Windows 客户端进行网络操作（包括域联接、访问网络资源以及用户或计算机身份验证）进行身份验证的协议。 LM 身份验证级别确定客户端和服务器计算机之间协商的质询/响应身份验证协议。 具体而言，LM 身份验证级别确定客户端将尝试协商的身份验证协议或服务器将接受的身份验证协议。 为 LmCompatibilityLevel 设置的值确定哪个质询/响应身份验证协议用于网络登录。 此值会影响客户端使用的身份验证协议级别、协商的会话安全级别以及服务器接受的身份验证级别。
       
       可能的设置包括以下内容。

       值	设置	描述
       0	发送 LM & NTLM 响应	客户端使用 LM 和 NTLM 身份验证，从不使用 NTLMv2 会话安全性。 域控制器接受 LM、NTLM 和 NTLMv2 身份验证。
       1	发送 LM & NTLM - 如果协商，请使用 NTLMv2 会话安全性	客户端使用 LM 和 NTLM 身份验证，如果服务器支持，则使用 NTLMv2 会话安全性。 域控制器接受 LM、NTLM 和 NTLMv2 身份验证。
       2	仅发送 NTLM 响应	客户端仅使用 NTLM 身份验证，如果服务器支持 NTLMv2 会话安全性，则使用 NTLMv2 会话安全性。 域控制器接受 LM、NTLM 和 NTLMv2 身份验证。
       3	仅发送 NTLMv2 响应	客户端仅使用 NTLMv2 身份验证，如果服务器支持 NTLMv2 会话安全性，则使用 NTLMv2 会话安全性。 域控制器接受 LM、NTLM 和 NTLMv2 身份验证。
       4	仅发送 NTLMv2 响应/拒绝 LM	客户端仅使用 NTLMv2 身份验证，如果服务器支持 NTLMv2 会话安全性，则使用 NTLMv2 会话安全性。 域控制器拒绝 LM，只接受 NTLM 和 NTLMv2 身份验证。
       5	仅发送 NTLMv2 响应/拒绝 LM & NTLM	客户端仅使用 NTLMv2 身份验证，如果服务器支持 NTLMv2 会话安全性，则使用 NTLMv2 会话安全性。 域控制器拒绝 LM 和 NTLM，只接受 NTLMv2 身份验证。

       请注意，在 Windows 95、Windows 98 和 Windows 98 第二版中，目录服务客户端使用 NTLM 身份验证通过 Windows Server 2003 服务器进行身份验证时使用 SMB 签名。 但是，这些客户端在使用 NTLMv2 身份验证对这些服务器进行身份验证时不会使用 SMB 签名。 此外，Windows 2000 服务器不会响应来自这些客户端的 SMB 签名请求。
       
       检查 LM 身份验证级别：必须更改服务器上的策略以允许 NTLM，或者必须将客户端计算机配置为支持 NTLMv2。
       
       如果策略设置为 (5) 仅发送 NTLMv2 响应\拒绝要连接到的目标计算机上的 LM & NTLM，则必须降低该计算机上的设置，或将安全设置为连接到的源计算机上的相同设置。
       
       找到可以更改 LAN 管理器身份验证级别以将客户端和服务器设置为相同级别的正确位置。 找到设置 LAN 管理器身份验证级别的策略后，如果要连接到运行早期版本 Windows 的计算机，请将值降低到至少 (1) 发送 LM & NTLM - 如果协商，请使用 NTLM 版本 2 会话安全性。 不兼容设置的一个效果是，如果服务器需要 NTLMv2 (值 5) ，但客户端配置为仅使用 LM 和 NTLMv1 (值 0) ，则尝试身份验证的用户会遇到具有错误密码的登录失败，并且会增加错误的密码计数。 如果配置了帐户锁定，用户最终可能会被锁定。
       
       例如，可能必须查看域控制器，或者可能需要检查域控制器的策略。
       
       查看域控制器
       
       请注意，可能需要在所有域控制器上重复以下过程。

       1. 单击 “开始”，指向 “程序”，然后单击 “管理工具”。

       2. 在 “本地安全设置”下，展开 “本地策略”。

       3. 单击 “安全选项”。

       4. 双击 “网络安全：LAN 管理器身份验证级别”，然后单击列表中的值。

       
       如果有效设置和本地设置相同，则已在此级别更改策略。 如果设置不同，则必须检查域控制器的策略，以确定是否在该处定义了网络安全：LAN 管理器身份验证级别设置。 如果未在此处定义，请检查域控制器的策略。
       
       检查域控制器的策略

       1. 单击 “开始”，指向 “程序”，然后单击 “管理工具”。

       2. 在 域控制器安全 策略中，展开 安全设置，然后展开 本地策略。

       3. 单击 “安全选项”。

       4. 双击“网络安全：LAN 管理器身份验证级别”，然后单击列表中的值。

       
       注意

       • 可能还必须检查在站点级别、域级别或组织单位 (OU) 级别链接的策略，以确定必须配置 LAN 管理器身份验证级别的位置。

       • 如果将组策略设置实现为默认域策略，则该策略将应用于域中的所有计算机。

       • 如果将组策略设置实现为默认域控制器的策略，则该策略仅适用于域控制器 OU 中的服务器。

       • 最好是在策略应用程序层次结构中必要范围的最低实体中设置 LAN 管理器身份验证级别。

       Windows Server 2003 有一个新的默认设置，仅使用 NTLMv2。 默认情况下，基于 Windows Server 2003 和 Windows 2000 Server SP3 的域控制器已启用“Microsoft 网络服务器：对通信进行数字签名 (始终) ”策略。 此设置要求 SMB 服务器执行 SMB 数据包签名。 对 Windows Server 2003 进行了更改，因为任何组织中的域控制器、文件服务器、网络基础结构服务器和 Web 服务器都需要不同的设置来最大化其安全性。
       
       如果要在网络中实现 NTLMv2 身份验证，必须确保域中的所有计算机都设置为使用此身份验证级别。 如果将 Active Directory 客户端扩展应用于 Windows 95 或 Windows 98 和 Windows NT 4.0，则客户端扩展将使用 NTLMv2 中提供的改进的身份验证功能。 由于运行以下任何操作系统的客户端计算机不受 Windows 2000 组策略对象的影响，因此可能需要手动配置这些客户端：

       • Microsoft Windows NT 4.0

       • Microsoft Windows 千年版

       • Microsoft Windows 98

       • Microsoft Windows 95

       请注意，如果启用 网络安全：请勿在下一个密码更改策略上存储 LAN 管理器哈希值 ，或设置 NoLMHash 注册表项，密码更改后，未安装目录服务客户端的基于 Windows 95 和 Windows 98 的客户端无法登录到域。
       
       许多第三方 CIFS 服务器（如 Novell Netware 6）都不知道 NTLMv2 并仅使用 NTLM。 因此，大于 2 的级别不允许连接。 还有第三方 SMB 客户端不使用扩展会话安全性。 在这些情况下，不考虑资源服务器的 LmCompatiblityLevel。 然后，服务器将打包此旧请求并将其发送到用户域控制器。 然后，域控制器上的设置决定用于验证请求的哈希，以及这些哈希是否满足域控制器的安全要求。
       
        

       299656 如何防止 Windows 在 Active Directory 和本地 SAM 数据库中存储密码的 LAN 管理器哈希
        

       2701704审核事件将身份验证包显示为 NTLMv1 而不是 NTLMv2，有关 LM 身份验证级别的详细信息，请单击以下文章号以查看 Microsoft 知识库中的文章：

       239869 如何启用 NTLM 2 身份验证
        

    2. 有风险的
       
       配置 以下是有害的配置设置：

       • 以明文形式发送密码并拒绝 NTLMv2 协商的非对称设置

       • 阻止不兼容的客户端或域控制器协商常见身份验证协议的限制性设置

       • 要求在运行早于 Service Pack 4 Windows NT 4.0 版本的成员计算机和域控制器上进行 NTLMv2 身份验证 (SP4)

       • 要求在 Windows 95 客户端或未安装 Windows Directory Services 客户端的 Windows 98 客户端上进行 NTLMv2 身份验证。

       • 如果在基于 Windows Server 2003 或 Windows 2000 Service Pack 3 的计算机上单击 Microsoft 管理控制台组策略编辑器管理单元中选择“需要 NTLMv2 会话安全”复选框，并且将 LAN 管理器身份验证级别降低到 0，则这两个设置会发生冲突，并且可能会在 Secpol.msc 文件或 GPEdit.msc 文件中收到以下错误消息：

         Windows 无法打开本地策略数据库。 尝试打开数据库时出现未知错误。

         有关安全配置和分析工具的详细信息，请参阅 Windows 2000 或 Windows Server 2003 帮助文件。

    3. 修改此设置的原因

       • 你希望增加组织中客户端和域控制器支持的最低常见身份验证协议。

       • 如果安全身份验证是业务要求，则需禁止协商 LM 和 NTLM 协议。

    4. 禁用此设置
       
       的原因 客户端或服务器身份验证要求（或两者兼有）已增加到无法通过通用协议进行身份验证的地步。

    5. 符号名称：
       
       LmCompatibilityLevel

    6. 注册表路径：

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

    7. 兼容性问题的示例

       • Windows Server 2003：默认情况下，已启用 Windows Server 2003 NTLMv2 发送 NTLM 响应设置。 因此，当你尝试连接到基于 Windows NT 4.0 的群集或基于 LanManager V2.1 的服务器（例如 OS/2 Lanserver）时，Windows Server 2003 在初始安装后收到“拒绝访问”错误消息。 如果尝试从早期版本的客户端连接到基于 Windows Server 2003 的服务器，也会出现此问题。

       • 安装 Windows 2000 安全汇总包 1 (SRP1) 。SRP1 强制使用 NTLM 版本 2 (NTLMv2) 。 此汇总包是在 Windows 2000 Service Pack 2 (SP2) 发布后发布的。
          

       • Windows 7 和 Windows Server 2008 R2：许多第三方 CIFS 服务器（如 Newl Netware 6 或基于 Linux 的 Samba 服务器）都不知道 NTLMv2 并仅使用 NTLM。 因此，大于“2”的级别不允许连接。 现在，在此版本的操作系统中，LmCompatibilityLevel 的默认值已更改为“3”。 因此，升级 Windows 时，这些第三方文件员可能会停止工作。

       • 可能会提示 Microsoft Outlook 客户端输入凭据，即使它们已登录到域。 当用户提供凭据时，他们会收到以下错误消息：Windows 7 和 Windows Server 2008 R2

         提供的登录凭据不正确。 确保用户名和域正确，然后再次键入密码。

         启动 Outlook 时，可能会提示输入凭据，即使登录网络安全设置设置设置为“传递”或“密码身份验证”。 键入正确的凭据后，可能会收到以下错误消息：

         提供的登录凭据不正确。

         网络监视器跟踪可能显示全局目录发出远程过程调用 (RPC) 状态为0x5的错误。 状态为0x5表示“拒绝访问”。

       • Windows 2000：网络监视器捕获可能显示 NetBIOS 中通过 TCP/IP (NetBT) 服务器消息块 (SMB) 会话出现以下错误：

         SMB R 搜索目录 Dos 错误， (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) 用户标识符无效

       • Windows 2000：如果具有 NTLMv2 级别 2 或更高版本的 Windows 2000 域受 Windows NT 4.0 域的信任，则资源域中基于 Windows 2000 的成员计算机可能会遇到身份验证错误。

       • Windows 2000 和 Windows XP：默认情况下，Windows 2000 和 Windows XP 将 LAN Manager 身份验证级别本地安全策略选项设置为 0。 设置为 0 表示“发送 LM 和 NTLM 响应”。
         
         请注意Windows NT基于 4.0 的群集必须使用 LM 进行管理。

       • Windows 2000：如果这两个节点都属于 Windows NT 4.0 Service Pack 6a (SP6a) 域，则 Windows 2000 群集不会对联接节点进行身份验证。

       • IIS 锁定工具 (HiSecWeb) 将 LMCompatibilityLevel 值设置为 5，RestrictAnonymous 值设置为 2。

       • Macintosh
         
         服务 用户身份验证模块 (UAM) ：Microsoft UAM (用户身份验证模块) 提供了一种加密用于登录 Windows AFP (AppleTalk 归档协议) 服务器的密码的方法。 Apple 用户身份验证模块 (UAM) 仅提供最小或无加密。 因此，可以在 LAN 或 Internet 上轻松截获密码。 尽管不需要 UAM，但它确实向运行 Macintosh 服务的 Windows 2000 服务器提供加密身份验证。 此版本包括对 NTLMv2 128 位加密身份验证和与 MacOS X 10.1 兼容的版本的支持。
         
         默认情况下，适用于 Macintosh 的 Windows Server 2003 服务服务器仅允许 Microsoft 身份验证。
          

       • Windows Server 2008、Windows Server 2003、Windows XP 和 Windows 2000：如果将 LMCompatibilityLevel 值配置为 0 或 1，然后将 NoLMHash 值配置为 1，则应用程序和组件可能会被拒绝通过 NTLM 访问。 出现此问题的原因是计算机配置为启用 LM，但不使用 LM 存储的密码。
         
         如果将 NoLMHash 值配置为 1，则必须将 LMCompatibilityLevel 值配置为 2 或更高。

11. 网络安全：LDAP 客户端签名要求

    1. 背景
       
       网络安全：LDAP 客户端签名要求设置确定代表发出轻型目录访问协议 (LDAP) BIND 请求的客户端请求的数据签名级别，如下所示：

       • 无：LDAP BIND 请求使用调用方指定的选项发出。

       • 协商签名：如果安全套接字层/传输层安全 (SSL/TLS) 尚未启动，则除了调用方指定的选项外，还会使用 LDAP 数据签名选项集启动 LDAP BIND 请求。 如果 SSL/TLS 已启动，则使用调用方指定的选项启动 LDAP BIND 请求。

       • 需要签名：这与协商签名相同。 但是，如果 LDAP 服务器的中间 saslBindInProgress 响应未指示需要 LDAP 流量签名，则调用方会被告知 LDAP BIND 命令请求失败。

    2. 风险配置
       
       启用网络安全：LDAP 客户端签名要求设置是有害的配置设置。 如果将服务器设置为需要 LDAP 签名，则还必须在客户端上配置 LDAP 签名。 不将客户端配置为使用 LDAP 签名会阻止与服务器通信。 这会导致用户身份验证、组策略设置、登录脚本和其他功能失败。

    3. 修改此设置
       
       的原因 无符号网络流量容易受到中间人攻击，其中入侵者捕获客户端和服务器之间的数据包、修改数据包，然后将其转发到服务器。 在 LDAP 服务器上发生这种情况时，攻击者可能会导致服务器基于来自 LDAP 客户端的虚假查询做出响应。 通过实施强大的物理安全措施来帮助保护网络基础结构，可以降低企业网络中的此风险。 此外，还可以通过 IPSec 身份验证标头要求所有网络数据包上的数字签名来帮助防止各种中间人攻击。

    4. 符号名称：
       
       LDAPClientIntegrity

    5. 注册表路径：

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity

12. 事件日志：最大安全日志大小

    1. 背景
       
       事件日志：最大安全日志大小安全设置指定安全事件日志的最大大小。 此日志的最大大小为 4 GB。 若要查找此设置，请展开
       Windows 设置，然后展开 安全设置。

    2. 有风险的
       
       配置 以下是有害的配置设置：

       • 在启用审核时限制安全日志大小和安全日志保留方法：如果无法记录安全审核设置，请立即关闭系统。 有关更多详细信息，请参阅本文的“审核：如果无法记录安全审核，立即关闭系统”部分。

       • 限制安全日志大小，以便覆盖感兴趣的安全事件。

    3. 增加此设置
       
       的原因 业务和安全要求可能要求增加安全日志大小，以处理其他安全日志详细信息或将安全日志保留更长时间。

    4. 减少此设置
       
       的原因事件查看器日志是内存映射文件。 事件日志的最大大小受本地计算机中的物理内存量和事件日志进程可用的虚拟内存的限制。 将日志大小增大到可用于事件查看器的虚拟内存量不会增加所维护的日志条目数。

    5. 兼容性问题的
       
       示例 Windows 2000：运行早于 Service Pack 4 (SP4) 的 Windows 2000 版本的计算机可能会在达到事件查看器中“最大日志大小”设置中指定的大小之前停止记录事件， (手动清除日志) 选项。
       
       
        

13. 事件日志：保留安全日志

    1. 背景
       
       事件日志：保留安全日志安全设置确定安全日志的“包装”方法。 若要查找此设置，请展开 Windows 设置，然后展开 安全设置。

    2. 有风险的
       
       配置 以下是有害的配置设置：

       • 无法在覆盖所有记录的安全事件之前保留这些事件

       • 配置最大安全日志大小设置太小，以便覆盖安全事件

       • 在启用审核时限制安全日志大小和保留方法：如果无法记录安全审核安全设置，请立即关闭系统

    3. 启用此设置
       
       的原因 仅当按天保留方法选择 覆盖事件 时，才启用此设置。 如果使用事件相关系统轮询事件，请确保天数至少是轮询频率的三倍。 这样做是为了允许失败的轮询周期。

14. 网络访问：允许每个人的权限应用于匿名用户

    1. 背景
       
       默认情况下，“网络访问：允许每个人”权限应用于匿名用户设置，设置为“未在 Windows Server 2003 上定义”。 默认情况下，Windows Server 2003 在“每个人”组中不包括匿名访问令牌。

    2. 兼容性问题的
       
       示例 的以下值

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0在 Windows Server 2003 和 Windows NT 4.0 之间中断了信任创建，当 Windows Server 2003 域是帐户域，Windows NT 4.0 域是资源域时。 这意味着帐户域在 Windows NT 4.0 上受信任，并且资源域在 Windows Server 2003 端处于信任状态。 发生此行为是因为在初始匿名连接后启动信任的过程是 ACL，其中包含 Windows NT 4.0 上的匿名 SID 的 Everyone 令牌。

    3. 修改此设置
       
       的原因 该值必须设置为0x1或通过在域控制器的 OU 上使用 GPO 设置为：网络访问：允许每个人的权限应用于匿名用户 - 启用以使创建信任成为可能。
       
       请注意，大多数其他安全设置的值会上升，而不是在最安全的状态下0x0。 更安全的做法是更改主域控制器模拟器上的注册表，而不是在所有域控制器上更改注册表。 如果出于任何原因移动了主域控制器模拟器角色，则必须在新服务器上更新注册表。
       
       设置此值后，需要重启。

    4. 注册表路径

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous

15. NTLMv2 身份验证

    1. 会话安全性
       
       会话安全性确定客户端和服务器会话的最小安全标准。 最好在 Microsoft 管理控制台组策略编辑器管理单元中验证以下安全策略设置：

       • 计算机设置\Windows 设置\安全设置\本地策略\安全选项

       • 网络安全：基于 NTLM SSP 的最低会话安全性 (包括安全 RPC) 服务器

       • 网络安全：基于 NTLM SSP 的最低会话安全性 (包括安全 RPC) 客户端

       这些设置的选项如下所示：

       • 要求消息完整性

       • 要求消息保密

       • 需要 NTLM 版本 2 会话安全性

       • 需要 128 位加密

       Windows 7 之前的默认设置为“无要求”。 从 Windows 7 开始，默认值更改为需要 128 位加密以提高安全性。 默认情况下，不支持 128 位加密的旧设备将无法连接。
       
       这些策略确定客户端服务器上应用程序到应用程序通信会话的最小安全标准。
       
       请注意，尽管这些标志被描述为有效设置，但确定 NTLM 会话安全性时，不会使用要求消息完整性和机密性的标志。
       
       从历史上看，Windows NT支持以下两种网络登录质询/响应身份验证变体：

       • LM 质询/响应

       • NTLM 版本 1 质询/响应

       LM 允许与已安装的客户端和服务器基础互操作。 NTLM 为客户端和服务器之间的连接提供更高的安全性。
       
       相应的注册表项如下所示：

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec”
       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec”

    2. 有风险的
       
       配置 此设置控制如何处理使用 NTLM 保护的网络会话。 例如，这会影响使用 NTLM 进行身份验证的基于 RPC 的会话。 存在以下风险：

       • 使用比 NTLMv2 更旧的身份验证方法，由于使用的哈希方法更简单，通信更容易受到攻击。

       • 使用低于 128 位的加密密钥可让攻击者使用暴力攻击中断通信。

时间同步

时间同步失败。 受影响计算机上的停机时间超过 30 分钟。 确保客户端计算机的时钟与域控制器的时钟同步。

SMB 签名的解决方法

建议在基于 Windows Server 2003 的域中互操作的 Windows NT 4.0 客户端上安装 Service Pack 6a (SP6a) 。 基于 Windows 98 第二版的客户端、基于 Windows 98 的客户端和基于 Windows 95 的客户端必须运行目录服务客户端才能执行 NTLMv2。 如果Windows NT基于 4.0 的客户端未安装Windows NT 4.0 SP6，或者基于 Windows 95 的客户端、基于 Windows 98 的客户端和基于 Windows 98SE 的客户端未安装目录服务客户端，请在域控制器的 OU 上禁用默认域控制器策略设置中的 SMB 签名，然后将此策略链接到托管域控制器的所有 OU。

适用于 Windows 98 Second Edition、Windows 98 和 Windows 95 的目录服务客户端将在 NTLM 身份验证下执行 Windows 2003 服务器的 SMB 签名，但不会在 NTLMv2 身份验证下执行 SMB 签名。 此外，Windows 2000 服务器不会响应来自这些客户端的 SMB 签名请求。

尽管我们不建议这样做，但你可以阻止在域中运行 Windows Server 2003 的所有域控制器上需要 SMB 签名。 若要配置此安全设置，请执行以下步骤：

1. 打开默认域控制器的策略。

2. 打开计算机配置\Windows 设置\安全设置\本地策略\安全选项文件夹。

3. 找到并单击 Microsoft 网络服务器：对通信进行数字签名 (始终) 策略设置，然后单击“已禁用”。

重要说明本部分、方法或任务包含说明如何修改注册表的步骤。 但是，如果修改注册表不正确，可能会出现严重问题。 因此，请确保谨慎执行这些步骤。 若要添加保护，请在修改注册表之前备起注册表。 然后，如果出现问题，可以还原注册表。 有关如何备份和还原注册表的详细信息，请单击以下文章编号以查看 Microsoft 知识库中的文章：

322756 如何在 Windows 中备份和还原注册表，或者通过修改注册表关闭服务器上的 SMB 签名。 为此，请按以下步骤操作：

1. 单击 “开始”，单击 “运行”，键入 regedit，然后单击 “确定”。

2. 找到并单击以下子项：
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters

3. 单击 enablesecuritysignature 条目。

4. 在 “编辑” 菜单上，单击 “修改”。

5. 在 “值”数据 框中，键入 0，然后单击 “确定”。

6. 退出注册表编辑器。

7. 重启计算机，或停止，然后重启服务器服务。 为此，请在命令提示符处键入以下命令，然后在键入每个命令后按 Enter：
   net stop 服务器
   net start server

请注意，客户端计算机上的相应密钥位于以下注册表子项中：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters 下面列出了转换为状态代码的错误代码编号和前面提到的逐字错误消息：

有关详细信息，请单击以下文章编号以查看 Microsoft 知识库中的文章：

324802 如何配置组策略以在 Windows Server 2003 中设置系统服务的安全性

816585 如何在 Windows Server 2003 中应用预定义的安全模板