目录服务组件更新

  • 项目

适用范围：Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012

作者：Justin Turner，Windows 组的高级支持升级工程师

注意

本内容由 Microsoft 客户支持工程师编写，适用于正在查找比 TechNet 主题通常提供的内容更深入的有关 Windows Server 2012 R2 中的功能和解决方案的技术说明的有经验管理员和系统架构师。 但是，它未经过相同的编辑审批，因此某些语言可能看起来不如通常在 TechNet 上找到的内容那么精练。

本课介绍 Windows Server 2012 R2 中的目录服务组件更新。

学习内容

将介绍以下新的目录服务组件更新：

域和林功能级别

概述

本部分简要介绍域和林功能级别的更改。

新的 DFL 和 FFL

该版本提供新的域和林功能级别：

  • 林功能级别：Windows Server 2012 R2

  • 域功能级别：Windows Server 2012 R2

Windows Server 2012 R2 域功能级别可用于支持以下功能：

  1. 针对受保护用户的 DC 端保护

    向 Windows Server 2012 R2 域进行身份验证的受保护用户再也不能执行以下操作：

    • 使用 NTLM 身份验证进行验证

    • 在 Kerberos 预身份验证中使用 DES 或 RC4 密码套件

    • 使用不受约束的或受约束的委派进行委派

    • 在超出最初的 4 小时生存期后续订用户票证 (TGT)

  2. 身份验证策略

    新的基于林的 Active Directory 策略，这些策略可以应用到 Windows Server 2012 R2 域中的帐户，用于控制一个帐户可以从哪些主机登录，并将身份验证的访问控制条件应用到作为帐户运行的服务

  3. 身份验证策略接收器

    新的基于林的 Active Directory 对象，可以在用户、托管服务和计算机，以及帐户（用于对帐户分类，以便实施身份验证策略或进行身份验证隔离）之间创建关系。

有关详细信息，请参阅“如何配置受保护的帐户”。

除了上述功能外，Windows Server 2012 R2 域功能级别还可确保域中的任何域控制器都运行 Windows Server 2012 R2。 Windows Server 2012 R2 林功能级别不提供任何新功能，但可确保在林中创建的任何新域都自动在 Windows Server 2012 R2 域功能级别运行。

在创建新域时强制实施最低 DFL

Windows Server 2008 DFL 是创建新域时支持的最低功能级别。

注意

FRS 的弃用是通过以下方式实现的：使用户无法通过服务器管理器或 Windows PowerShell 安装域功能级别低于 Windows Server 2008 的新域。

降低林和域功能级别

在创建新域和新林时，林和域功能级别默认设置为 Windows Server 2012 R2，但可以使用 Windows PowerShell 来降低。

若要使用 Windows PowerShell 提高或降低林功能级别，请使用 Set-ADForestMode cmdlet。

若要将 contoso.com FFL 设置为 Windows Server 2008 模式，请运行：

Set-ADForestMode -ForestMode Windows2008Forest -Identity contoso.com

若要使用 Windows PowerShell 提高或降低域功能级别，请使用 Set-ADDomainMode cmdlet。

若要将 contoso.com DFL 设置为 Windows Server 2008 模式，请运行：

Set-ADDomainMode -DomainMode Windows2008Domain -Identity contoso.com

可以将运行 Windows Server 2012 R2 的 DC 作为附加副本提升到运行 2003 DFL 的现有域。

在现有林中创建新域

Screenshot that shows the Domain Controller Options page.

ADPREP

此版本中没有新的林或域操作。

这些 .ldf 文件包含设备注册服务的架构更改。

  1. Sch59

  2. Sch61

  3. Sch62

  4. Sch63

  5. Sch64

  6. Sch65

  7. Sch67

工作文件夹：

  1. Sch66

MSODS：

  1. Sch60

身份验证策略和接收器

  1. Sch68

  2. Sch69

弃用 NTFRS

概述

