这是 Active Directory 最后一篇文章,前面的章节我已经基本介绍了域的基本功能和操作,虽然有很多功能我没有演示,但是它的大概用途和使用方法我基本都写出来了,如果有遗漏或写得不好的地方还请自行百度

最后一章就简单的聊一下域服务器在日常使用中可能会遇到的问题

# FSMO 角色

在聊这个之前,首先我们需要先了解活动目录中主域控制器的五个重要的 FSMO (Flexible single master operation) 角色

我们都知道,活动目录是一个中央存储库,它存储了域内的所有对象及其各自的属性,在同一个域中可以部署多台 DC 让它们同时互相复制达到一个高可用的作用

由于各站点之间的 DC 存在一个同步的时间差,假如你在 DC-1 更改了一个对象的属性,然后在 DC-2 又对这个对象作了一些属性变更,当这两台 DC 同步的时候,如果同一个属性发生两次变更,且值不相同,默认情况下是应用最后一次的变更,但是这样仍有可能会导致某些数据冲突异常

微软为了防止这种情况发生,在活动目录中加入了单一主模型的方式对某些对象进行执行更新,在这种模型中加入了五个唯一的 FSMO 角色,每个 FSMO 角色只能授权一台 DC 负责执行特定的对象更新,此时不管域中有多少台 DC,最终只能由活动目录中唯一拥有 FSMO 角色的 DC 进行更新,这样就可以有效的避免数据冲突

这五个 FSMO 角色分别是:Schema Master、Naming Master、PDC、RID Master、Infrastructure Master

其中 Schema Master Naming Master 属于森林级别,PDC、RID Master、Infrastructure Master 属于域级别

这五个主控默认安装在林中的第一台 DC,当创建子域时,Dcpromo.exe 会将三个域范围的角色分配给该域中的第一个 DC,可以在任意一台加了域的 Windows 服务器打开 cmd 命令行,输入 netdom query fsmo 查询这五个角色分别安装在哪些 DC 上

FSMO

下面重点说一下这五个角色分别负责哪些数据的更新,只有了解这些,出了故障你才可以快速地定位问题

# Schema Master

Schema Master 持有者是负责执行活动目录架构命名上下文更新的 DC, 此 DC 是唯一可以处理目录架构更新的 DC,架构更新完成后,它将从架构主机复制到目录中的所有其它 DC

# Active Dircetory 架构

我们可以通过 Active Dircetory 架构这个控制台管理工具查看目录的整个架构属性,想要使用 Active Dircetory 架构管理工具,必须先用命令注册动态连接库文件 schmmgmt.dll,我们打开 cmd 或者 power shell 用命令 regsvr32 schmmgmt.dll 注册

schmmgmt.dll

注册成功后,我们再输入 mmc 打开控制台,点击文件,选择添加 / 删除管理单元,在管理单元窗口选择 Active Dircetory 架构添加确定即可

mmc

# 类和属性

展开 Active Dircetory 架构可以看到它底下有两个子目录,一个是、还有一个是属性

Active Dircetory 架构

下面是类对象,例如用户、计算机、组织单位等,每个类对象包含了数据名称、数据类型、系统、描述和源类

对于,我们可以更改它的类别、是否启用、它的类关系、类属性以及默认安全性这几个方面,但是需要慎重操作,避免更改后导致目录异常

class

属性则包含了属性名称、语法、活动状态和描述

对于属性,我们可以更改它的语法及范围、属性是否启用、编制此属性的索引、模糊名称解析、将此属性复制到全局编录、复制用户时复制属性、在活动目录中为容器化搜索编制此属性的索引

attribute

这里简单说一下语法及范围,这就拿 accountExpres 属性来说,这里语法描述是大整数 / 间隔大整数是指一个 64 位有符号整数值,间隔则是时间间隔值,根据微软官方文档描述,此值表示自 1601 年 1 月 1 日(UTC)起 100 纳秒间隔的数量,值为 0 或 0x7FFFFFFFFFFFFFFFF (9223372036854775807) 表示帐户永不过期,如果你对这些属性值不了解请切勿擅自修改

