理解Active Directory中的FSMO角色

如果您的组织基于 Microsoft Active Directory运行，那么您就需要依赖一个或多个域控制器来维持 AD 的运作。表面上看，Active Directory 似乎运行在一种对等（peer-to-peer）模型中：每个域控制器（DC）都拥有创建、修改和删除 AD 对象的权限。这是因为每个域控制器都保存了其域分区的可写副本；唯一的例外是只读 DC。一旦完成更改或新增操作，它们就会通过多主（multi-master）复制与其他 DC 同步。不过，某些关键操作被限制在被分配了称为 Flexible Single Master Operations (FSMO) 角色或操作主机（operation master）角色的特定 DC 上。

下面我们将详细说明 FSMO 角色在 Active Directory 中的重要性，并分享一些最佳实践，以确保实现有效的管理与保护。

FSMO 角色简介

FSMO 是 Flexible Single Master Operations 的缩写，这一术语源自微软为解决 AD 中多主复制模型的局限性而开展的工作。FSMO 角色通过将特定关键任务分配给指定的控制器，并提供单一权威的流程变更机制，来确保跨 Windows 域的 Active Directory 的正常运行与一致性。通过在特定域控制器中集中这些操作，FSMO 角色有助于维护 Active Directory 环境的完整性与稳定性。

共有五个独特的 FSMO 角色。默认情况下，当你创建一个 Active Directory domain 时，所有 FSMO 角色都会被分配给林中的第一台域控制器。如有需要，域管理员可以将 FSMO 角色重新分配给其他域控制器。

为什么需要 FSMO 角色

在深入了解实际的 FSMO 角色之前，重要的是先理解推动其产生需求的多主（multi-master）架构。

多主（Multi-master）模型 vs. 单主（Single-master）模型

Microsoft 的早期网络架构基于单主（Single-Master）模型：由一台服务器保存一个可写的数据库副本，其中包含所有用户和计算机对象账户。该服务器的唯一职责是对账户数据库进行新增或修改。网络中的其他服务器仅保存数据库的只读副本。虽然这些服务器可以对用户进行身份验证，但无法更改数据库内容。如果主服务器下线或发生故障，就无法创建新的账户，也无法修改现有账户。这就形成了单点故障。

为了解决单主（Single-Master）模型的限制，Microsoft 在 Active Directory（AD）中转向了多主（Multi-Master）模型：每个域控制器（DC）都维护账户数据库的可写副本。该设计通过冗余和弹性来提高系统的可靠性——即使某一台 DC 不可用，操作也仍可继续。不过，这种多主方案也带来了潜在冲突：不同的 DC 可能会同时尝试做出彼此矛盾的更改。为防止此类不一致并保持 AD 的完整性与性能，Microsoft 引入了 Flexible Single Master Operations（FSMO）角色。

AD 中 FSMO 角色的重要性

通过分配 FSMO 角色，Active Directory 可确保架构（schema）更新、域名（domain naming）以及时间同步等关键操作以有序且一致的方式完成。如果承载特定 FSMO 角色的 DC 出现故障，该角色可以转移到另一台 DC，从而确保服务连续性。FSMO 角色的分配对于维持平衡且高效的网络至关重要；组织还可以根据自身的具体需求，以及在性能和冗余方面的最佳实践来定制这种分配方案。

解释 5 个 FSMO Active Directory 角色

Active Directory 具有五个独特的 FSMO 角色：

• 架构主控（森林级别）
• 域名主控（森林级别）
• 相对 ID（RID）主控（域级别）
• 主域控制器（PDC）仿真器（域级别）
• 基础结构主控（域级别）

让我们进一步了解每个 FSMO 角色，以及它在 Active Directory 基础架构中的具体功能：

架构主控

What is the schema master FSMO role?

架构主机（Schema Master）是企业级 FSMO 角色，因此在 Active Directory 林中只有一个 Schema Master。架构定义对象类（对象类型，例如用户、组和计算机）以及在 AD 数据库 中可能存在的属性。

架构主机（schema master）何时以及如何使用

有时需要修改架构，例如添加必需的新对象类型或属性。为了防止出现重叠或冲突的更新，只有承担 Schema Master 角色的 DC 才能处理对 AD 架构的更改。只要进行架构更新，Schema Master 就会确保这些更改会复制到林中的所有其他 DC。

如果需要进行架构更新，则必须保证 Schema Master 可用。不过，在大多数环境中，架构更改相对不常见。可能需要进行架构更改的情况包括：升级 Active Directory、集成某些类型的企业软件、提高林的功能级别，以及将 DC 的操作系统升级到高于当前林中所存在版本的版本。

域命名主机（Domain Naming Master）

域命名主机（Domain Naming Master）的角色与职责

域命名主机（Domain Naming Master）是企业级角色；在 Active Directory Forest 中只有一个域命名主机。它是唯一能够向该 Forest 添加新域和应用分区，或从该 Forest 中删除现有域和应用分区的域控制器（DC）。

