如果您更改安全设置和用户权限分配，则可能会导致客户端、服务和程序问题发生

适用于： Microsoft Windows Server 2003 Standard Edition (32-bit x86)Microsoft Windows Server 2003 Datacenter Edition (32-bit x86)Microsoft Windows Server 2003 Enterprise Edition (32-bit x86) 详细

摘要

可以在本地策略和组策略中更改安全设置和用户权限分配，以帮助加强域控制器和成员计算机上的安全性。但是，提高安全性的弊端是会出现与客户端、服务和程序的不兼容问题。

本文介绍了当你在 Windows Server 2003 域或之前版本的 Windows Server 域中修改特定的安全设置和用户权限分配后，运行 Windows XP 或之前版本的 Windows 的客户端计算机上可能会发生的不兼容问题。

若要了解 Windows 7、Windows Server 2008 R2 和 Windows Server 2008 的组策略，请参阅以下文章：

对于 Windows 7，请参阅适用于 IT 专业人士的组策略管理
对于 Windows 7 和 Windows Server 2008 R2，请参阅组策略中的新增功能
对于 Windows Server 2008，请参阅有关 Windows Server 2008 中新的组策略首选项的信息

注意：本文中的其余内容与 Windows XP、Windows Server 2003 和之前版本的 Windows 有关。

Windows XP

若要更好地发现配置不当的安全设置，请使用组策略对象编辑器工具来更改安全设置。当使用组策略对象编辑器时，以下操作系统上的用户权限分配可有所增强：

Windows XP Professional Service Pack 2 (SP2)
Windows Server 2003 Service Pack 1 (SP1)

增强的功能是一个包含指向本文的链接的对话框。每当你将安全设置或用户权限分配更改为一个兼容性更低、限制性更强的设置时就会出现该对话框。如果使用注册表或安全模板直接更改相同的安全设置或用户权限分配，则得到的效果与在组策略对象编辑器中更改设置是相同的。只是将不会出现包含指向本文的链接的对话框。

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

我们建议您在将与安全相关的任何配置更改引入生产环境之前，先在测试林中验证它们的兼容性。测试林必须在以下方面与生产林相同：

客户端和服务器操作系统版本、客户端和服务器程序、Service Pack 版本、修补程序、架构更改、安全组、组成员、文件系统中对象上的权限、共享文件夹、注册表、Active Directory 目录服务、本地和组策略设置、对象计数类型和位置
执行的管理任务、使用的管理工具和用于执行管理任务的操作系统
执行的操作，如下所示：
- 计算机和用户登录身份验证
- 由用户、计算机和管理员进行的密码重置
- 浏览
- 从所有帐户域或资源域的所有客户端操作系统中使用 ACL 编辑器来设置文件系统、共享文件夹、注册表和 Active Directory 资源的权限
- 从管理和非管理帐户进行打印

Windows Server 2003 SP1

gpedit.msc 中的警告

为了帮助客户意识到他们正在编辑可能对其网络产生不利影响的用户权限或安全选项，gpedit.msc 中添加了两个警告机制。当管理员编辑可能对整个企业产生不利影响的用户权限时，他们将看到类似于让行标志的新图标。同时还将收到一条警告消息，其中包含一个指向 Microsoft 知识库文章 823659 的链接。此消息的文本如下所示：

修改此设置可能影响与客户端、服务和应用程序的兼容性。有关更多信息，请参阅“要修改的用户权限或安全选项”(Q823659)

如果你已通过 gpedit.msc 中的链接定向到此知识库文章，请确保阅读并了解所提供的说明及更改此设置的可能后果。下面列举了包含警告文本的用户权限：

从网络访问这台计算机
本地登录
跳过遍历检查
启用计算机和用户以进行受信任的委派

下面列举了包含警告和弹出消息的安全选项：

域成员: 对安全通道数据进行数字加密或签名(总是)
域成员: 需要强(Windows 2000 或更高版本)会话密钥
域控制器: LDAP 服务器签名要求
Microsoft 网络服务器: 数字签名的通信(总是)
网络访问: 允许匿名 SID/名称转换
网络访问: 不允许 SAM 帐户和共享的匿名枚举
网络安全: LAN Manager 身份验证级别
审核: 如果无法记录安全审核则立即关闭系统
网络访问: LDAP 客户端签名要求

更多信息

以下部分介绍了在更改 Windows NT 4.0 域、Windows 2000 域和 Windows Server 2003 域中的特定设置时可能出现的不兼容问题。

用户权限

下面的列表介绍了用户权限，确定了可能导致问题发生的配置设置，同时还介绍了您应该应用用户权限以及可能要删除用户权限的原因，并列举了在您配置用户权限后可能会出现的兼容性问题的示例。

从网络访问这台计算机
1. 背景
  
  与远程基于 Windows 计算机进行交互的能力需要从网络访问这台计算机用户权限。此类网络操作的示例有：
  - 在公共域或林中的域控制器之间复制 Active Directory
  - 用户和计算机向域控制器发出身份验证请求
  - 访问位于网络中远程计算机上的共享文件夹、打印机和其他系统服务
  通过将用户、计算机和服务帐户显式或隐式地添加到已被授予从网络访问这台计算机用户权限的安全组中或将它们从此类安全组中删除，可相应地使这些用户、计算机和服务帐户获得或失去该用户权限。例如，用户帐户或计算机帐户可能被管理员显式添加到某个自定义或内置的安全组中，也可能被操作系统隐式添加到计算安全组（如 Domain Users、Authenticated Users 或 Enterprise Domain Controllers）中。
  
  默认情况下，如果在默认域控制器的组策略对象 (GPO) 中定义了计算组（例如 Everyone 或 Authenticated Users（后者更好）；若是域控制器，则为 Enterprise Domain Controllers 组），则会为用户帐户和计算机帐户授予从网络访问这台计算机用户权限。
2. 危险配置
  
  以下是有害的配置设置：
  - 从此用户权限中删除 Enterprise Domain Controllers 安全组
  - 删除 Authenticated Users 组或授予用户、计算机和服务帐户通过网络连接到计算机的用户权限的显式组
  - 从此用户权限中删除所有用户和计算机