如果需要了解这些属性,请点击下方链接跳转到微软官方文档查看

https://docs.microsoft.com/en-us/windows/win32/adschema/attributes-all

Note:
如果对目录架构类和属性进行扩展时,需知道架构添加是永久的,你可以禁用类和属性,但是不能从架构中将其删除

# Naming Master

Naming Master 角色持有者是更改分区容器中目录的林范围域名空间的 DC,该 DC 是唯一可以从目录中添加或删除域或应用程序命名上下文的 DC

  1. 它负责跟踪整个森林中的所有域名,确保没有人创建重复的域名,并解决同时创建域名时可能出现的问题

  2. 只有 Naming Master 角色持有者才有权限添加域信任关系

# Active Directory 域和信任关系

我们可以通过 Active Directory 域和信任关系 这个管理工具查看 Naming Master 的功能,在上篇文章中我已经提到过这个工具了,并说了它的主要的功能,在这里我就验证一下 Naming Master 的权限

在我这个环境中,DC-1 Naming Master 角色持有者,我用 DC-1 是有权限对打开 Active Directory 域和信任关系,在域名处右键选择属性,然后点击新建信任,此时弹出新建信任向导窗口,说明 DC-1 是有权限在林中建立信任关系的

DC-1

然后我们在 Active Directory 域和信任关系右键选择更改 Active Directory 域控制器,选择 DC-2 然后再打开新建信任看看

DC-2

从上图中可以看到 DC-2新建信任按键为灰色并且无法点击,所以 DC-2 无法在林中建立信任关系

Note:
创建新域时,Naming Master 主机必须可用,否则将导致创建域失败

# PDC 仿真器

PDC(Primary Domain Controller) 仿真器角色持有者是负责处理 Kerberos 身份验证 和时间服务的 DC

它的功能如下:

  1. 同步域内所有域控制器上的时间,为了保证复制的准确性,所有域控制器都必须有同步的时间

  2. 域用户密码更改优先复制到 PDC 仿真器

  3. 如果用户在一个域控制器上更改了密码,然后试图登录到另一个域控制器,那么第二个域控制器可能仍然拥有旧的密码信息,则第二个域控制器将把身份验证请求转发到 PDC 仿真器,以针对最新密码验证请求。如果 PDC 向 DC 报告了无效的密码,则 DC 将向用户发送错误的密码失败消息

  4. 帐户锁定在 PDC 仿真器上处理

  5. 由于 NetLogon 远程协议也扮演着 PDC 的角色,因此 PDC 仿真器角色持有者必须支持并执行该部分中指定的所有 PDC 特定功能,除 PDC 仿真器角色持有者之外的 DC 均不得执行此功能

如果有域账号经常出现无法登录,请检查该账户登录机器的负责 DC 是否和 PDC 主机无法同步

# RID Master

RID(Relative ID) 角色持有者是负责处理来自给定域中所有 DC 的 RID 池请求的单个 DC,它还负责从对象域中删除对象,并负责在对象移动过程中将其放入另一个域中

我们在域控制器中创建安全主体对象( 例如 user 或 group)时,为确保域中创建的每个安全主体 SID 都是唯一的,会将唯一的 SID 附加到该对象,这个 SID 是由 domain SID 加上 relative ID 组合而成,其中 domain SID 是固定不变的,relative ID RID 角色持有者控制的 RID 池中分配,RID 角色持有者会一次给域中的所有 DC 分配 500 个 relative ID

我们打开 ADSI 编辑器,右键选中 ADSI 编辑器连接到默认命名上下文,依次展开查看之前创建的 Alice Bob 这两个域用户的 SID 值,可以看到它们前面的 domain SID 都是相同的,只有最后面的 4 位 relative ID 是不一样的,而且它们的 relative ID 是连续的,可以说明这两个域账号是在同一台 DC 创建的