常见的域命名主机（Domain Naming Master）相关场景

随着业务的发展，你可能需要调整 AD Forest；或者由于兼并或收购，可能会向你的 Forest 添加额外的域。由于域和分区的添加与删除并不频繁，而且通常不是对时间要求极高的操作，因此域命名主机（Domain Naming Master）角色的开销很小，其丢失通常预计只会带来很小或几乎不带来任何运维影响。

RID Master

RID Master 角色是什么？

Relative Identifier Master (RID Master) 是一个域级角色；在 AD 森林中的每个域里都有一个 RID Master。它负责按其域的顺序向该域中的 DC 分配 RID 池，以确保每个安全主体（例如用户或组）都拥有唯一的安全标识符。

SID 是一种长度可变的字母数字字符串，外观如下：

      `S-1-5-21-1234567890-1234567890-1234567890-1001`
      

字符串的第一部分是域 SID，在同一域中的所有 SID 都相同。最后一部分是 RID，它在该域中的每个 SID 都是唯一的。在上面的示例中，1001 是分配给该域中某个特定安全主体的 RID。

RID Master 的功能与用法

RID Master 会将 RID 池分配给域控制器（DC）。每个池都由一组唯一且连续的 RID 范围组成，DC 在创建安全主体（security principal）时可以使用这些 RID 来生成唯一的 SID。通过对 RID 的分配进行集中管理，RID Master 确保不会有两个域控制器向不同的安全主体分配相同的 RID，从而保证每个 SID 在域内的唯一性。

一旦某个 DC 从 RID Master 分配到一个 RID 池，DC 在每次创建 AD 对象时就不需要与 RID Master 进行通信。不过，如果丢失了域的 RID Master，最终将导致无法在该域中创建新对象，因为 DC 上的这些 RID 池会被逐步用尽。在成熟的 AD 环境中，由于创建的对象相对较少，因此这一过程会花费相当长的时间。

通常，RID Master 角色会分配给域中的主域控制器（PDC），因为 PDC 通常会受到管理员最多的关注，因此具备较高的可用性。在成熟的域中，RID Master 角色产生的开销几乎可以忽略不计。尽管该角色不像某些其他角色那样关键，但仍然需要确保与 RID Master 的连接。

PDC Emulator（PDCE）

理解 PDC Emulator 角色：说明与历史

Primary Domain Controller (PDC) 是 Windows NT 早期的术语，那时只有一台域控制器（DC）拥有目录的可写副本。如今，域中的大多数 DC 都是可写的，但仍然有一台指定的 DC 会模拟 PDC 的角色。在 Active Directory Forest 中，每个域都包含一台承担 PDCE 角色的 DC。

PDC Emulator 在 AD 中的功能

Primary Domain Controller Emulator 负责以下事项：

• 时间同步 — PDCE 是该域的权威时间源；所有工作站和成员服务器都会与 PDC emulator 同步时间。在多域 Forest 中，Forest 根域里的 PDCE 会作为 Forest 中所有其他 PDC emulator 的时间管理员（timekeeper）。为了在整个 Forest 内保持准确的计时，应将根域中的 PDC emulator 配置为与外部可靠的时间源进行同步。时间非常关键。例如，如果请求主机的时钟与进行身份验证的 DC 的时钟之间的差异超过指定的最大值（默认是 5 分钟），Kerberos 身份验证将失败；这有助于抵御某些恶意活动，例如重放攻击（replay attacks）。
• 密码更改与身份验证 —当用户的密码被更改时，该更改最初会在对用户进行身份验证的 DC 上完成。已提交的密码更新会立即复制到该域的 PDCE。若某个账户尝试对尚未通过计划复制收到最近一次密码更改的 DC 进行身份验证，则该请求会传递给域的 PDCE；由 PDCE 处理身份验证请求，并指示发出请求的 DC 接受或拒绝该请求。此行为确保即使最近的更改尚未通过计划复制完全传播，密码也能可靠地被处理。
• 帐户锁定状态 — 同样地，如果 由于多次登录失败而导致帐户被锁定，系统会立即在 PDC emulator 上处理锁定，并将锁定状态复制到域中的所有 DC，以确保被锁定的帐户无法登录到另一台 DC。管理员解锁帐户时，该更改会立即在整个域中复制。
• 组策略更新 — 如果对某个 组策略对象 (GPO) 进行更新，这些更新最初会提交到具有 PDC Emulator 角色的 DC。这样可以防止由于某个 GPO 恰好在大约同一时间被两台 DC 修改而引发的版本冲突。
• 向后兼容 — 在仍然拥有依赖于 Windows NT 的旧式设备或软件的组织中，PDCE emulator 可以作为 PDC 使用。其中包括充当 Master Browser（主浏览器）的功能，用于收集并分发网络中应用程序和设备的信息。
• 分布式文件系统（DSF） — 默认情况下，DFS 根服务器会定期向 PDCE 请求更新的 DFS 命名空间信息。此行为可能导致资源瓶颈，但启用 Dfsutil.exe RootScalability 参数后，将允许 DFS 根服务器从最近的 DC 请求更新。

