当前位置：首页 > news >正文

Microsoft Entra Hybrid Identity 实施指南Connect Sync 与 Cloud Sync 从部署、同步到 Day-2 Monitoring

news 2026/8/7 22:15:45

引言

真实案例

某金融企业在部署 Entra Connect Sync 时，技术团队选择了 Express Setup。Express Setup 默认采用较宽泛的预定义同步范围——而该企业的 AD 中混杂着 300 多个服务账户（SQL Server、IIS AppPool、SAP）和 200 多个测试账号。
同步启动后第二天，安全团队紧急叫停：300 多个服务账户被同步到云端，每个月消耗 300 多个 M365 许可证，一年多花 180 万；更糟的是，这些服务账户默认启用了 SSPR 和 MFA——它们根本不是真人，没法接 MFA token，全部登录失败。

这不是个案。Express Setup 本身不是错误，但企业环境如果目录治理不足，默认同步范围会将非用户对象一并上云。

本文目标

身份同步的实施不是装好 Connect 就完事。它是架构决策 → 安装配置 → 监控运维三段链路的连贯工程。

本文系统化拆解：

Connect Sync 实施：从服务器准备到 Express vs Custom 决策
Cloud Sync 实施：从 gMSA 到 Agent 高可用部署
Entra Connect Health 监控：让同步可见、可控、可查
同步实施后的验证：检查清单 + 烟雾测试

一、实施前必备的全局认知

1.1 同步工具的"工程本质"

工具	本质	类比
Entra Connect Sync	本地部署的企业级同步引擎 + SQL Server + Sync Service	自建水电站
Entra Cloud Sync	云端运行的同步引擎 + 本地轻量 Agent	集中供水（你只装水表）

架构心法：Connect Sync 是"功能完整但运维复杂"的工具——支持 Exchange Hybrid、PTA、AD FS、LDAP 过滤等所有高级特性，代价是组织必须维护一个"小型基础设施"（Sync Server + SQL + 备份策略）。
Cloud Sync 是"功能精简但运维轻量"的工具——微软负责 80% 的运维，组织只需维护 Agent 主机。

1.2 实施前的"四个确认"

确认项	说明
✅ Source of Authority 已确立	本地 AD 是真值来源（云端不可改同步用户）
✅ UPN 后缀与租户主域一致	IdFix 已跑通
✅ OU 同步范围已设计	按"白名单"原则而非"黑名单"
✅ 认证方式已决策	PHS / PTA / Federation 已选择

1.3 Hybrid Identity 同步架构图

架构解读：

组件	部署位置	职责
Microsoft Entra ID	云端	云端身份中心；统一身份目录
Connect Sync	本地服务器	企业级同步引擎；包含 Sync Engine + SQL Server + Metaverse + AD Connector
Connect Sync Staging Server	本地服务器	温备节点（DR），不执行 Export
Cloud Sync Provisioning Service	云端	由微软管理；执行同步决策、同步逻辑、对象匹配
Cloud Sync Provisioning Agent	本地服务器	与 Microsoft Entra Provisioning Service 建立安全通信通道，提供本地 AD 数据访问能力
AD Forest	本地	源目录；用户、组、Contact、objectGUID、ms-DS-ConsistencyGuid

1.4 Hybrid Identity 架构决策矩阵