FRS 在 Windows Server 2012 R2 中已弃用。 FRS 的弃用是通过强制实施 Windows Server 2008 的最低域功能级别 (DFL) 来实现的。 仅当使用服务器管理器或 Windows PowerShell 创建新域时才强制实施此措施。

将 -DomainMode 参数与 Install-ADDSForest 或 Install-ADDSDomain cmdlet 结合使用以指定域功能级别。 此参数支持的值可以是有效整数或相应的枚举字符串值。 例如，若要将域模式级别设置为 Windows Server 2008 R2，可以指定值 4 或“Win2008R2”。 从 Server 2012 R2 执行这些 cmdlet 时，有效值包括 Windows Server 2008（3，Win2008）、Windows Server 2008 R2（4，Win2008R2）、Windows Server 2012（5，Win2012）和 Windows Server 2012 R2（6，Win2012R2）。 域功能级别不能低于林控制级别，但可以高于林控制级别。 由于 FRS 在此版本中已弃用，因此在从 Windows Server 2012 R2 执行这些 cmdlet 时，Windows Server 2003（2，Win2003）不是这些 cmdlet 的可识别参数。

Screenshot of a terminal window that shows the -DomainMode parameter used with the Install-ADDSForest cmdlet.

Screenshot of a terminal window that shows how to use the Install-ADDSForest cmdlet.

LDAP 查询优化程序更改

概述

已重新评估并进一步优化了 LDAP 查询优化器算法。 结果是复杂查询的 LDAP 搜索效率和 LDAP 搜索时间得到了性能改进。

注意

在开发人员方面：通过改进从 LDAP 查询到 ESE 查询的映射改进了搜索性能。 超过一定复杂程度的 LDAP 筛选器会阻止选择优化的索引，导致性能急剧下降（下降 1000 倍或更多）。 此项更改改变了我们为 LDAP 查询选择索引的方式，从而避免了此问题。

注意

对 LDAP 查询优化器算法进行了全面的大幅修改，从而：

  • 缩短了搜索时间
  • 提升了效率，使 DC 可以完成更多任务
  • 减少了有关 AD 性能问题的支持呼叫
  • 已向后移植到 Windows Server 2008 R2 (KB 2862304)

背景

搜索 Active Directory 的功能是域控制器提供的一项核心服务。 其他服务和业务线应用程序依赖于 Active Directory 搜索。 如果此功能不可用，业务运营可能会中断。 作为一项核心且重度使用的服务，域控制器必须高效处理 LDAP 搜索流量。 LDAP 查询优化器算法尝试通过将 LDAP 搜索筛选器映射到结果集（可以通过已在数据库中编制索引的记录来提供）来尽可能提高 LDAP 搜索效率。 已重新评估此算法并进一步将其优化。 结果是复杂查询的 LDAP 搜索效率和 LDAP 搜索时间得到了性能改进。

更改详细信息

LDAP 搜索包含：

  • 层次结构中开始搜索的位置（NC 头、OU、对象）

  • 搜索筛选器

  • 要返回的属性列表

搜索过程总结如下：

  1. 尽可能简化搜索筛选器。

  2. 选择一组返回最小涵盖集的索引键。

  3. 执行一个或多个索引键的交集，以减小涵盖集。

  4. 对于涵盖集中的每条记录，评估筛选表达式和安全性。 如果筛选器计算为 TRUE 并授予了访问权限，则将此记录返回给客户端。

LDAP 查询优化工作修改了步骤 2 和 3，以减小涵盖集的大小。 更具体地说，当前实现将选择重复的索引键并执行冗余交集。

新旧算法的比较

此示例中低效 LDAP 搜索的目标是一个 Windows Server 2012 域控制器。 由于找不到更有效的索引，完成搜索大约花费了 44 秒。

adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=justintu@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfind.txt

Using server: WINSRV-DC1.blue.contoso.com:389

<removed search results>

Statistics
=====
Elapsed Time: 44640 (ms)
Returned 324 entries of 553896 visited - (0.06%)