3. 授予此用户权限的原因
  - 通过向 Enterprise Domain Controllers 组授予从网络访问这台计算机用户权限，可满足在同一林中的域控制器之间进行 Active Directory 复制所必须具备的身份验证要求。
  - 此用户权限允许用户和计算机访问共享文件、打印机和系统服务，包括 Active Directory。
  - 用户使用早期版本的 Microsoft Outlook Web Access (OWA) 访问邮件时需要此用户权限。
4. 删除此用户权限的原因
  - 那些可以将计算机连接到网络的用户可以访问他们具有权限的远程计算机上的资源。例如，用户需要具备此用户权限才能连接到共享打印机和文件夹。如果向 Everyone 组授予此用户权限，并且某些共享文件夹同时配置有共享和 NTFS 文件系统权限以使相同的组具有读取权限，则任何人均可查看这些共享文件夹中的文件。但是，Windows Server 2003 的全新安装不大可能出现这种情况，因为 Windows Server 2003 中默认的共享和 NTFS 权限不包括 Everyone 组。对于从 Microsoft Windows NT 4.0 或 Windows 2000 升级的系统，这个弱点的危险性可能更高，因为这些操作系统默认的共享和文件系统权限的限制性不如 Windows Server 2003 中的默认权限严格。
  - 从此用户权限中删除 Enterprise Domain Controllers 组并没有有效的根据。
  - 通常会删除 Everyone 组，而倾向于使用 Authenticated Users 组。如果删除了 Everyone 组，则必须向 Authenticated Users 组授予此用户权限。
  - 升级到 Windows 2000 的 Windows NT 4.0 域不会显式对 Everyone、Authenticated Users 或 Enterprise Domain Controllers 组授予从网络访问这台计算机用户权限。因此，当你从 Windows NT 4.0 域策略中删除 Everyone 组时，升级到 Windows 2000 后，Active Directory 复制将失败并显示“拒绝访问”错误消息。升级 Windows NT 4.0 主域控制器 (PDC) 时，Windows Server 2003 中的 Winnt32.exe 通过对 Enterprise Domain Controllers 组授予此用户权限避免此错误配置。如果 Enterprise Domain Controllers 组不在组策略对象编辑器中，则向该组授予此用户权限。
5. 兼容性问题的示例
  - Windows 2000 和 Windows Server 2003：对以下分区进行复制将会失败，并且监视工具（如 REPLMON 和 REPADMIN）或事件日志中的复制事件会报告“拒绝访问”错误。
    - Active Directory 架构分区
    - 配置分区
    - 域分区
    - 全局编录分区
    - 应用程序分区
  - 所有 Microsoft 网络操作系统：除非已向用户或用户所属的安全组授予了此用户权限，否则来自远程网络客户端计算机的用户帐户身份验证将会失败。
  - 所有 Microsoft 网络操作系统：除非已向帐户或帐户所属的安全组授予了此用户权限，否则来自远程网络客户端的帐户身份验证将会失败。此情况适用于用户帐户、计算机帐户和服务帐户。
  - 所有 Microsoft 网络操作系统：如果从此用户权限中删除所有帐户，则会阻止任何帐户登录到域或访问网络资源。如果删除了计算组（例如 Enterprise Domain Controllers、Everyone 或 Authenticated Users），则必须将此用户权限显式授予帐户或帐户所属的安全组才能通过网络访问远程计算机。此情况适用于所有用户帐户、所有计算机帐户和所有服务帐户。
  - 所有 Microsoft 网络操作系统：本地管理员帐户使用“空”密码。在域环境中，不允许管理员帐户使用空密码进行网络连接。如果使用此配置，将收到“Access Denied”错误消息。
允许本地登录
1. 背景
  
  尝试在基于 Windows 的计算机的控制台上登录的用户（使用 Ctrl+Alt+Delete 键盘快捷方式）和尝试启动服务的帐户必须在主机计算机上拥有本地登录权限。本地登录操作的示例包括：管理员登录到企业中成员计算机或域控制器的控制台和域用户使用非特权帐户登录到成员计算机以访问其桌面。使用远程桌面连接或终端服务的用户在运行 Windows 2000 或 Windows XP 的目标计算机上必须具有允许本地登录用户权限，因为这些登录模式对于主机计算机来说是本地的。如果用户登录到启用了终端服务的服务器而又不具有此用户权限，但他们具有允许通过终端服务登录用户权限，则他们仍可以在 Windows Server 2003 域中启动远程交互式会话。
2. 危险配置
  
  以下是有害的配置设置：
  - 从默认域控制器的策略中删除管理安全组，包括 Account Operators、Backup Operators、Print Operators、Server Operators 和内置 Administrators 组。
  - 从默认域控制器的策略中删除域中成员计算机和域控制器上的组件和程序所使用的服务帐户。
  - 删除登录到域中成员计算机的控制台的用户或安全组。
  - 删除在成员计算机或工作组计算机的安全帐户管理器 (SAM) 数据库中定义的服务帐户。
  - 删除通过在域控制器上运行的终端服务进行身份验证的非内置管理帐户。
  - 通过 Everyone 组将域中的所有用户帐户显式或隐式添加到拒绝本地登录登录权限中。此配置会阻止用户登录到域中的任何成员计算机或任何域控制器。
3. 授予此用户权限的原因
  - 用户必须具有允许本地登录用户权限才能访问工作组计算机、成员计算机或域控制器的控制台或桌面。
  - 用户必须具有此用户权限才能通过在 Window 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 和更高版本的计算机上，如果添加允许本地登录用户权限，但又隐式或显式授予了拒绝本地登录登录权限，则帐户将无法登录域控制器的控制台。
跳过遍历检查
1. 背景
  
  “跳过遍历检查”用户权限允许用户浏览 NTFS 文件系统或注册表中的文件夹，而无需检查用户是否具有“遍历文件夹”的特殊访问权限。跳过遍历检查用户权限不允许用户列出文件夹的内容，只允许用户遍历其文件夹。
2. 危险配置
  
  以下是有害的配置设置：
  - 删除已登录基于 Windows 2000 或基于 Windows Server 2003 的终端服务计算机、但没有访问文件系统中文件和文件夹的权限的非管理帐户。
  - 从安全主体列表中删除 Everyone 组，默认情况下，这些安全主体具有此用户权限。根据 Windows 操作系统和许多程序的设计思路，系统认为可以合法访问计算机的任何人都应该具有跳过遍历检查用户权限。因此，从默认具有此用户权限的安全主体列表中删除 Everyone 组可能导致操作系统不稳定或程序故障。最好保留此设置的默认值。