需求	推荐	原因
Exchange Hybrid 本地 + 云端邮箱共存	✅ Connect Sync	Cloud Sync 不提供 Exchange Hybrid 所需的完整目录同步能力
Exchange Online Only（仅云端邮箱）	✅ Cloud Sync 支持	如果只是 Exchange Online 云邮箱，不需要 Hybrid 属性流转，Cloud Sync 可以同步需要的用户对象
PTA / Pass-Through Authentication	✅ Connect Sync	Cloud Sync 不支持 PTA
AD FS 联邦认证	✅ Connect Sync	Cloud Sync 不支持 Federation
LDAP 复杂过滤 / 复杂多林 Join	✅ Connect Sync	Cloud Sync 不提供 Metaverse / Join Rules
组写回 / 设备写回	✅ Connect Sync	Cloud Sync 能力有限
单林 + 纯 PHS + 简化运维	✅ Cloud Sync	微软负责 80% 运维
减少本地服务器维护	✅ Cloud Sync	只需 1 个轻量 Agent
多子公司 AD / 多站点	✅ Cloud Sync	Cloud Sync 原生支持多 Agent 高可用模型
新建云原生企业	✅ HR Provisioning + Lifecycle Workflow	跳过 AD，迈向云原生
并购过渡期	✅ Connect + Cloud Sync 共存	微软官方支持的迁移路径

架构决策树：

架构原则：

✅ 新部署企业：从 Cloud Sync 起步（除非需要 Connect Sync 独占能力）
✅ 传统企业：保留 Connect Sync 作为过渡，逐步迁移 Cloud Sync
✅ 并购场景：使用 Connect + Cloud Sync 共存路径
✅ 云原生企业：跳过 AD，直接走 HR Provisioning + Lifecycle Workflow

二、Entra Connect Sync 实施全流程

2.1 服务器前置条件

前提项	要求	备注
操作系统	Windows Server 2016+	Full GUI 必须，Server Core 不支持
Windows 版本	Standard Edition 或更佳	不支持 Windows Server Essentials
.NET Framework	4.6.2+	新版本也支持
PowerShell	5.0+	默认满足
磁盘空间	至少 10 GB 可用	同步数据库需要空间
域加入	必须加入要同步的 AD 域
时间同步	与域控制器时间偏差 < 5 分钟	否则 Kerberos 认证失败
TLS	启用 TLS 1.2	现代默认满足

2.2 AD FS 场景的额外前提

如果同时部署 AD FS（Federation），需要满足：

前提项	要求
AD FS / WAP 服务器	Windows Server 2012 R2+
WinRM	必须在 AD FS / WAP 服务器上启用（远程安装需要）
TLS/SSL 证书	已正确配置，名称解析（DNS）就绪
服务账户	域账户具备必要的本地管理员权限

2.3 网络与流量要求

很多团队忽略的细节——Entra Connect Sync 会持续与 Entra ID 通信。

流量类型	用途	频率
Delta Sync	检测 AD 变更并推送到云	约 30 分钟（默认约 30 分钟，不保证严格按 30 分钟）
Full Sync	手动触发或特定场景触发	初始配置 / Schema 变化 / Connector 变化 / 手动 Initial Sync——不是固定周期
Password Hash Sync	同步密码哈希	每 2 分钟（独立周期）
Microsoft Entra ID 连接	outbound HTTPS 到`login.microsoftonline.com`	持续
本地 AD 通信	LDAP 查询、目录变更通知	持续

关键警告：Microsoft 明确不支持在 Connect Sync 与 Entra ID 之间做"流量抓包分析"——因为这会中断同步服务的内部认证握手，导致同步失败。如果需要排查连接问题，使用Test-NetConnection或官方诊断工具。

2.4 Express vs Custom Setup 决策

维度	Express Setup	Custom Setup
适用场景	单林、纯 PHS、希望快速就绪	多林、自定义认证、自定义过滤
认证方式	默认 PHS	PHS / PTA / Federation 任选
SQL Server	使用内置 SQL Server Express	可指定现有 SQL Server
服务账户	自动创建所需服务身份和本地权限配置（使用 Virtual Service Account / gMSA / Managed Service Account）	可指定现有服务账户
同步范围	默认使用微软预定义同步范围，通常范围较宽	可自定义 OU 包含/排除
同步组	自动创建本地组	可指定现有组
安装路径	默认路径	可指定自定义路径
后续扩展性	受限（Express 锁定部分配置）	完全可配置

2.5 Express Setup 的真相