Used Filter:
 ( |  ( &  ( |  (cn=justintu)  (postalCode=80304)  (userPrincipalName=justintu@blue.contoso.com) )  ( |  (objectClass=person)  (cn=justintu) ) )  ( &  (cn=justintu)  (objectClass=person) ) )

Used Indices:
 DNT_index:516615:N

Pages Referenced          : 4619650
Pages Read From Disk      : 973
Pages Pre-read From Disk  : 180898
Pages Dirtied             : 0
Pages Re-Dirtied          : 0
Log Records Generated     : 0
Log Record Bytes Generated: 0

使用新算法的示例结果

此示例重复与上面完全相同的搜索，但目标是一个 Windows Server 2012 R2 域控制器。 由于 LDAP 查询优化器算法得到改进，该搜索在不到一秒内即已完成。

adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=dhunt@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfindBLUE.txt

Using server: winblueDC1.blue.contoso.com:389

.<removed search results>

Statistics
=====
Elapsed Time: 672 (ms)
Returned 324 entries of 648 visited - (50.00%)

Used Filter:
 ( |  ( &  ( |  (cn=justintu)  (postalCode=80304)  (userPrincipalName=justintu@blue.contoso.com) )  ( |  (objectClass=person)  (cn=justintu) ) )  ( &  (cn=justintu)  (objectClass=person) ) )

Used Indices:
 idx_userPrincipalName:648:N
 idx_postalCode:323:N
 idx_cn:1:N

Pages Referenced          : 15350
Pages Read From Disk      : 176
Pages Pre-read From Disk  : 2
Pages Dirtied             : 0
Pages Re-Dirtied          : 0
Log Records Generated     : 0
Log Record Bytes Generated: 0

  • 如果无法优化树：

    • 例如：树中的表达式针对未编制索引的列

    • 记录阻止优化的索引列表

    • 通过 ETW 跟踪和事件 ID 1644 公开

      Screenshot that highlights the Attributes Preventing Optimization value.

在 LDP 中启用统计信息控件

  1. 打开 LDP.exe，然后连接并绑定到域控制器。

  2. 在“选项”菜单中，选择“控件”。

  3. 在“控件”对话框中，展开“加载预定义控件”下拉菜单，选择“搜索统计信息”，然后选择“确定”。

    Screenshot that highlights the Load Predefined list.

  4. 在“浏览”菜单中，选择“搜索”

  5. 在“搜索”对话框中，选择“选项”按钮。

  6. 确保在“搜索选项”对话框中选中“扩展”复选框，然后选择“确定”。

    Screenshot that highlights the the Extended option.

试试看：使用 LDP 返回查询统计信息

在域控制器上或者从已加入域并安装了 AD DS 工具的客户端或服务器执行以下操作。 针对 Windows Server 2012 DC 和 Windows Server 2012 R2 DC 重复以下操作。

  1. 查看创建更高效的启用 Microsoft AD 的应用程序一文，并在需要时参考此文。

  2. 使用 LDP 启用搜索统计信息（请参阅在 LDP 中启用统计信息控件）

  3. 执行几次 LDAP 搜索并观察结果顶部的统计信息。 你将在其他活动中重复相同的搜索，因此请将这些信息记录在记事本文本文件中。

  4. 执行一个 LDAP 搜索，因为使用了属性索引，查询优化器应该可以优化该搜索

  5. 尝试构造一个需要很长时间才能完成的搜索（可能需要增大“时间限制”选项，使搜索不会超时）。

其他资源

什么是 Active Directory 搜索？

Active Directory 搜索的工作原理

创建更高效的启用 Microsoft Active Directory 的应用程序

951581 在 AD 或 LDS/ADAM 目录服务中，LDAP 查询的执行速度比预期要慢，并可能会记录事件 ID 1644

1644 事件改进

概述