3. 授予此用户权限的原因
  
  跳过遍历检查用户权限的默认设置是允许任何人跳过遍历检查。对于有经验的 Windows 系统管理员，这是预期的行为，他们会相应地配置文件系统访问控制列表 (SACL)。如果配置权限的管理员不了解该行为并认为不能访问父文件夹的用户将无法访问任何子文件夹的内容，则默认配置可能导致问题，这也是默认配置可能导致问题的唯一情况。
4. 删除此用户权限的原因
  
  非常注重安全性的组织可能很想从拥有跳过遍历检查用户权限的组列表中删除 Everyone 组，甚至可能删除 Users 组，以试图阻止对文件系统中文件或文件夹的访问。
5. 兼容性问题的示例
  - Windows 2000、Windows Server 2003：如果在运行 Windows 2000 或 Windows Server 2003 的计算机上删除或错误配置跳过遍历检查用户权限，则无法在域中的域控制器之间复制 SYVOL 文件夹中的组策略设置。
  - Windows 2000、Windows XP Professional、Windows Server 2003：如果删除或错误地配置了“跳过遍历检查”用户权限，则在从 SYSVOL 树中删除所需的文件系统权限时，运行 Windows 2000、Windows XP Professional 或 Windows Server 2003 的计算机将记录事件 1000 和 1202 而且无法应用计算机策略和用户策略。
    
    有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
    
    290647 在应用程序事件日志中每 5 分钟记录一次事件 ID 1000、1001
  - 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 的计算机上，如果未对用户授予跳过遍历检查用户权限，则这些用户可能无法访问共享文件夹或共享文件夹中的文件，并且可能收到“拒绝访问”错误消息。
    
    有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
    
    277644 用户尝试访问共享文件夹时看到“拒绝访问”错误消息
  - 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 的客户端计算机上，如果未向 Authenticated Users 组授予跳过遍历检查用户权限，则 net use * /home 命令会失败并显示“拒绝访问”错误消息。
  - Outlook Web Access：如果未向非管理员授予跳过遍历检查用户权限，则他们将无法登录 Microsoft Outlook Web Access，并会看到“拒绝访问”错误消息。

安全设置

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

审核: 如果无法记录安全审核则立即关闭系统
1. 背景
  - “审核: 如果无法记录安全审核则立即关闭系统”设置可确定在无法记录安全事件时是否关闭系统。如果审核系统不能记录这些事件，则受信任的计算机安全评估标准 (TCSEC) 方案的 C2 评估和信息技术安全评估的通用标准需要此设置来防止发生可审核事件。如果审核系统失败，则关闭系统，并出现停止错误消息。
  - 如果计算机不能将事件记录到安全日志中，则发生安全事故后可能没有关键证据或重要的故障排除信息可供查看。
2. 危险配置
  
  以下是一种有害的配置设置： “审核: 如果无法记录安全审核则立即关闭系统”设置打开，并且事件查看器中的安全事件日志的大小受以下选项约束：“不要覆盖事件(手动清除日志)”选项、“按需要覆盖事件”选项、“覆盖时间超过 number 天的事件”选项。请参见“兼容性问题的示例”部分，了解运行最初发布的 Windows 2000、Windows 2000 Service Pack 1 (SP1)、Windows 2000 SP2 或 Windows 2000 SP3 版本的计算机的特定风险。
3. 启用此设置的原因
  
  如果计算机不能将事件记录到安全日志中，则发生安全事故后可能没有关键证据或重要的故障排除信息可供查看。
4. 禁用此设置的原因
  - 启用了“审核: 如果无法记录安全审核则立即关闭系统”设置后，如果由于任何原因无法记录安全审核，则会关闭系统。如果安全审核日志已满并且其指定的保留方法为“不要覆盖事件(手动清除日志)”选项或“覆盖时间超过 number天的事件”选项时，通常无法记录事件。
  - 如果启用了“审核: 如果无法记录安全审核则立即关闭系统”设置后，则可能导致非常重的管理负担，尤其是在你还为安全日志打开了“不要覆盖事件(手动清除日志)”选项的情况下。此设置可以追查操作员的操作。例如，管理员可以使用内置管理员帐户或其他共享帐户来重置启用了审核的组织单位 (OU) 中所有用户、计算机和组上的权限，然后拒绝他们重置这些权限。但是，因为写入安全日志的大量登录事件和其他安全事件可能会使服务器不堪重负而被迫关闭，所以启用此设置确实会降低系统的稳定性。另外，因为不是正常关闭，还可能对操作系统、程序或数据造成无法修复的损坏。虽然 NTFS 可以在非正常系统关闭过程中确保文件系统的完整性得以保持，但它无法保证每个程序的每个数据文件在系统重新启动后仍处于可以使用的状态。
5. 符号名称：
  
  CrashOnAuditFail
6. 注册表路径：
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)
7. 兼容性问题的示例
  - Windows 2000：由于存在错误，运行最初发布的 Windows 2000、Windows 2000 SP1、Windows 2000 SP2 或 Windows Server SP3 版本的计算机可能在达到“最大日志大小”选项中指定的安全事件日志大小之前就会停止记录事件。此错误在 Windows 2000 Service Pack 4 (SP4) 中得到修复。在考虑启用此设置之前，确保您的 Windows 2000 域控制器安装了 Windows 2000 Service Pack 4。
    
    有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
    
    312571 事件日志在达到最大日志大小前停止记录事件
  - Windows 2000、Windows Server 2003：如果打开了“审核: 如果无法记录安全审核则立即关闭系统”设置，在安全日志已满并且不能覆盖现有事件日志项的情况下，运行 Windows 2000 或 Windows Server 2003 的计算机可能会停止响应，然后可能自行重启。当计算机重新启动后，出现以下停止错误消息：
    停止: C0000244 {审核失败}
    未能生成安全审核。
    要进行恢复，管理员必须登录，对安全日志进行存档（可选），清除安全日志，然后重置此选项（可选，根据需要进行）。
  - 用于 MS-DOS、Windows 95、Windows 98、Windows NT 4.0、Windows 2000、Windows XP、Windows Server 2003 的 Microsoft 网络客户端：尝试登录到域的非管理员会收到以下错误消息：
    您的帐户配置为阻止您使用该计算机。请尝试其他计算机。
  - Windows 2000：在基于 Windows 2000 的计算机上，非管理员将无法登录远程访问服务器，并且会看到类似以下内容的错误消息：
    未知用户或错误密码
    有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
    
    285665 错误消息：你的帐户已配置为阻止你使用此计算机
  - Windows 2000：在 Windows 2000 域控制器上，站点间消息服务 (Ismserv.exe) 将停止且无法重启。 DCDIAG 会将此错误报告为“failed test services 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 错误。