架构师描述：Express Setup 是针对标准化、小规模环境设计的快速部署模式。但由于企业 AD 通常包含大量非用户对象（服务账户、计算机账户、历史遗留对象、测试账号、禁用账号等），因此生产环境需要在部署前验证默认同步范围。
Express Setup 本身不是错误——风险来自企业目录治理不足。架构师应从"企业目录治理"角度评估，而非将 Express 视为"危险"。

Express Setup 在后台会：

✅ 自动启用 PHS（Password Hash Sync）（默认）
⚠️ 可能启用 Seamless SSO（无缝 SSO）（默认配置）
❌ 不会自动启用 Device Writeback / Group Writeback——这些高级能力需要根据业务场景单独配置
⚠️ 自动配置微软预定义同步范围——通常范围较宽，不适合作为复杂企业环境的生产默认方案
⚠️ 自动创建本地服务身份与权限配置（使用 Virtual Service Account / gMSA / Managed Service Account）
⚠️ 自动创建本地同步组（ADSyncAdmins 等）

Express Setup 的问题清单：

问题	影响
⚠️ 使用预定义同步范围	测试账号、服务账户、过期账号全部上云
❌ 无法选择 OU	必须事后用"过滤"机制排除，但 Express 不支持完整过滤
❌ SQL 不可指定	性能受限（SQL Express）
❌ 服务账户不可控	后续迁移困难
❌ 升级到 Custom Setup 困难	一旦 Express 完成，重做必须卸载重装

2.6 推荐决策路径

架构经验：绝大多数企业生产环境应选择 Custom Setup。Express Setup 仅适用于"实验室测试"或标准化小规模环境。

2.7 Custom Setup 安装步骤

三、Microsoft Entra Cloud Sync 实施全流程

3.1 Cloud Sync 的核心组件

组件	部署位置	职责
Microsoft Entra Provisioning Service	Microsoft 云端	执行同步编排、对象匹配、属性映射、Provisioning 工作流——这是 Cloud Sync 架构中唯一负责任务逻辑的组件
Provisioning Agent	本地 Windows Server	提供访问 AD DS 的安全连接通道，将目录读取能力暴露给云端 Provisioning Service
gMSA / Virtual Service Account	本地	Agent 服务运行身份（支持 gMSA 与 Virtual Service Account 两种身份模式）
ECMA Connector Host	本地（可选）	扩展到非 AD 数据源

架构心法：Cloud Sync 的核心理念是 "Move synchronization intelligence from on-premises to cloud"（将同步智能从本地迁移到云端）。

Connect Sync vs Cloud Sync 架构对比：

维度	Connect Sync	Cloud Sync
同步引擎	本地 Sync Engine	云端 Microsoft Entra Provisioning Service
匹配决策	Metaverse + Source Anchor（本地）	云端 Matching Rules
Agent 职责	本地同步 + Export	仅提供安全通道 + 数据传递
数据控制	本地 Connector Space + DB	云端 Provisioning 工作流
核心架构描述	企业级同步引擎	云端同步智能 + 本地安全通道

Cloud Sync 架构模型：

避免误解：Cloud Sync 的 Agent 没有本地同步引擎，不负责变更检测和决策。这些都是云端 Provisioning Service 的职责。

3.2 Cloud Sync 部署前提

前提项	要求	备注
gMSA	已创建	提供自动密码管理
混合身份管理员账户	Entra 中的特权账户（不能是 guest user）	用于 Agent 注册
Agent 服务器	Windows Server 2016+	建议 Tier 0 服务器；可装在 DC 上
.NET Framework	4.7.2+
PowerShell	5.0+
防火墙 outbound	允许 HTTPS 到 Entra 服务
域账户权限	Domain Admin / Enterprise Admin	仅创建 gMSA 时需要

3.3 gMSA 详解