应将 PDC Emulator 角色放置在高度可访问、连接良好且性能高的 DC 上，因为丢失承担此角色的 DC 可能会对运营产生即时且显著的影响。

基础结构主机

基础结构主机 FSMO 的作用

基础结构主机是一个域级角色，其主要功能是在多域林中处理跨域对象的引用。基础结构主机会将其所在域中的对象与同一林中其他域中的对象进行比较，并将它们与global catalog 服务器同步。

何时以及为什么需要基础结构主机

在某些情况下，这些操作并不需要。显然，在只有一个 AD domain 的环境中，无需处理跨域引用。如果某个域中的所有 DC 都是 global catalog 主机（这在今天很常见，因为网络带宽更好），那么它们都将拥有最新信息，而无需依赖 Infrastructure Master。

Infrastructure Master 承担以下职责：

• 跨域对象引用 — 在多域森林中，一个域的对象可能会在另一个域中被引用。一个典型例子是：当来自一个域的用户被添加到另一个域的安全组中时。在这种情况下，会在该安全组所在的域中创建一个占位符（称为“phantom object”）来表示来自另一个域的用户。Phantom objects 会跟踪并管理对已删除对象的持久性引用，以及引用森林中另一个域对象的、带链接值的属性。
• 更新组到用户的引用 —Infrastructure Master 负责在跨域对象引用中更新对象的 SID 和区分名（DN），并在森林中的各域之间转换 GUID、SID 和 DN。
• 清理过期对象 — Infrastructure Master 会定期检查其所在域中不再有效的对象（例如来自已删除的信任关系的对象），并将其移除。

如果承担“基础结构主机（Infrastructure Master）”角色的 DC 发生故障，影响主要是管理层面的。尽管在其缺席期间，跨域对象链接名称可能无法正确解析，但跨域组成员关系仍会继续生效。

在森林与域上下文中的 FSMO 角色

森林级 FSMO 角色

如上表所示，最后两个 FSMO 角色会在整个森林范围内运行，这意味着森林中只能有一台 DC 承担该角色。换句话说，每个 Active Directory 森林都只有一个 Schema Master 和一个 Domain Naming Master。

域级 FSMO 角色

另外三个 FSMO 角色在单个域的管辖范围内运行。在每个域中，都有一个 Infrastructure Master、一个 RID Master 和一个 PDC Emulator。每个域都会在一个或多个 DC 上包含多个域的环境中托管这三个 FSMO 角色。

管理 FSMO 角色

识别 FSMO 角色持有者

了解你在 AD 环境中哪些 DC 承载 5 个 FSMO 角色非常重要。识别拥有 FSMO 角色的 DC 有多种方法。一个快速的方法是使用命令提示符并输入以下命令：

      netdom query fsmo /domain:<DomainName>
      

下面是一个示例：

你也可以使用以下脚本在 PowerShell 中完成：

      (Get-ADForest).Domains |