域控制器: LDAP 服务器签名要求
1. 背景
  
  “域控制器: LDAP 服务器签名要求”安全设置可确定轻型目录访问协议 (LDAP) 服务器是否需要 LDAP 客户端协商数据签名。此策略设置的可能值如下所示：
  - 无：绑定到服务器不需要数据签名。如果客户端请求数据签名，则服务器将支持它。
  - 要求签名：除非正在使用传输层安全/安全套接字层 (TLS/SSL)，否则必须协商 LDAP 数据签名选项。
  - 未定义：未启用或禁用此设置。
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 域控制器上没有安装正确的 Service Pack，则不支持 LDAP 签名的客户端将无法对域控制器和全局编录执行 LDAP 查询。
  - 客户端和服务器间 LDAP 通信的网络跟踪会被加密，从而使检查 LDAP 对话变得困难。
  - 如果用支持 LDAP 签名的程序管理基于 Windows 2000 的服务器，并且这些程序是从运行 Windows 2000 SP4、Windows XP 或 Windows Server 2003 的客户端计算机运行的，则基于 Windows 2000 的服务器必须安装 Windows 2000 Service Pack 3 (SP3) 或更高版本。有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
    
    325465 使用 Windows Server 2003 管理工具时，Windows 2000 域控制器需要 Service Pack 3 或更高版本
5. 符号名称：
  
  LDAPServerIntegrity
6. 注册表路径：
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)
7. 兼容性问题的示例
  - 简单绑定会失败，您会收到以下错误消息：
    Ldap_simple_bind_s() failed: 需要加强的身份验证。
  - Windows 2000 Service Pack 4、Windows XP、Windows Server 2003：在运行 Windows 2000 SP4、Windows XP 或 Windows Server 2003 的客户端上，当协商 NTLM 身份验证时，如果域控制器运行的是低于 Windows 2000 SP3 的版本，则某些 Active Directory 管理工具将不能针对此类域控制器正常执行操作。
    
    有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
    
    325465 使用 Windows Server 2003 管理工具时，Windows 2000 域控制器需要 Service Pack 3 或更高版本
  - Windows 2000 Service Pack 4、Windows XP、Windows Server 2003：在运行 Windows 2000 SP4、Windows XP 或 Windows Server 2003 的客户端上，如果域控制器运行的是低于 Windows 2000 SP3 的版本，而以此类域控制器为目标的某些 Active Directory 管理工具使用的是 IP 地址（例如“dsa.msc /server=x.x.x.x”，
    其中 x.x.x.x 是 IP 地址），则这些管理工具将不能正常执行操作。
    
    有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
    
    325465 使用 Windows Server 2003 管理工具时，Windows 2000 域控制器需要 Service Pack 3 或更高版本
  - Windows 2000 Service Pack 4、Windows XP、Windows Server 2003：在运行 Windows 2000 SP4、Windows XP 或 Windows Server 2003 的客户端上，如果域控制器运行的是低于 Windows 2000 SP3 的版本，则以该域控制器为目标的某些 Active Directory 管理工具将无法执行正常操作。
    
    有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
    
    325465 使用 Windows Server 2003 管理工具时，Windows 2000 域控制器需要 Service Pack 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 域之间的信任。
域成员: 对安全通道数据进行数字加密或签名(总是)
1. 背景
  - 启用“域成员: 对安全通道数据进行数字加密或签名(总是)”可以防止与不能对所有安全通道数据进行签名或加密的任何域控制器建立安全通道。为了协助保护身份验证流量免遭中间人攻击、重播攻击和其他类型的网络攻击，基于 Windows 的计算机可通过网络登录服务创建一个称为安全通道的信道，以便对计算机帐户进行身份验证。当一个域中的用户连接到远程域中的网络资源时也可使用安全通道。这种多域身份验证（亦称为传递身份验证）允许已加入某个域的基于 Windows 的计算机有权访问该域及所有受信任的域中的用户帐户数据库。
  - 要在成员计算机上启用“域成员: 对安全通道数据进行数字加密或签名(总是)”设置，该成员所属的域中的所有域控制器都必须能够对所有安全通道数据进行签名或加密。这意味着所有这些域控制器都必须运行 Windows NT 4.0 Service Pack 6a (SP6a) 或更高版本。
  - 启用“域成员: 对安全通道数据进行数字加密或签名(总是)”设置，则会自动启用“域成员: 对安全通道数据进行数字加密或签名(如果可能)”设置。
2. 危险配置
  
  在并非所有域控制器都可以签名或加密安全通道数据的域中启用“域成员: 对安全通道数据进行数字加密或签名(总是)”设置是一种有害的配置设置。
3. 启用此设置的原因
  
  未经签名的网络通信容易受到中间人攻击，入侵者可以捕获服务器和客户端之间的数据包，对数据包进行修改，然后将数据包转发到客户端。当此行为发生在轻型目录访问协议 (LDAP) 服务器上时，入侵者会导致客户端根据 LDAP 目录中的错误记录而进行决策。您可以降低企业网络遭受这种攻击的风险，方法是实施严格的物理安全措施以帮助保护网络基础结构。此外，实施 Internet 协议安全性 (IPSec) 身份验证标头模式还可有助于阻止中间人攻击。此模式可为 IP 通信执行相互身份验证和数据包完整性检查。