关键认知：gMSA 是生产环境推荐的 Agent 服务身份模型，而非功能性强制要求。Microsoft Entra Cloud Sync Provisioning Agent 支持 gMSA 与 Virtual Service Account 两种身份模式。

为什么推荐 gMSA？ Cloud Sync Agent 是一个长期运行的 Windows 服务，需要稳定的、可管理的服务账户。

问题	使用普通域账户	使用 gMSA
密码管理	❌ 密码会过期 → 服务崩溃	✅ Windows 自动轮换
生命周期	❌ 需手动管理	✅ 与 AD 账户生命周期联动
多服务器	❌ 管理噩梦	✅ 多服务器共享同一身份

SPN 提醒：gMSA 本身并不自动为所有应用管理 SPN。SPN 是否自动注册取决于服务的具体实现。

创建 gMSA 的 PowerShell：

powershell

3.4 Cloud Sync 高可用设计

核心原则：多个 Agent 同时活动（Active-Active），不是一主多备。

设计	说明
1 个 Agent	❌ 不可接受——单点故障
2 个 Agent	⚠️ 最低标准——可承受 1 个 Agent 故障
3 个 Agent	✅ 企业实践推荐——适用于大型、多站点环境

Agent 负载均衡机制：

Entra 预配服务会在多个 Agent 之间轮询分配变更检测任务
如果某个 Agent 离线，请求自动转移至其他 Agent
用户无感知——同步持续运行

3.5 Cloud Sync 安装步骤

3.6 Cloud Sync Identity Matching 与 Source Anchor 策略

关键警告：Cloud Sync 的对象匹配逻辑与 Connect Sync 的 Source Anchor 概念在表达层和实现层都存在差异。Cloud Sync 不提供 Entra Connect Sync 同等粒度的 Source Anchor 显式配置能力。Cloud Sync 的匹配行为由服务管理，不保证与 Entra Connect Sync 完全一致。

Source Anchor / 对象匹配标识的本质：确保本地 AD 对象生命周期变化过程中，Entra ID 能持续识别为同一个身份对象。企业迁移、林合并、对象恢复场景必须提前规划该策略。

Connect Sync vs Cloud Sync 架构模型差异：

维度	Entra Connect Sync	Microsoft Entra Cloud Sync
架构模型	AD Object → Connector Space → Metaverse → Source Anchor → Entra Object	AD Object → Cloud Provisioning Agent → Entra Provisioning Service → Matching Rules → Entra Object
Source Anchor 性质	本地 Metaverse 中的明确属性，架构师可配置	云端 Matching Rules 管理的匹配属性（不提供 Connect Sync 同等级别的配置模型）
默认行为	已围绕 ms-DS-ConsistencyGuid 优化	由 Microsoft Entra Provisioning Service 管理，优先使用 ms-DS-ConsistencyGuid，Fallback objectGUID
林合并迁移	可手工修改 Source Anchor 策略	需重新配置 Matching Rules

优先级	属性	说明
1️⃣	`ms-DS-ConsistencyGuid`	AD 中的可写属性；Microsoft 推荐用于迁移、林合并、Exchange Hybrid 共存场景
2️⃣	`objectGUID`	AD 中每个对象的 GUID；Fallback 选项

不要误解：不要理解成 "Cloud Sync 也有 Source Anchor，只是不让改"。两个模型思想不同：

Connect Sync：Source Anchor 是本地 Metaverse 中的明确配置项，架构师可控制
Cloud Sync：Matching Rules 是云端 Provisioning Service 的内置匹配能力，架构师不直接控制

Exchange Hybrid 场景说明：

Cloud Sync 可以同步 Exchange Online 中需要的用户对象，但不提供 Exchange Hybrid 所需的完整目录同步能力。如果企业存在以下场景，应使用 Entra Connect Sync：