ForEach-Object{ Get-ADDomainController -Server $_ -Filter {OperationMasterRoles -like "*"}} | `

Select-Object Domain, HostName, OperationMasterRoles
      

下面是一个使用 PowerShell 的示例：

你也可以使用 Windows Active Directory Tools 找出哪些 DC 被分配了 FSMO 角色。使用 Active Directory Users and Computers：右键单击你的域，然后选择“Operations Masters”，如下所示：

然后点击每个选项卡，找到三个域 FSMO。

你可以使用 Active Directory Domains and Trusts t，通过右键单击 Active Directory Domains and Trust，找出哪台 DC 承担“Domain Naming Master”角色，然后选择 Operations Master，如下所示。

然后将弹出以下窗口，用于识别当前角色的持有者。

识别架构主 FSMO 的过程要复杂一些。你可以使用 Active Directory Schema 管理单元找到它的身份信息；不过，该管理单元在 Windows Server 中默认不会显示。要访问它，你需要使用 Schmmgmt.dll 文件对其进行注册。具体操作：单击“开始(Start) > 运行(Run)”，在“打开(Open)”框中输入 regsvr32 schmmgmt.dll。然后按如下所示单击“确定(OK)”。

注册成功后，你需要执行以下操作：

1. 在控制台( Console )菜单中，点击 Add/Remove Snap-in，点击“添加(Add)”，双击“Active Directory Schema”，点击“关闭(Close)”，然后点击“确定(OK)”。
2. 在左上窗格中右键单击 Active Directory Schema，然后点击“Operations Masters”，以查看持有架构主(schema master)角色的服务器。

下面的截图中展示了一个示例：

这样你就可以打开该“管理单元/插件（snap-in）”，在其中右键单击 Active Directory Schema，然后选择 Operations Master。

传输与接管 FSMO 角色

何时以及如何传输 FSMO 角色

尽管 Active Directory 会自动将 FSMO 角色分配给你的 DC，但有时你可能会希望把某个角色转移到另一台 DC。比如，你可能需要对当前持有已分配角色的 DC 进行维护并将其停机。域管理员和企业管理员都可以根据需要自行决定在域控制器之间移动这些角色。

接管 FSMO 角色

进行 FSMO 角色转移时，当前持有者和目标域控制器角色都必须处于激活状态，并且已连接到网络。若当前 FSMO 角色持有者不可用且无法恢复，则需要由域管理员或企业管理员接管该角色。由于该操作更为突兀，接管 FSMO 角色应仅在确有必要时执行。

最佳实践与故障排除

优化 FSMO 角色放置以提高效率

尽管关于 Active Directory 中 FSMO 角色的放置没有一成不变的硬性规则，但以下建议将帮助您获得最佳结果：

• 请将 PDC Emulator 和 RID Master 放置在一台可靠的域控制器上，该域控制器具有良好的网络连接，并且能够被其他域控制器随时访问。因为它们的角色对日常 Active Directory 活动至关重要。
• 如果可能的话，Infrastructure Master 不应放置在全球编录服务器（Global Catalog Server）上。当然，如果所有 DC 都是全球编录服务器，则这一点就无法实现。
• 将两个林侧角色（Schema Master 和 Domain Naming Master）放在同一台 DC 上即可，因为它们并不经常被使用。

常见问题及解决方案

有一些关键情况可能表明 FSMO 不可用。例如，如果 Schema Master 已停机，那么尝试更新 AD 架构（schema）的任何操作都会产生错误。如果 Domain Naming Master 无法访问，您也将无法在该林中添加或删除域。在这些情况下，您需要确认是哪一台 DC 承担该角色，并验证该 DC 是否可访问。

无法访问已分配 FSMO 角色的 DC 可能由多种因素导致，包括：

• 服务器处于离线状态或已关机
• 网络连接问题
• DNS 配置错误或故障

排查这些问题可能需要使用网络诊断工具来验证整个网络的连通性，核查 DNS 设置（包括 SRV 记录），并确保承载 FSMO 角色的服务器在物理和逻辑层面都处于健康状态。如果问题仍然存在，请考虑将该角色转移到另一台正常的 DC；或者作为最后手段，如果当前持有者永久不可用，请执行夺取（seizing）该角色。

监控与审计 FSMO 角色

由于这些 FSMO 角色至关重要，因此应定期监控承载这些角色的服务器。最基础的层面上，您可以查看域控制器上的事件日志。特定事件可以指示 FSMO 角色何时被转移或被“夺取”。您的组织也可能会使用监控或管理软件，其中可能包含与 FSMO 角色变更相关的历史数据或告警。此外，还有一些第三方工具提供了更强的功能。一个示例是 Netwrix Auditor for Active Directory 可自动化监控 FSMO 角色，并能在发现任何可疑或意外的变更时及时提醒您。也建议将这些 FMSO 角色变更发生的时间记录下来，以便在必要时可以访问此类历史信息。

Netwrix 如何提供帮助

正如我们所见，FSMO 角色对于业务连续性和安全性都至关重要。因此，必须审计您所有与 FSMO 角色相关的变更。Netwrix Auditor for Active Directory 会自动化完成此监控，并能在发现任何可疑变更时提醒您，从而让您在它导致停机或发生 data breach 之前采取行动。

当然，保护 FSMO 角色只是安全策略的一部分。Netwrix Auditor for Active Directory 为您所需的核心系统提供全面的可视性和控制。它会持续监控并分析 Active Directory 中的变更及其他活动，以发现新兴威胁，并让您能够迅速、有效地响应，从而最大限度地降低对业务流程、用户生产力以及安全性的影响。

结论

AD 中的 FSMO 角色就是一个例子，说明在表面之下会发生多少事情。虽然林级别的 FSMO 角色并非每天都至关重要，但你的业务确实依赖于你的域级 FSMO 角色和服务。除了周期性出现的预期故障带来的威胁之外，这些角色还会成为旨在扰乱业务运营的恶意威胁行为者的理想目标。这意味着你需要对 AD 环境的复杂性保持可视性。

AD 支持团队正越来越多地采用自动化监控工具来应对这些挑战。这些解决方案可以提供：

• 更深入地了解 FSMO 角色持有者的状态和性能
• 关于 FSMO 角色分配中的任何变更或异常的实时告警
• 主动识别潜在问题，防止其升级
• 强大的审计能力，可追踪历史变更。

这种主动的做法可以帮助 AD 管理员维护 AD 基础设施的健康与稳定，并强化组织整体的安全态势。

常见问题

FSMO 是什么？

FSMO 是 Flexible Single Master Operations 的缩写。这些操作是分配给特定域控制器的特殊职责，用于防止冲突并确保网络的顺畅运行。

FSMO 是什么，以及它的作用是什么？

Active Directory 基于多主模型，其中 FSMO 会将指定的权限分配给指定的域控制器。

5 个 FSMO 角色分别是什么？以及如何检查这些角色的持有者？

5 个 FSMO 角色如下：

• Schema Master：负责更新 AD 架构。
• Domain Naming Master：控制在林中添加或移除域。
• RID（Relative ID）Master：向 DC 分配 RID 池，以创建唯一的安全标识符（SID）。
• PDC（Primary Domain Controller）Emulator：负责处理密码更改和时间同步，并在某些类型的身份验证中充当后备。
• Infrastructure Master：管理对其他域中对象的引用

使用标准 Active Directory tools 和 PowerShell，您可以查明哪些域控制器是这些 FSMO 的角色持有者。

FSMO 角色位于哪里？

默认情况下，Active Directory 林的根域的第一台域控制器会托管架构主控（Schema Master）和域命名主控（Domain Naming Master）。每个域的第一台域控制器会托管 PDC Emulator、RID Master 和 Infrastructure Master。Active Directory 管理员可以在需要时将这些角色移动到其他 DC。

为什么要劫持（seize）FSMO 角色？

如果域控制器突然离线，其 FSMO 角色将变得不可用。如果无法与原角色持有者建立连接，则无法执行角色转移。在这种情况下，需要劫持（seize）该角色，并将其分配给另一台 DC。

最重要的 FSMO 角色是什么？

尽管所有 FSMO 角色都很重要，但 PDC Emulator 最为关键，因为它负责管理域的时间、密码更改以及 组策略 配置。在某些情况下，旧系统可能依赖它来作为处理身份验证请求的唯一方式。

如何查找 FSMO 角色？

有多种方法可以找出哪些域控制器拥有 Active Directory 的 FSMO 角色。一种方法是在命令提示符中使用 “netdom query fsmo” 命令。你也可以使用 Active Directory 工具和 PowerShell 来查明每个角色由哪台服务器托管。

FSMO 角色应放置在何处？

如果你的 AD 环境中只有一台或两台域控制器，那么在这方面你可选择的余地就不多了。所有 FSMO 角色都应分配给与森林中其他所有 DC 具有良好连接性的 DC。若可能，Infrastructure Master 不应放置在全局编录（global catalog）服务器上。

哪些 FSMO 角色应该放在一起？

Schema Master 和 Domain Naming Master 这两个基于森林（forest-level）的 FSMO 角色应放置在同一台 DC 上，但这仅是建议。

Active Directory中的FSMO角色是什么？

Microsoft通过指定特定的域控制器作为五项敏感操作的唯一权威，降低了冲突风险。这些是Flexible Single Master Operations（FSMO）角色，理解它们对于管理稳定且良好治理的Active Directory环境至关重要。

Active Directory 采用多主模型，每个域控制器都维护其域分区的可写副本。该设计提供了弹性（即使个别DC离线，操作仍可继续），但也引入了冲突更改的可能性。

本指南解释了五个FSMO角色的每一个，介绍了如何识别持有这些角色的域控制器，并提供了在需要时转移或夺取角色所需的命令。

五个FSMO角色中的每一个都属于两个范围之一：

默认情况下，当您提升林中的第一个域控制器时，所有五个FSMO角色都会分配到该DC。管理员可以随着环境的增长和运营需求的变化重新分配它们。

FSMO代表Flexible Single Master Operations，指的是五个Active Directory操作，这些操作一次只能由一个指定的域控制器处理。通过将这些操作限制在每个范围内的单一权威DC，Active Directory防止了多个控制器同时尝试执行时可能发生的数据冲突。

Netwrix Auditor监控Active Directory中的FSMO角色分配，并在角色转移或接管发生在计划维护窗口之外时提醒您的团队。获取演示

为什么多主复制需要单主操作

森林范围的角色在整个 AD 森林中只有一个持有者，无论森林包含多少个域。域范围的角色在每个 Active Directory 域 中有且仅有一个持有者，因此一个包含三个域的森林包含三个 RID Masters、三个 PDC Emulators 和三个 Infrastructure Masters。

FSMO 角色的重要性

冲突预防

早期的网络目录服务依赖于单主模型：一台服务器持有账户数据库的可写副本，而其他所有服务器则保持只读副本。该模型防止了冲突，但造成了对单一服务器的高度依赖：如果该服务器离线，就无法创建新账户，也无法修改现有账户。

FSMO 角色保持 Active Directory 的一致性、安全性和可恢复性。只有当出现问题时，它们的重要性才显现：域控制器故障、在压力下需要角色转移，或攻击者针对角色持有者。

Active Directory 用多主复制取代了该模型。每个域控制器都可以写入其本地目录副本，且更改通过计划复制传播到所有其他控制器。该设计提供了弹性，但暴露了两个控制器同时操作时会破坏目录的特定操作。FSMO 角色通过在多主模型无法安全运行的地方强制单主权威来解决此问题。

身份验证可靠性

安全态势

如果没有指定的单主控权限，两个域控制器可能会同时处理冲突操作：一个将RID 1050分配给新用户帐户，而另一个将相同的RID分配给不同帐户，或者两个管理员用不兼容的属性定义扩展架构。任何结果都会导致目录损坏且无法顺利解决。FSMO角色确保每个敏感操作在任何时候都有唯一的权威来源。

灾难恢复

什么是5个FSMO角色

PDC Emulator的FSMO指定是您的帮助台能够解锁账户并使其在整个域内几秒内生效的原因。没有它，Kerberos authentication的决策将依赖于某个DC当时持有的密码版本，导致最近密码更改与登录尝试之间出现竞争条件。密码处理的单主模型为每个DC提供了已知的身份验证失败升级路径，而这条路径之所以有效，是因为有一个DC持有PDC Emulator角色。

五个FSMO角色中有三个直接处于高价值攻击场景的路径上。Schema Master控制攻击者是否可以扩展目录架构以引入持久性机制。RID Master控制SID分配，RID操作是privilege escalation和SID历史攻击的已知向量。PDC Emulator处理身份验证和账户锁定，使其成为任何试图维持域访问或抑制锁定警报的人的主要目标。

Active Directory 定义了五个 FSMO 角色。Schema Master 和 Domain Naming Master 在林级别运行。RID Master、PDC Emulator 和 Infrastructure Master 在域级别运行。

1. 架构主控

当持有 FSMO 角色的域控制器发生故障时，恢复路径取决于您的团队是否知道它持有哪些角色，以及故障是暂时的还是永久的。不跟踪角色分配的组织会在压力下发现问题：无法创建新用户帐户，时间同步漂移，或 Group Policy 更新停止传播。记录角色持有者并测试转移程序是 AD 弹性的操作基础。

每个林中都有一个Schema Master。Active Directory database架构定义了每个对象类（用户、组、计算机、打印机等）及这些对象可以拥有的每个属性。只有Schema Master可以编写架构更改。

2. 域命名主控

每个林中都有一个Domain Naming Master。它是唯一被授权从林中添加或删除域和应用程序分区的域控制器。

架构更新不频繁。它们发生在您提升林功能级别、将 Active Directory 升级到新版本、集成扩展架构的企业软件（Exchange Server 是常见示例）或在林中引入新的 Windows Server 操作系统版本时。Schema Master 必须在线且可访问，才能使这些操作成功。

一旦提交，架构更改会复制到林中的每个域控制器。如果在尝试架构更新时 Schema Master 离线，操作将失败，直到 DC 再次可访问。

3. RID Master

SID 遵循以下结构：

当您的组织目录结构发生变化时，您会与Domain Naming Master交互：添加子域、删除过时域或吸收收购公司的域。由于这些操作不频繁且很少具有时间紧迫性，Domain Naming Master的可用性要求低于域级角色。Domain Naming Master的短暂中断不会影响日常运营。

RID Master通过将RID池分配给域控制器来保持此唯一性。当DC需要创建新的安全主体时，它从分配的池中获取RID，而不是每次都联系RID Master。当池资源不足时，DC会向RID Master请求新的池。

如果 RID Master 离线，域控制器将继续使用其现有的 RID 池创建对象。在拥有大型池的成熟环境中，这种情况可能会持续较长时间。最终，一旦所有 DC 池耗尽，对象创建将失败。

4. PDC 模拟器

每个域都有一个 RID Master。Active Directory 中的每个安全主体（用户、计算机和组）都需要一个唯一的安全标识符（SID）。SID 由域范围的前缀和相对标识符（RID）组成。RID 部分使每个 SID 在域内唯一。

每个域都有一个PDC模拟器。它承担的责任比任何其他FSMO角色都多，对日常域操作有最直接的影响。PDC模拟器负责以下内容：

域 SID 对域中的所有对象都是相同的。最后一段（此示例中的 1001）是分配给特定安全主体的 RID。

• 时间同步： PDC模拟器是其域的权威时间源。所有工作站和成员服务器都将其时钟与之同步。在多域林中，林根域的PDC模拟器充当林中所有其他PDC模拟器的时间管理者。根域的PDC模拟器应与可靠的外部时间源同步。当客户端与其认证DC之间的时钟差超过五分钟时，Kerberos认证将失败；准确的时间是必需的。
• 账户锁定处理： 当发生 account lockout 时，PDC模拟器会立即处理并将锁定状态复制到域中的所有DC。当管理员解锁账户时，PDC模拟器会立即复制该更改。
• 密码更改和身份验证： 当用户更改密码时，变更会立即复制到PDC Emulator。如果用户尝试对尚未通过正常复制接收更新密码的DC进行身份验证，该DC会将身份验证请求转发给PDC Emulator。这确保即使最近的密码更改尚未通过计划复制传播，域也能接受有效凭据。

将PDC仿真器放置在具有良好网络连接的高性能DC上，连接域内所有其他控制器。其故障会对操作产生即时且明显的影响。

• DFS 命名空间同步： 默认情况下，DFS 根服务器会从 PDC Emulator 请求更新的命名空间信息。在大型环境中，这可能导致资源瓶颈。启用 Dfsutil.exe 中的 RootScalability 参数允许 DFS 根服务器改为从最近的 DC 请求更新。

5. 基础结构主控

• Group Policy 更新： 对 Group Policy Object 的更改最初提交给拥有 PDC Emulator 角色的 DC。这可以防止如果两个管理员同时在不同的 DC 上编辑同一个 GPO 时发生版本冲突。

每个域都有一个Infrastructure Master。其主要职责是在多域林中维护准确的跨域对象引用。

如果Infrastructure Master离线，跨域对象名称可能无法正确解析。跨域组成员关系仍然有效，因此操作影响主要是管理方面的。

如何查找FSMO角色持有者

有两种情况使Infrastructure Master变得不必要：单域林（不存在跨域引用）和每个DC同时也是全局目录服务器的环境（在具有足够网络带宽的现代环境中常见）。无论哪种情况，所有DC都已经持有更新的跨域信息，无需依赖Infrastructure Master。

当一个域的用户被添加到另一个域的安全组时，Active Directory 会在该组的域中创建一个占位符对象（称为幻影对象）来表示跨域用户。Infrastructure Master 通过与全局目录同步，保持这些幻影对象的最新状态。它还通过删除对已删除的 trusts 或域 中对象的引用来清理过时对象。

使用 netdom query fsmo

使用 PowerShell

将 <DomainName>Expand 替换为目标域的完全限定域名。输出列出了持有每个角色的 DC 主机名。

该 netdomExpand 命令可在安装了RSAT的任何加入域的Windows机器上运行，或直接在域控制器上运行。它在单个查询中返回所有五个角色持有者：

使用Active Directory管理工具

PowerShell 提供了更细粒度的控制，适用于多个域的环境。以下脚本查询林中的所有域，并返回每个具有 FSMO 角色分配的 DC：

了解哪些域控制器拥有五个FSMO角色，是计划维护和事件响应的前提条件。使用内置的Active Directory management tools，有三种方法可用。

要查找 RID Master、PDC Emulator 和 Infrastructure Master：

1. 打开 Active Directory 用户和计算机。

要进行更简单的按域查询，请直接使用 Get-ADDomainExpand 和 Get-ADForestExpand：

在 Active Directory Users and Computers 中的GUI工具显示三个域级FSMO角色。

1. 在左侧窗格中右键单击域名，然后选择 Operations Masters。
2. 打开 Active Directory Domains and Trusts。

查找 Domain Naming Master：

1. 对话框显示当前的Domain Naming Master。
2. 查看RID、PDC和Infrastructure 标签，每个标签显示当前角色持有者。
3. 在左侧窗格中右键单击 Active Directory Domains and Trusts，然后选择 Operations Master。

查找 Schema Master： Active Directory Schema 管理单元默认不加载。请先注册它：

如何转移 FSMO 角色

1. 打开运行对话框（Win + R），输入 regsvr32 schmmgmt.dll。Expand点击 确定。

3. 在左侧窗格中右键单击 Active Directory Schema，然后选择 Operations Master 以查看当前的 Schema Master。

2. 打开 MMC（mmc.exeExpand），转到 文件 > 添加/删除管理单元，并添加 Active Directory Schema。

传输会将FSMO角色从当前持有者转移到另一个DC，同时两个控制器在线并通信。计划操作时使用传输：退役DC、为负载或冗余重新分配角色，或更换老化硬件。

通过 PowerShell 传输

传输单个角色：

一次性转移所有五个角色：

在开始传输之前，两个 DC 必须在线、可访问且成功复制。请使用 repadmin /replsummaryExpand 验证复制状态。

PowerShell 是传输角色的最高效方法，尤其是在一次移动多个角色时。Move-ADDirectoryServerOperationMasterRoleExpand cmdlet 处理所有五个角色。

通过 GUI 传输：

五个角色名称值是 SchemaMaster、DomainNamingMaster、PDCEmulator、RIDMaster 和 InfrastructureMasterExpand。

如何接管 FSMO 角色

将 TargetDCName Expand 替换为目标 DC 的 NetBIOS 名称或 FQDN。PowerShell 在转移每个角色之前会提示确认。添加 -Confirm:$falseExpand 以在脚本场景中抑制提示。

完成任何转移后，运行 netdom query fsmoExpand 以确认新的角色分配。

使用 ntdsutil 获取角色：

在接管之前，尝试恢复或找回原始 DC。如果无法恢复，则继续接管，并确保在未先降级原始 DC 的情况下，绝不将其重新加入域。

对于 RID Master、PDC Emulator 和 Infrastructure Master：打开 ADUC，导航到 Operations Masters，选择相关标签，然后点击 Change。对于 Domain Naming Master：使用 Active Directory Domains and Trusts > Operations Master > Change。对于 Schema Master：使用 Active Directory Schema 管理单元 > Operations Master > Change。

连接后，逐个获取每个角色：

Seizure 会在未与原持有者协调的情况下，强制将 FSMO 角色分配给新的 DC。仅当当前角色持有者永久离线且无法恢复时才使用 seizure。如果原持有者可能重新连接网络，请勿 seizure 该角色；seizure 后将前角色持有者重新上线会导致分裂脑状态，需要手动修复。

在将接收角色的 DC 上打开提升权限的命令提示符并运行 ntdsutilExpand。然后按照以下步骤操作：

完成所有接管后，输入 quit Expand两次以退出 ntdsutil。

FSMO角色放置最佳实践

使用以下命令确认新的分配：netdom query fsmoExpand 在重新上线依赖这些角色的任何服务之前。

角色分配直接影响AD的稳定性和恢复时间。请查看Active Directory安全最佳实践指南，以获取这些角色特定指南之外的更广泛加固建议：

• 尽可能将角色分布在不同的物理位置： 在多站点环境中，将角色放置在主站点的DC上，可减少角色依赖操作对WAN的依赖。配合有文档的转移计划，以便主站点离线时角色能快速迁移。
• 在较少使用的DC上同时设置Schema Master和Domain Naming Master： 这些森林级角色很少被调用。将它们集中在同一DC上简化了管理，同时不会造成性能瓶颈。

有关设置和配置域控制器以支持这些部署决策的指导，请查阅Netwrix的域控制器部署指南。

Netwrix Auditor 如何帮助您监控和审计 FSMO 角色更改

• 域内最可靠的DC上的PDC模拟器和RID主控： 这两个角色都需要高可用性。PDC模拟器故障会立即影响用户；RID主控故障随着池耗尽会逐渐累积。请将它们放置在域内最可靠、连接最好的DC上。
• 非全局编录服务器上的Infrastructure Master： 在并非所有DC都是全局编录服务器的环境中，Infrastructure Master应运行在不持有全局编录副本的DC上。持有全局编录的Infrastructure Master永远找不到需要更新的幻影对象，因此无法保持跨域引用的最新状态。如果域中的所有DC都是全局编录服务器（现代环境中常见），则此限制不适用。

FSMO角色变更的实时警报

Netwrix Auditor for Active Directory 弥合了本地日志捕获内容与您的安全团队需要采取行动内容之间的差距。

Active Directory 会在目录服务事件日志中以事件 ID 1458 记录 FSMO 转移，记录在接收该角色的域控制器上，并标明前任持有者。该事件确认转移已发生，但未提供调查所需的完整帐户上下文或会话详细信息。

要全面了解目录中需要监控的内容，Active Directory auditing guidelines 涵盖了值得跟踪的事件的全部范围。

未经授权的FSMO角色转移或夺取是已确认的AD攻击向量，其后果超出常规运营中断。攻击者若在域控制器上获得足够权限，可夺取PDC Emulator角色，以拦截身份验证请求、操控时间同步或控制整个域的Group Policy分发。这些更改可能不会在Windows本地事件日志中以足够的上下文显示，难以识别行为者及其意图。

完整的前后审计跟踪

Netwrix Auditor在FSMO角色被转移或夺取的瞬间发出警报。无论更改是通过PowerShell、GUI还是ntdsutil进行，警报都会触发，并包含发起更改的账户、源工作站和时间戳。您的团队可以立即验证计划的转移，并在进一步损害发生前升级未识别的更改。

符合合规要求的报告

区分计划内转移与未经授权的扣押

每次FSMO角色变更都会记录前任角色持有者、新角色持有者、执行操作的账户以及变更的准确时间。Windows原生日志省略了此上下文。当事件需要重建（用于内部调查或外部审计）时，可以获得完整记录，无需依赖多个域控制器的日志聚合。

由于 Netwrix Auditor 捕获了完整的账户和会话上下文，您的团队可以将角色变更与变更管理记录进行交叉核对。在计划的维护窗口期间由指定管理员账户执行的转移，与由无先前管理活动的账户执行的占用不同。审计轨迹使这种区分清晰且有据可依。

请求演示，了解Netwrix如何帮助您审计FSMO角色更改，跟踪每一次Active Directory修改，并生成您的安全团队所需的调查准备证据。

FSMO角色分配是特权访问范围的一部分，SOX、HIPAA和ISO 27001审计会检查。Netwrix Auditor生成关于Active Directory权限变更的预构建报告，满足审计员的请求，无需手动提取日志。角色变更历史被保留且可搜索，因此合规证据可按需提供，而无需在压力下组装。