4. 禁用此设置的原因
  - 本地或外部域中的计算机确实支持加密的安全通道。
  - 并非域中所有的域控制器都具有适当的 Service Pack 版本级别来支持加密的安全通道。
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 网络客户端将收到以下错误消息之一：
    登录失败: 用户名未知或密码错误。
    
    没有指定登录会话的用户会话密钥。
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 Second Edition 中，目录服务客户端在通过 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 workstation
  net start workstation
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 签名，否则该客户端无法建立会话。
    
    在高安全性网络中启用数字签名有助于防止对客户端和服务器的模拟。这种模拟称为会话劫持。能够访问客户端或服务器所在网络的攻击者会使用会话劫持工具中断、结束或窃取正在进行的会话。攻击者可以截获并修改未经签名的子网带宽管理器 (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 Second Edition 中，目录服务客户端在通过 NTLM 身份验证向 Windows Server 2003 服务器验证身份时使用 SMB 签名。但是，目录服务客户端在通过 NTLMv2 身份验证向这些服务器验证身份时并不使用 SMB 签名。另外，Windows 2000 服务器不响应来自这些客户端的 SMB 签名请求。有关详细信息，请参阅第 10 项： “网络安全: Lan Manager 身份验证级别”。
2. 危险配置
  
  以下是一种有害的配置设置：在本地域或外部域中，当不兼容的基于 Windows 和第三方操作系统的客户端计算机进行访问时，在服务器和域控制器上启用“Microsoft 网络服务器: 数字签名的通信(总是)”设置。
3. 启用此设置的原因
  - 直接通过注册表或通过组策略设置启用此设置的所有客户端计算机都支持 SMB 签名。换句话说，启用了此设置的所有客户端计算机都可运行 Windows 95（安装了 DS 客户端）、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 客户端将无法成功通过登录身份验证，并会收到以下错误消息：
    您提供的域密码不正确，或访问登录服务器被拒绝。
    有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
    
    811497 Windows 95 或 Windows NT 4.0 客户端登录 Windows Server 2003 域时出现错误消息
  - Windows NT 4.0：运行版本低于 Windows NT 4.0 Service Pack 3 (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
    
    有关相关主题的更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
    
    224287 错误消息：发生系统错误 1240。该帐户不能从此站点登录。
  - Windows Server 2003：默认情况下，运行 Windows Server 2003 的域控制器上的安全设置被配置为帮助防止恶意用户截获或篡改域控制器通信。为了使用户与运行 Windows Server 2003 的域控制器成功通信，客户端计算机必须同时使用 SMB 签名和加密，或者使用安全通道通信签名。默认情况下，运行安装了 Service Pack 2 (SP2) 或更早版本的 Windows NT 4.0 客户端和运行 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 客户端
    - 未安装 SP3 或更高版本的基于 Microsoft Windows NT 4.0 的计算机
    - Novell Netware 6 CIFS 客户端
    - 不支持 SMB 签名的 SAMBA SMB 客户端
8. 重新启动要求
  
  重新启动计算机，或重新启动服务器服务。为此，请在命令提示符下键入以下命令。键入每个命令之后按 Enter 键。
  net stop server
  net start server
网络访问: 允许匿名 SID/名称转换
1. 背景
  
  “网络访问: 允许匿名 SID/名称转换”安全设置可确定匿名用户是否可以请求另一用户的安全标识号 (SID) 属性。
2. 危险配置
  
  启用“网络访问: 允许匿名 SID/名称转换”设置是一种有害的配置设置。
3. 启用此设置的原因
  
  如果禁用“网络访问: 允许匿名 SID/名称转换”设置，较早的操作系统或应用程序可能无法与 Windows Server 2003 域进行通信。例如，以下操作系统、服务或应用程序可能无法工作：
  - 基于 Windows NT 4.0 的“远程访问服务”服务器
  - 在基于 Windows NT 3.x 或 Windows NT 4.0 的计算机上运行的 Microsoft SQL Server
  - 在 Windows NT 3.x 域或 Windows NT 4.0 域中的基于 Windows 2000 的计算机上运行的远程访问服务
  - 在 Windows NT 3.x 域或 Windows NT 4.0 域中基于 Windows 2000 的计算机上运行的 SQL Server
  - 在 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 编辑器中显示“Account Unknown”错误消息。
网络访问: 不允许 SAM 帐户的匿名枚举
1. 背景
  - “网络访问: 不允许 SAM 帐户的匿名枚举”设置可确定为了能够匿名连接到计算机，需要授予哪些权限。 Windows 允许匿名用户执行某些活动，例如枚举工作站和服务器安全帐户管理器 (SAM) 帐户和网络共享的名称。例如，管理员可以使用此功能向不维护可逆信任的受信任域中的用户授予访问权限。一旦进行会话，匿名用户就可能具有基于“网络访问: 让每个人(Everyone)权限应用于匿名用户”设置中的设置或对象的自定义访问控制列表 (DACL) 授予 Everyone 组相同的访问权限。
    
    通常，在 SMB 会话设置过程中，较早版本的客户端（或下级客户端）将请求匿名连接。在这些情况下，网络跟踪将显示 SMB 进程 ID (PID) 为客户端重定向程序，例如，在 Windows 2000 中为 0xFEFF，在 Windows NT 中为 0xCAFE。 RPC 也可能尝试进行匿名连接。
  - 重要说明此设置对域控制器没有影响。在域控制器上，此行为由“Pre-Windows 2000 compatible Access”中是否存在“NT AUTHORITY\ANONYMOUS LOGON”控制。
  - 在 Windows 2000 中，一个类似的设置对匿名连接的额外限制可管理 RestrictAnonymous 注册表值。该值的位置如下所示：
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
    有关 RestrictAnonymous 注册表值的更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
    
    246261 如何在 Windows 2000 中使用 RestrictAnonymous 注册表值
    
    143474 限制匿名登录用户可使用的信息
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 Network Discovery（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 的计算机上的用户将无法更改其用户帐户的密码。
网络访问: 不允许 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) 将无法启动网络登录服务、获得备份浏览器的列表或同步同一域中 Windows 2000 或 Windows Server 2003 域控制器上的 SAM 数据库。
  - Windows 2000：如果在客户端计算机的本地安全策略中启用没有显式匿名权限就无法访问设置，则 Windows NT 4.0 域中的基于 Windows 2000 的成员计算机将无法查看外部域中的打印机。
  - Windows 2000： Windows 2000 域用户将无法添加 Active Directory 中的网络打印机；但是，在树视图中选择打印机之后，他们便可以添加这些打印机了。
  - Windows 2000：在基于 Windows 2000 的计算机上，ALC 编辑器将无法添加受信任的 Windows NT 4.0 域中的用户或全局组。
  - ADMT 版本 2：使用 Active Directory 迁移工具 (ADMT) 版本 2 在各林间迁移的用户帐户的密码迁移将会失败。
    
    有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
    
    322981 如何对使用 ADMTv2 在林间迁移密码进行疑难解答
  - Outlook 客户端：对于 Microsoft Exchange Outlook 客户端，全局地址列表将显示为空。
    
    有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
    321169 在将文件从 Windows XP 复制到 Windows 2000 域控制器时 SMB 性能下降
  - SMS： Microsoft Systems Management Server (SMS) 网络发现将无法获得操作系统信息。因此，它将在发现数据记录 (DDR) 的 SMS DDR 属性的 OperatingSystemNameandVersion 属性中写入“Unknown”。
  - SMS：当使用 SMS 管理员用户向导浏览用户和组时，不会列出任何用户或组。此外，高级客户端也无法与管理点进行通信。管理点上要求进行匿名访问。
  - SMS：在 SMS 2.0 和打开了拓扑、客户端和客户端操作系统网络发现选项的远程客户端安装中使用网络发现功能时，可能会发现计算机但无法进行安装。

网络安全: Lan Manager 身份验证级别

背景

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 会话安全。域控制器接受 LM、NTLM 和 NTLMv2 身份验证。
3	仅发送 NTLMv2 响应	客户端只使用 NTLMv2 身份验证并在服务器支持时使用 NTLMv2 会话安全。域控制器接受 LM、NTLM 和 NTLMv2 身份验证。
4	仅发送 NTLMv2 响应/拒绝 LM	客户端只使用 NTLMv2 身份验证并在服务器支持时使用 NTLMv2 会话安全。域控制器拒绝 LM，而只接受 NTLM 和 NTLMv2 身份验证。
5	仅发送 NTLMv2 响应/拒绝 LM 和 NTLM	客户端只使用 NTLMv2 身份验证并在服务器支持时使用 NTLMv2 会话安全。域控制器拒绝 LM 和 NTLM，而只接受 NTLMv2 身份验证。

注意在 Windows 95、Windows 98 和 Windows 98 Second Edition 中，目录服务客户端在通过 NTLM 身份验证向 Windows Server 2003 服务器验证身份时使用 SMB 签名。但是，目录服务客户端在通过 NTLMv2 身份验证向这些服务器验证身份时并不使用 SMB 签名。另外，Windows 2000 服务器不响应来自这些客户端的 SMB 签名请求。

检查 LM 身份验证级别：必须更改服务器上的策略以允许使用 NTLM，或者必须配置客户端计算机以支持 NTLMv2。

如果要连接到的目标计算机上的策略设置为 (5) 仅发送 NTLMv2 响应\拒绝 LM 和 NTLM，那么必须降低该计算机上的设置，或者对安全性进行设置使其与要从中进行连接的源计算机的设置相同。

找到可以更改 LAN Manager 身份验证级别的正确位置，以便将客户端和服务器设置为同一级别。找到设置 LAN Manager 身份验证级别的策略后，如果希望与运行较早版本 Windows 的计算机建立连接，请将该值至少降低到 (1) 发送 LM 和 NTLM - 如果已协商，则使用 NTLMv2 会话安全。不兼容设置的一个结果便是：如果服务器需要 NTLMv2（值 5），但客户端配置为仅使用 LM 和 NTLMv1（值 0），则尝试身份验证的用户会因使用了无效密码而无法登录，同时会因此增加无效密码计数。如果配置了帐户锁定，则可能最终会锁定该用户。

例如，您可能必须查看域控制器，或者检查域控制器的策略。

查看域控制器

注意你可能必须在所有域控制器上重复以下过程。

单击“开始”，指向“程序”，然后单击“管理工具”。
在“本地安全设置”下，展开“本地策略”。
单击“安全选项”。
双击“网络安全: LAN 管理器身份验证级别”，然后单击列表中的值。

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

检查域控制器的策略

单击“开始”，指向“程序”，然后单击“管理工具”。
在“域控制器安全”策略中，展开“安全设置”，然后展开“本地策略”。
单击“安全选项”。
双击“网络安全: LAN 管理器身份验证级别”，然后单击列表中的值。

注意

您可能还必须检查在网站级别、域级别或组织单位 (OU) 级别链接的策略，以确定必须配置 LAN Manager 身份验证级别的位置。
如果将组策略设置作为默认域策略实施，则该策略将应用于域中的所有计算机。
如果将某一组策略设置作为默认域控制器的策略来执行，则该策略仅适用于域控制器的 OU 中的服务器。
最好在策略应用程序层次结构中所需范围的最低实体中设置 LAN Manager 身份验证级别。

Windows Server 2003 有一个仅使用 NTLMv2 的新默认设置。默认情况下，基于 Windows Server 2003 和基于 Windows 2000 Server SP3 的域控制器已启用“Microsoft 网络服务器: 数字签名的通信(总是)”策略。此设置要求 SMB 服务器执行 SMB 数据包签名。已经对 Windows Server 2003 进行了更改，原因是任何组织中的域控制器、文件服务器、网络结构服务器和 Web 服务器均要求采用不同的设置，以最大程度地提高其安全性。

如果您想在网络中实施 NTLMv2 身份验证，请一定要确保将域中的所有计算机都设置为使用此身份验证级别。如果对 Windows 95 或 Windows 98 以及 Windows NT 4.0 应用了 Active Directory Client Extension，则此客户端扩展将使用 NTLMv2 中提供的改进的身份验证功能。由于运行以下任何操作系统的客户端计算机都不受 Windows 2000 组策略对象的影响，因此您可能需要手动配置这些客户端：

Microsoft Windows NT 4.0
Microsoft Windows Millennium Edition
Microsoft Windows 98
Microsoft Windows 95

注意如果启用了“网络安全”：在下一次更改密码时不存储 LAN 管理器哈希值”策略或设置 NoLMHash 注册表项，未安装目录服务客户端的基于 Windows 95 和 Windows 98 客户端在密码更改后将无法登录到域。

许多第三方 CIFS 服务器（如 Novell Netware 6）都无法识别 NTLMv2 而只使用 NTLM。因此，高于 2 的级别都不允许进行连接。还有不使用扩展会话安全的第三方 SMB 客户端。在这些情况下，不考虑资源服务器的 LmCompatiblityLevel。然后，服务器打包此过时请求，并将其发送到用户域控制器。然后，域控制器上的设置决定使用什么哈希来验证请求，以及这些哈希是否满足域控制器的安全要求。

有关如何手动配置 LAN 管理器身份验证级别的更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

147706 如何在 Windows NT 上禁用 LM 身份验证

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

312630 Outlook 不断提示你提供登录凭据

2701704 审核事件将身份验证程序包显示为 NTLMv1，而不是 NTLMv2

有关 LM 身份验证级别的更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

239869 如何启用 NTLM 2 身份验证

危险配置

以下是有害的配置设置：
- 以明文形式发送密码和拒绝 NTLMv2 协商的非限制性设置
- 阻止不兼容的客户端或域控制器协商通用身份验证协议的限制性设置
- 要求在运行早于 Windows NT 4.0 Service Pack 4 (SP4) 版本的成员计算机和域控制器上进行 NTLMv2 身份验证
- 要求在未安装 Windows 目录服务客户端的 Windows 95 客户端或 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 帮助文件。
修改此设置的原因
- 您想要提高组织中客户端和域控制器支持的最低的通用身份验证协议。
- 在业务需要安全的身份验证的情况下，您希望禁止对 LM 和 NTLM 协议的协商。
禁用此设置的原因

已将客户端或服务器身份验证要求（或两者同时）提高到了通过通用协议也无法进行身份验证的程度。
符号名称：

LmCompatibilityLevel
注册表路径：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel
兼容性问题的示例
- Windows Server 2003：默认情况下，Windows Server 2003 NTLMv2 的“发送 NTLM 响应”设置已启用。因此，在初始安装后，当您尝试连接到基于 Windows NT 4.0 的群集或基于 LanManager V2.1 的服务器（如 OS/2 Lanserver）时，Windows Server 2003 将收到“Access Denied”错误消息。在尝试从较早版本的客户端连接到基于 Windows Server 2003 的服务器时，也会发生此问题。
- 应该安装 Windows 2000 安全汇总包 1 (SRP1)。SRP1 会强制使用 NTLM 版本 2 (NTLMv2)。此汇总包是在 Windows 2000 Service Pack 2 (SP2) 之后发布的。有关 SRP1 的更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
  
  311401 Windows 2000 安全汇总包 1（2002 年 1 月）
- Windows 7 和 Windows Server 2008 R2：许多第三方 CIFS 服务器（如 Novell Netware 6 或基于 Linux 的 Samba 服务器）都无法识别 NTLMv2 而只使用 NTLM。因此，高于 2 的级别都不允许进行连接。如今在此版本的操作系统中，LmCompatibilityLevel 默认值已更改为 3。因此升级 Windows 时，这些第三方筛选器可能停止工作。
- 即使 Microsoft Outlook 客户端已经登录到域，这些客户端也可能会收到要求提供凭据的提示。用户提供凭据后，将收到下面的错误消息： Windows 7 和 Windows Server 2008 R2
  提供的登录凭证不正确。请确保用户名和域正确，然后重新输入密码。
  即使将“登录网络安全性”设置设为“Passthrough”或“密码验证”，您也可能会在启动 Outlook 时收到要求提供凭据的提示。键入正确的凭据后，可能会收到下面的错误消息：
  提供的登录凭证不正确。
  网络监视器跟踪可能会显示全局编录发出的远程过程调用 (RPC) 失败，状态为 0x5。状态 0x5 表示“拒绝访问”。
- Windows 2000：网络监视器捕获功能可能会在 TCP/IP 上的 NetBIOS (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 管理器身份验证级别本地安全策略”选项设置为 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 服务
  
  User Authentication Module (UAM)： Microsoft UAM (User Authentication Module) 提供了一种对登录 Windows AFP (AppleTalk Filing Protocol) 服务器所使用的密码进行加密的方法。 Apple User Authentication Module (UAM) 仅提供最简单的加密或者根本不加密。因此，在 LAN 或 Internet 上，您的密码很容易被截获。虽然没有要求 UAM，但它确实可以为运行 Macintosh 服务的 Windows 2000 服务器提供加密的身份验证。此版本包括对 NTLMv2 128 位加密身份验证和与 MacOS X 10.1 兼容的版本的支持。
  
  默认情况下，适用于 Macintosh 服务器的 Windows Server 2003 服务仅允许使用 Microsoft 身份验证。
  
  有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
  
  834498 Macintosh 客户端无法连接到 Windows Server 2003 上的 Mac 服务
- Windows Server 2008、Windows Server 2003、Windows XP 和 Windows 2000：如果将 LMCompatibilityLevel 值配置为 0 或 1，然后将 NoLMHash 值配置为 1，则可能会拒绝应用程序和组件通过 NTLM 进行访问。此问题是由于计算机被配置为启用 LM 而非使用 LM 存储的密码造成的。
  
  如果将 NoLMHash 值配置为 1，则必须将 LMCompatibilityLevel 值配置为 2 或更大的值。

网络安全: 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
事件日志: 安全日志最大值
1. 背景
  
  “事件日志: 安全日志最大值”安全设置可指定安全事件日志的最大大小。此日志的最大大小是 4 GB。若要找到此设置，请展开
  “Windows 设置”，然后展开“安全设置”。
2. 危险配置
  
  以下是有害的配置设置：
  - 当启用了“审核: 如果无法记录安全审核则立即关闭系统”设置时限制安全日志大小和安全日志保留方法。有关详细信息，请参阅本文中的“审核: 如果无法记录安全审核则立即关闭系统”部分。
  - 限制安全日志大小，以便覆盖有用的安全事件。
3. 增大此设置的原因
  
  业务和安全需要可能要求您增大安全日志大小以处理更多的安全日志详细信息或将安全日志保留更长时间。
4. 减小此设置的原因
  
  事件查看器日志是内存映射的文件。事件日志的最大大小受本地计算机上的物理内存量和可用于事件日志进程的虚拟内存限制。增大日志大小如果超过了可用于事件查看器的虚拟内存量，则维护的日志条目数不会增加。
5. 兼容性问题的示例
  
  Windows 2000：如果打开了“不要覆盖事件(手动清除日志)”选项，则运行 Windows 2000 Service Pack 4 (SP4) 以前版本的计算机可能在达到事件查看器中“最大日志大小”设置指定的大小前就停止在事件日志中记录事件。
  
  有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：
  
  312571 事件日志在达到最大日志大小前停止记录事件
事件日志: 保留安全日志
1. 背景
  
  “事件日志: 保留安全日志”安全设置可确定安全日志的“覆盖”方法。若要找到此设置，请展开“Windows 设置”，然后展开“安全设置”。
2. 危险配置
  
  以下是有害的配置设置：
  - 未能在记录的安全事件被改写前保留所有记录的安全事件
  - 将“安全日志最大值”设置配置的太小，以致安全事件被覆盖
  - 在启用“审核: 如果无法记录安全审核则立即关闭系统”安全设置时限制安全日志大小和保留方法
3. 启用此设置的原因
  
  仅当选择“按天数覆盖事件”保留方法时，才启用此设置。如果使用轮询事件的事件关联系统，请确保天数至少是轮询频率的三倍。这样可以允许失败的轮询周期。
网络访问: 让每个人(Everyone)权限应用于匿名用户
1. 背景
  
  默认情况下，“网络访问: 让每个人(Everyone)权限应用于匿名用户”设置在 Windows Server 2003 上会设置为“未定义”。默认情况下，Windows Server 2003 不包括 Everyone 组中的匿名访问令牌。
2. 兼容性问题的示例
  
  如果 Windows Server 2003 域是帐户域，并且 Windows NT 4.0 域是资源域，则
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
  Windows Server 2003 域是帐户域且 Windows NT 4.0 域是资源域时，[REG_DWORD]=0x0 会中断 Windows Server 2003 和 Windows NT 4.0 之间的信任创建。这种情况意味着帐户域在 Windows NT 4.0 上是受信任方，资源域在 Windows Server 2003 一侧上是信任方。发生此行为是由于初始匿名连接之后要启动信任的进程是 ACL'd，它具有包含 Windows NT 4.0 上匿名 SID 的 Everyone 令牌。
3. 修改此设置的原因
  
  该值必须设置为 0x1，或者通过使用域控制器的 OU 上的 GPO 将该值设置为： “网络访问: 让每个人(Everyone)权限应用于匿名用户 - 启用”以允许信任创建。
  
  注意对于大多数其他安全设置，要使其处于最安全的状态，都是将值上升而不是下降至 0x0。更安全的做法是在主域控制器仿真器上（而不是在所有域控制器上）更改注册表。如果由于某种原因移开了主域控制器仿真器角色，则必须在新服务器上更新注册表。
  
  设置该值后需要重新启动。
4. 注册表路径
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
NTLMv2 身份验证
1. 会话安全
  
  会话安全确定客户端和服务器会话的最低安全标准。最好在 Microsoft 管理控制台“组策略编辑器”管理单元中验证以下安全策略设置：
  - 计算机设置\Windows 设置\安全设置\本地策略\安全选项
  - 网络安全: 基于 NTLM SSP(包括安全 RPC)服务器的最小会话安全
  - 网络安全: 基于 NTLM SSP(包括安全 RPC)客户端的最小会话安全
  这些设置的选项如下所示：
  - 要求消息的完整性
  - 要求消息的保密性
  - 要求 NTLMv2 会话安全
  - 要求 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 Second Edition 的客户端、基于 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 身份验证（而非 NTLMv2 身份验证）下，对 Windows 2003 服务器执行 SMB 签名。此外，Windows 2000 服务器将不响应这些客户端发出的 SMB 签名请求。

虽然我们不建议使用这种方法，但是您可以阻止在域中运行 Windows Server 2003 的所有域控制器要求提供 SMB 签名。要配置此安全设置，请按照下列步骤操作：

打开默认域控制器的策略。
打开计算机配置\Windows 设置\安全设置\本地策略\安全选项文件夹。
找到并单击“Microsoft 网络服务器: 数字签名的通信(总是)”策略设置，然后单击“禁用”。

重要说明本部分（或称方法或任务）包含有关如何修改注册表的步骤。但是，注册表修改不当可能会出现严重问题。因此，请务必严格按照这些步骤操作。为了获得进一步的保护，请在修改注册表之前对其进行备份。这样就可以在出现问题时还原注册表。若要详细了解如何备份和还原注册表，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

322756 如何在 Windows 中备份和还原注册表

或者，通过修改注册表来关闭服务器上的 SMB 签名。为此，请按照下列步骤操作：

单击“开始”，单击“运行”，键入 regedit，然后单击“确定”。
找到并单击下面的子项：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters
单击 enablesecuritysignature 项。
在“编辑”菜单上，单击“修改”。
在“数值数据”框中，键入 0，然后单击“确定”。
退出注册表编辑器。
重启计算机，或者先停止服务器服务，然后重启该服务。为此，请在命令提示符下键入以下命令，并在键入每条命令后按 Enter 键：
net stop server
net start server

注意客户端计算机上的对应项位于以下注册表子项中：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters

下面列出了对应于状态代码和前面提到的错误消息的转换错误代码号：

错误 5
ERROR_ACCESS_DENIED

访问被拒绝。

错误 1326

ERROR_LOGON_FAILURE

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

错误 1788

ERROR_TRUSTED_DOMAIN_FAILURE

主域和受信任的域之间的信任关系失败。

错误 1789

ERROR_TRUSTED_RELATIONSHIP_FAILURE

此工作站和主域间的信任关系失败。

有关更多信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

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

161372 如何在 Windows NT 中启用 SMB 签名

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

820281 使用 Outlook 2003 HTTP 上的 RPC 功能连接到 Exchange Server 2003 时必须提供 Windows 帐户凭据

本地策略和组策略，更改安全设置和用户权限分配兼容性问题