Exchange Server 与 Exchange Online 共存
Hybrid Modern Authentication（HMA）
Hybrid Free/Busy
Mailbox Migration（邮箱迁移）
Exchange Hybrid Configuration Wizard 要求的完整属性流转模型
mail-enabled object（MailUser / MailContact / Linked Mailbox）属性流转
Exchange writeback 场景

3.7 Cloud Sync 同步拓扑支持

拓扑	支持	实施要点
单林 + 单租户	✅	最简单；1 个 Agent 起步，扩展至 3 个 HA
多林 + 单租户	✅	每林独立 Agent；确保跨林唯一；Cloud Sync 多林能力更偏向轻量 Provisioning 模型
混合：Connect Sync + 新林 Cloud Sync	✅	迁移路径；新旧 Agent 并存
现有混合 AD 林中试点 Cloud Sync	✅	可与 Connect Sync 共存测试

3.8 Cloud Sync 的关键约束

约束	说明	影响
⚠️ 不适合作为 Exchange Hybrid 主同步方案	Cloud Sync 不提供 Exchange Hybrid 所需的完整目录同步能力	邮件混合场景必选 Connect
❌ 不支持 PTA	仅支持 PHS	需要 PTA 必须用 Connect
❌ 不支持 AD FS 联邦	仅支持 PHS	需要 Federation 必须用 Connect
⚠️ 不支持跨林匹配	每个用户必须在林中唯一	多林场景需手动去重
⚠️ 组写回 Preview	2025-2026 仍处于预览	生产谨慎启用
⚠️ 匹配关系不宜频繁变化	服务管理匹配决策	决策前充分验证

四、Express vs Custom Setup 完整对比

4.1 决策矩阵

维度	Express Setup	Custom Setup
同步范围	使用微软预定义同步范围，通常较宽泛	自定义 OU（白名单）
认证方式	仅 PHS	PHS / PTA / Federation 任选
SQL Server	内置 SQL Express	现有 SQL Server（生产级）
服务账户	自动创建所需服务身份和本地权限配置	指定现有域账户
安装路径	默认	自定义
同步组	自动创建本地组	指定现有组
学习曲线	平缓	中等
生产就绪度	适合 ≤ 1000 用户 + 单林	适合任何规模
可扩展性	受限	完全可配置
Express → Custom 升级	❌ 必须卸载重装	—

4.2 推荐决策树

五、监控体系：Microsoft Entra Connect Health

部署完同步工具不是结束——监控运维才是真正的开始。

5.1 Entra Connect Health 三大能力

能力	监控对象	价值
AD DS Health	本地 AD 域控制器	发现复制问题、DFS 错误、性能瓶颈
AD FS Health	AD FS + WAP 服务器	监控联邦认证失败、令牌请求异常
Sync Health	Entra Connect Sync 同步服务	监控同步延迟、错误、导出失败

5.2 监控维度

监控类别	具体指标
同步状态	最后同步时间、增量同步间隔、错误数
性能数据	CPU、内存、SQL 连接、LDAP 查询延迟
告警通知	同步失败、密码哈希同步失败、AD DS 复制异常
使用分析	登录次数、令牌请求、错误分布
配置基线	与最佳实践的偏离（如未启用 PHS）

5.3 部署方式

Connect Sync 场景：

Connect Sync 安装向导自动安装 Entra Connect Health Agent
同步服务器、AD FS、AD DS 都会被注册到 Health 监控
在 Entra admin center → Entra Connect Health 查看

Cloud Sync 场景：

Cloud Sync 自动将同步状态报告到 Entra
在 Entra admin center → Cloud Sync 配置页面查看
无需额外安装 Agent

5.4 关键告警场景

告警	含义	行动
"Data sync has not completed in 60 minutes"	同步服务卡住	检查 Connect Server、SQL Server
"Password hash sync is not working"	PHS 失败	检查 Entra ID 连接、AD 凭据
"AD FS service is down"	联邦服务宕机	检查 AD FS 服务、WAP
"Duplicate attribute detected"	AD 端有重复属性	IdFix 扫描 + 修复
"AD DS replication latency > X hours"	AD 复制问题	检查站点链接、复制拓扑