此项更新将额外的 LDAP 搜索结果统计信息添加到了事件 ID 1644 以帮助进行故障排除。 此外，还可以使用一个新的注册表值来启用基于时间的阈值的日志记录。 这些改进已通过知识库文章 2800945 在 Windows Server 2012 和 Windows Server 2008 R2 SP1 中推出，今后将在 Windows Server 2008 SP2 中推出。

注意

  • 已将额外的 LDAP 搜索统计信息添加到事件 ID 1644，以帮助排查 LDAP 搜索低效或开销较高的问题
  • 现在可以指定搜索时间阈值（例如，记录运行时间超过 100 毫秒的搜索的日志事件 1644），而无需指定高开销和低效搜索结果阈值

背景

在排查 Active Directory 性能问题时，很明显 LDAP 搜索活动可能是导致问题的原因。 你决定启用日志记录，以便可以看到域控制器处理的高开销或低效 LDAP 查询。 若要启用日志记录，必须设置现场工程诊断值，并可以选择性地指定高开销/低效搜索结果阈值。 将现场工程日志记录级别值设为 5 后，满足这些条件的任何搜索都会记录在目录服务事件日志中，事件 ID 为 1644。

该事件包含：

  • 客户端 IP 和端口

  • 起始节点

  • 筛选器

  • 搜索范围

  • 属性选择

  • 服务器控件

  • 访问的条目

  • 返回的条目

但是，该事件中缺少关键数据，例如搜索操作所花费的时间，以及使用了哪些索引（如果有）。

添加到事件 1644 的其他搜索统计信息

  • 使用的索引

  • 引用的页

  • 从磁盘读取的页

  • 从磁盘预读的页

  • 修改的干净页

  • 修改的脏页

  • 搜索时间

  • 阻止优化的属性

事件 1644 日志记录的新基于时间的阈值注册表值

如果不指定高开销和低效搜索结果阈值的话，你可以指定搜索时间阈值。 如果你想要要记录所有耗时 50 毫秒或更长时间的搜索结果，请指定十进制值 50/十六进制值 32（此外，设置现场工程值）。

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Search Time Threshold (msecs)"=dword:00000032

新旧事件 ID 1644 的比较

OLD

Screenshot that shows the old event ID 1664.

新建…

directory services updates

试试看：使用事件日志返回查询统计信息

  1. 针对 Windows Server 2012 DC 和 Windows Server 2012 R2 DC 重复以下操作。 每次搜索后，观察两个 DC 上的事件 ID 1644。

  2. 运行 regedit，在 Windows Server 2012 R2 DC 上使用基于时间的阈值启用事件 ID 1644 日志记录，在 Windows Server 2012 DC 上使用旧方法。

  3. 执行多个超过阈值的 LDAP 搜索，并观察结果顶部的统计信息。 使用之前记录的 LDAP 查询并重复相同的搜索。

  4. 执行由于一个或多个属性未编制索引而无法由查询优化器优化的 LDAP 搜索。

Active Directory 复制吞吐量改进

概述

AD 复制使用 RPC 进行复制传输。 默认情况下，RPC 使用 8K 传输缓冲区和 5K 数据包大小。 最终效果是，发送端实例将传输三个数据包（大约 15K 数据），然后必须等待网络往返才能发送更多数据包。 假设往返时间为 3 毫秒，则最高吞吐量大约为 40Mbps，即使在 1Gbps 或 10Gbps 网络上也是如此。

注意

  • 此项更新将最大 AD 复制吞吐量从 40Mbps 调整到了大约 600Mbps。

    • 这样就增大了 RPC 发送缓冲区的大小，从而减少了网络往返次数

  • 在高速、高延迟网络上效果最为明显。

此项更新通过将 RPC 发送缓冲区大小从 8K 更改为 256KB，将最大吞吐量提高到了大约 600Mbps。 此项更改允许 TCP 窗口大小超过 8K，从而减少了网络往返次数。

注意

没有任何可配置的设置可以修改此行为。

其他资源

Active Directory 复制模型的工作原理