SID

我们再查看 OU=Domain Controllers 下的成员 DC-1DC-2,它们的目录下都分别有一个 RID set 成员,双击打开它们的属性对比一下

RID set

由截图可以发现,DC-1 的 RID 有三个比较重要的属性 rlDAllocationPoolrlD、rlDNextRID、rlDPreviousAllocationPool,而 DC-2 的 RID 只有 rlDAllocationPoolrlD,这是因为有的属性只有登录该 DC 才有权限查看,同理我们在 DC-2 里也只能查看 DC-1 rlDAllocationPoolrlD 属性

DC-1 中的 rlDAllocationPoolrlD 代表当前的 RID 分配池,rlDNextRID 代表最后一次分配给安全主体对象的 relative IDrlDPreviouAllocationPool 代表上一次的 RID 分配池,因为 RID 分配池一次只分配 500 个 relative ID,当这 500 个 relative ID 用完 RID 才分配新的 500 个 relative ID

rlDNextRID 这个属性名称应该是代表着下一次分配的 relative ID,但是我经过多次测试发现它这个值是代表最后一次分配给安全主体对象的 relative ID,大家也可以自己测试验证一下

RID 分配池的数量我们可以借助系统自带的 ldp.exe 工具验证一下,按住键盘 Ctrl + R 弹出运行窗口,输入 ldp.exe 确定,在 ldp 界面选中 实用工具 下的大型整数转换器,然后把 DC-1DC-2 中的 rlDAllocationPoolrlD 值转换一下就可以得出结果

ldp

可以看到截图中 DC-1 的 RID 分配池范围是由低位 1100 ~ 高位 1599,域用户 Alice Bobrelative ID 分别是 1108 和 1109,由此可以知道这两个域账户是在 DC-1 这台域控制器创建的,DC-2 的 RID 分配池范围是由低位 1600 ~ 高位 2099,它们可分配的数量都是 500 个

# Infrastructure Master

Infrastructure Master 角色持有者是负责更新跨域对象引用中的对象的 SID 和可分辨名称的 DC

根据微软官方文档中的描述,在未启用 回收站 功能时,Infrastructure Master 不应该部署在 GC 服务器的域控制器,因为 Infrastructure Master 在 GC 服务器上运行,它将不会更新对象信息,这是因为 GC 服务器保留了林中每个对象的部分副本

如果启用 回收站 可选功能后,则每台 DC 都有责任更新其跨域对象的引用,这种情况下就不会和 Infrastructure Master 有任何关联的任务,此时 Infrastructure Master 部署在哪台域控并不重要

由此得知这个主控在域中其实并不太重要,但是它必须存在

# 转移 FSMO 角色

通过上面对 FSMO 角色的描述,我们可以知道如果其中一台持有 FSMO 角色的 DC 无法正常提供服务的话,就会导致活动目录无法正常提供服务

这时我们就需要把出现问题的 FSMO 角色转移到其它的 DC 上让其继续为整个活动目录提供服务

通常会有这两种情况会需要转移 FSMO 角色:一种是 DC 和网络正常情况,还有一种是 DC 或网络故障情况

# 正常转移 FSMO 角色

持有 FSMO 角色的 DC 正常和网络正常,但是配置过低无法满足目前业务需求,需要将 FSMO 角色迁移到其它配置较高的 DC 提供服务,或者是对该服务器硬件升级和系统升级,在升级期间将 FSMO 角色先转移到其它 DC 上继续提供服务,之后再迁移回来

正常情况下迁移 FSMO 角色是非常简单的一件事,我们仅需要通过 GUI 管理工具 操作即可,这里假设我们现在需要把 DC-1 的五个 FSMO 角色迁移到 DC-2,我们需要在 DC-2 这台服务器上操作

我们先登录到 DC-2,直接看操作吧

  1. 架构主机

打开 Active Dircetory 架构,右键选中操作主机,点击更改即可

Schema Master

  1. 域命名主机