5.5 监控的最佳实践

监控最佳实践	说明
✅ 启用所有三个 Agent	AD DS / AD FS / Sync
✅ 配置邮件告警	关键错误直接发邮件到运维邮箱
✅ 集成到 SIEM	Log Analytics / Sentinel
✅ 建立 Dashboard	关键指标可视化
✅ 每月做 Health Review	主动看趋势，而不是被动等告警

架构心法：Entra Connect Health 应该是"无人值守"运维的基础。没有它，同步就是黑盒。

5.6 同步服务灾难恢复设计

很多企业部署完 Connect Sync 就以为万事大吉，没有为同步服务的"推倒重来"做准备。这是生产环境最常被忽视、影响最严重的环节之一。

灾难场景列举：

场景	影响	恢复方式
Connect Sync 服务器硬盘故障	同步中断	Staging Server 接管
Connect Sync 配置误删除	同步逻辑丢失	配置重导入 + 加密密钥重放
Connect Sync SQL Server 数据库损坏	所有同步元数据丢失	数据库恢复 + 加密密钥恢复
加密密钥丢失	灾难级——AD DS 账户密码哈希同步无法解密	必须有备份
AD Forest 推倒重建 / 林合并	Source Anchor 完全失效	重新规划 Source Anchor 策略
Cloud Sync Agent 服务器全部脱机	同步中断	新服务器部署 Agent

Connect Sync 灾难恢复三大要件：

1. Staging Server（温备节点）

独立同步数据库（LocalDB 或 SQL Server）
同步引擎安装完整，与生产环境配置一致
通过Export-Configuration/Import-ConfigurationPowerShell 命令维护配置一致性

2. SQL Server 数据库备份

关键备份：ADSync 数据库

ADSync 数据库包含以下内容：

Connector Space（连接器空间）
Metaverse 数据（中间存储）
Synchronization Rules 配置引用
Connector 配置

重要区分：ADSync 数据库与 Encryption Key 是两个独立资产，不能等同于"数据库包含 Encryption Key"。

资产	说明
ADSync 数据库	Connector Space + Metaverse + Sync Rules 引用 + Connector 配置
Encryption Key	独立资产，用于加密 AD DS 账户密码哈希，通过 DPAPI 保护

备份要求：

备份频率：每日全备 + 每小时增量
备份保留：至少 30 天
备份存储：独立于 Sync Server 的位置（异地备份）

3. 加密密钥 / 配置保护

v2.10 明确：实际 Entra Connect Encryption Key 是通过 DPAPI 保护的，不是简单 Registry 明文读取。企业文档应推荐 Microsoft 官方 Export 流程。

Microsoft 官方恢复机制：

方式	说明
Azure AD Connect Configuration Export	PowerShell 或安装向导导出
Synchronization Service Manager	Export Configuration
Azure AD Connect Wizard 导出	ADSyncConfig.ps1 文件
定期备份 ADSync 数据库	包含 Connector Space + Metaverse + Sync Rules + Connector 配置
备份同步服务 Encryption Key	与 ADSync 数据库独立，使用 Microsoft 官方 Export 流程
密码保险柜存储	CyberArk / HashiCorp Vault / Azure Key Vault

应避免的做法：

做法	风险
❌ 直接读取注册表提取 EncryptionKey	不保证所有版本存在；不代表完整密钥恢复机制
❌ 依赖单一备份源	单一导出位置可能丢失
❌ 将备份存储在 Sync Server 本地	灾难时一起丢失

定期验证恢复流程：

✅ 每季度在隔离环境演练一次恢复
✅ 验证加密密钥可被正确读取
✅ 验证 ADSyncConfig.ps1 可被使用
✅ 验证 Staging Server 接管后可正常同步

关键警告：如果加密密钥丢失并且没有配置备份，所有同步的 Password Hash Sync 功能将无法解密 AD DS 账户密码哈希，所有云端用户的密码同步将永久失效。

Connect Sync vs Cloud Sync 灾难恢复对比：

能力	Connect Sync	Cloud Sync
本地服务器故障	需要 Staging Server 接管	只需重新部署 Agent（云端服务不受影响）
数据库备份	必须	不需要（云端管理）
加密密钥备份	必须	不需要（云端管理）
配置备份	Export / Import Configuration	通过 Entra Portal 重新创建
恢复 RTO	数小时	分钟级
恢复 RPO	取决于备份频率	云端状态同步保留

架构心法：Cloud Sync 在 DR 上优于 Connect Sync，但这不是说 Cloud Sync 能完全替代 Connect Sync，而是能够使用 Cloud Sync 的场景下，其 DR 模型显著更轻。

5.7 生产部署推荐架构

生产部署架构要素解读：

层	能力 / 组件	职责
L1 云端身份中心	Microsoft Entra ID	云端身份真值目录；统一用户、组、Device
L1 零信任访问控制	Conditional Access	MFA + 合规设备 + 受信位置
L1 风险检测	Identity Protection	风险检测、自动响应、风险用户查询
L2 身份治理	Identity Governance	Lifecycle Workflow / Entitlement Management / PIM
L3 同步架构	Connect Sync（生产 + Staging）+ Cloud Sync（Agent x2）	云-地同步、DR保障、多 Agent HA
L3 Tier 0 资产	Sync Server、Cloud Sync Agent Server	企业身份同步关键资产（需防护）
L4 应用访问	M365 / SaaS / Application	应用访问、SaaS 应用、SCIM Provisioning
L4 AD 林	Tier 0 Forest（AD Forest）	源目录；用户、组、Contact

架构原则：

✅ L1 + L2 云原生能力在上、L3 同步层在下、L4 应用访问与 AD 源头隔离
✅ 同步架构支持 Connect Sync（生产 + Staging）与 Cloud Sync（Agent HA）并存
✅ Tier 0 资产保护：Sync Server / Agent Server / AD Domain Controller / ADFS 均属 Tier 0
✅ 断开路径：Conditional Access + Risk-Based 访问控制 + PIM 限定 L2 / L3 访问

架构本质：这不是"部署指南"，而是"企业 Hybrid Identity 落地蓝图"。架构师交付的不是一份安装文档，而是可运行多年的、可扩展、可 DR、可治理的企业身份架构。

六、安装后的验证

6.1 同步成功 Checklist

✅	检查项	验证方法
☐	用户已在 Entra 中创建	Entra admin center → Users → 找到测试用户
☐	用户可以登录 M365	portal.office.com 用同步用户登录
☐	密码哈希已同步	Entra Connect Health → "Password hash sync" 显示成功
☐	OU 范围正确	仅同步了预期的 OU，没有多余对象
☐	用户属性正确	检查 department、title、manager 等
☐	组已同步	Entra 中的组包含正确成员
☐	增量同步工作	在 AD 中改一个属性，30 分钟内云端同步
☐	密码写回工作（如果启用）	云端改密码，AD 中验证（可选）
☐	设备写回工作（如果启用）	Entra 中注册的设备回写到 AD（可选）

6.2 烟雾测试

Test 1: 创建用户 → 验证同步

在 AD 同步范围内的 OU 中创建一个测试用户
等待 30 分钟（增量同步周期）
在 Entra admin center 中找到该用户
验证属性（姓名、邮箱、UPN）

Test 2: 修改属性 → 验证同步

修改测试用户的 department 属性
强制增量同步：Start-ADSyncSyncCycle -PolicyType Delta
验证云端 department 已更新

Test 3: 密码哈希同步

重置测试用户密码
等待 2 分钟
用新密码登录 portal.office.com

Test 4: 禁用/启用用户