打开 Active Dircetory 域和信任关系,右键选中操作主机,点击更改即可

Naming Master

  1. RID、PDC、基础结构

RID、PDC、基础结构这三个域级别的 FSMO 角色是在同一个管理工具界面操作,打开 Active Dircetory 用户和计算机,右键选中操作主机,点击更改即可

Remove domain FSMO

# 故障转移 FSMO 角色

持有 FSMO 角色的 DC 故障或网络故障无法正常提供服务,这时我们就需要强制将 FSMO 角色转移到其它可以正常提供服务的 DC 上

上面我们已经将 DC-1 的 FSMO 角色转移到了 DC-2,现在假设我们的 DC-2 挂掉了,无法为域中用户提供服务,这里我将 DC-2 的网络断开模拟网络故障,然后在 DC-1 上打开 Active Dircetory 用户和计算机,测试看能不能将域中的 FSMO 角色转移过来

在我们打开 Active Dircetory 用户和计算机会发现比之前慢了许多,打开后显示操作主机错误当前操作主机脱机,角色不能被传送,我们点击更改会发现很慢,等待一段时间后弹出操作失败提示

Remove fault

由此可见我们无法通过正常的途径转移 FSMO 角色,此时我们可以使用 PowerShellNtdsutil 来强制转移 FSMO 角色

在这里我只演示如何使用 PowerShell 命令来强制转移 FSMO 角色到 DC-1, 因为 Ntdsutil 是一款比较老的命令行工具,其执行效率远没有 PowerShell 高效,如果对 Ntdsutil 方法感兴趣可以自行百度其使用方法

我们打开 PowerShell, 这里会用到一条 Move-ADDirectoryServerOperationMasterRole 的命令,先输入 man Move-ADDirectoryServerOperationMasterRole 查看该命令的帮助信息

PowerShell

可以从帮助命令看到这条命令的语法非常简洁,它有两个重要的参数,-Identity-OperationMasterRole, -Identity 指定 FSMO 角色所有者, -OperationMasterRole 指定 FSMO 角色

在这里必须先说明, Move-ADDirectoryServerOperationMasterRole 这条命令为我们提供了两种转移操作主机角色选择,这里我们应该选择 Role seizure

  1. Role transfer

Role transfer 是操作主机正常情况下的转移

例如我们需要指定 DC-1 为新的操作主机,并指定 PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster 这五个 FSMO 角色,仅输入下面这条命令执行即可

l
Move-ADDirectoryServerOperationMasterRole -Identity "DC-1" -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster
  1. Role seizure

Role seizure 是操作主机故障情况下的转移,我们只需要在上面那条命令的后面加上 - force 参数表示强制夺取,此操作仍然会先尝试正常传输,然后在无法传输的情况下强制夺取

l
Move-ADDirectoryServerOperationMasterRole -Identity "DC-1" -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster -force

PowerShell

Note:
如果不同的 FSMO 角色分配给不同域控制器,需要分开多次执行该命令,指定对应的 -Identity 主机名 和 -OperationMasterRole 角色,必须登录指定的主机操作
另外,需要用管理员权限打开 Power Shell 执行该命令,否则报错提示没有权限

# 结语

活动目录如果出现问题基本上都是 DC 之间不同步所造成的,可以从系统时间、网络、站点、DNS 服务器以及系统日志这几个地方分析

微软官方也有个叫 Active Directory Replication Status Tool 的小工具可以测试域中 DC 之间的复制状态,使用非常简单,可以通过下面的地址下载该软件查看该软件描述

https://www.microsoft.com/en-us/download/details.aspx?id=30005

活动目录是 Windows Server 的核心,需要学习的知识还有许多,官方文档就是非常不错的学习资料

关于自己对活动目录所理解的知识基本都已经全部汇总写出来了,可能文中有许多地方写得不好或者错误的地方,还请大神留言指正,我会及时更改

✿✿ヽ (°▽°) ノ✿✿