在 AD 中禁用测试用户
验证云端用户也被禁用
重新启用，验证云端恢复

Test 5: OU 排除

创建 OU=TestExclusion 中的用户
验证云端无该用户

6.3 强制同步命令

Connect Sync：

powershell

Cloud Sync：

Cloud Sync 没有 PowerShell 强制同步命令——同步由云端调度。要立即测试：

Entra admin center → Cloud Sync → 配置 → "Provision on demand"
或修改 AD 中测试用户属性，等待云端轮询

七、迁移策略：从 Connect Sync 到 Cloud Sync

很多组织从 Connect Sync 迁移到 Cloud Sync。这是一条支持的迁移路径。

7.1 迁移适用场景

场景	建议
组织不想维护 Connect Sync Server	✅ 迁移到 Cloud Sync
多林场景，需要每林独立管理	✅ 迁移到 Cloud Sync
现有 Connect Sync 工作良好	⚠️ 不必迁移，Connect Sync 仍受支持
需要 Exchange Hybrid	❌ 不能迁移——Exchange Hybrid 必须用 Connect Sync
需要 PTA / Federation	❌ 不能迁移——Cloud Sync 不支持

7.2 迁移步骤

关键警告：不要同时启用 Connect Sync 和 Cloud Sync 同步同一 OU——这会导致对象冲突、Source Anchor 冲突、不可预测的同步行为。迁移必须按 OU 逐步切换。

八、实施常见误区与最佳实践

8.1 十大误区

误区	真相
❌ "Express Setup 最快最好"	⚠️ Express 默认全林同步，是大量误同步事故的根源
❌ "装好就完事了"	✅ 同步是持续运维，需要监控、告警、定期审计
❌ "Cloud Sync 是 Connect 的升级版"	❌ Cloud Sync 是轻量化同步模型，而不是 Connect Sync 的完全替代版本
❌ "PTA 比 PHS 安全"	⚠️ PHS 也安全（传的是不可逆哈希）；PTA 优势是"密码哈希不出云"
❌ "Connect Sync Server 可以装在 DC 上"	❌ 不推荐（虽然支持）；DC 上装会引入运维风险
❌ "同步服务账户权限越大越好"	⚠️ 最小权限原则——仅给"读取要同步的 OU"
❌ "同步后可以改 UPN"	⚠️ UPN 一旦作为 Source Anchor 关联，改了会断链
❌ "Cloud Sync 的 Source Anchor 可以手动选"	❌ 由服务管理；匹配关系不宜频繁变化
❌ "Connect Sync 和 Cloud Sync 可以同时同步同一 OU"	❌ 对象冲突，不可预测行为
❌ "启用同步后所有云端能力都自动可用"	⚠️ 还需要配 MFA、Conditional Access、SSPR 等

8.2 十大最佳实践

实践	说明
✅ 优先 Custom Setup	即使单林，30 分钟投入换长期省心
✅ 按 OU 白名单设计	"按需包含"而非"默认全同步"
✅ 预创建 gMSA	生产环境推荐 gMSA（非强制要求）
✅ 3 个 Agent HA	Cloud Sync 推荐活动-活动部署
✅ 启用 Entra Connect Health	同步可见、可控、可查
✅ 建立监控告警	关键错误发邮件 + SIEM
✅ 每月 Health Review	主动看趋势
✅ 建立运维 Runbook	常见故障的排查 SOP
✅ 分离同步账户与管理员账户	最小权限原则
✅ 规划期做 Load Test	模拟 1 万用户同步，验证性能

九、总结

身份同步的实施是架构决策 → 工程实施 → 持续监控的三段链路。

阶段	关键决策	关键产出
架构决策	PHS / PTA / Federation / Connect / Cloud	选型文档
工程实施	Express / Custom / Agent 部署 / OU 设计	同步服务上线
持续监控	Connect Health / 告警 / Health Review	长期稳定运行

最关键的三个决策：