规划、设计和实现 Microsoft Entra Connect
Microsoft Entra Connect 是一项解决方案,用于桥接组织本地 Active Directory 与基于云的 Microsoft Entra ID。 IT 部门可以将标识从本地同步到 Azure,并确保两个平台之间的标识一致。 这种连接可以实现密码哈希同步、直通身份验证和无缝单一登录 (SSO) 等服务。
Microsoft Entra Connect 专用于满足和完成混合标识目标的 Microsoft 工具。 它提供以下功能:
- 同步 - 负责创建用户、组和其他对象。 然后,它还负责确保本地用户和组的标识信息与云匹配。 此同步还包括密码哈希。
- 密码哈希同步 - 一种用于将用户的本地 AD 密码哈希与 Microsoft Entra ID 同步的登录方法。
- 直通身份验证 - 一种登录方法,允许用户在本地和云中使用相同密码,但不需要联合环境的额外基础结构。
- 联合身份验证集成 - 联合身份验证是 Microsoft Entra Connect 的可选部件,可用于使用本地 AD FS 基础结构配置混合环境。 它还提供了 AD FS 管理功能,例如证书续签和更多 AD FS 服务器部署。
- 运行状况监视 - Microsoft Entra Connect Health 可提供可靠的监视。
为何使用 Microsoft Entra Connect?
将本地目录与 Microsoft Entra ID 集成可提供通用标识用于访问云和本地资源,从而提高用户的生产率。 借助 Microsoft Entra Connect,用户可以使用单个标识来访问本地应用程序和云服务(例如 Microsoft 365)。 此外,组织可以提供轻松的部署体验,使用单个工具即可同步和登录。 Microsoft Entra Connect 替换了旧版标识集成工具;并且包含在 Microsoft Entra ID 订阅中。
选择身份验证方法
标识是 IT 安全的新控制平面,因此身份验证是组织对新云世界的访问防护。 组织需要一个标识控制平面,以便增强其安全性并使其云应用免受入侵者攻击。 当 Microsoft Entra 混合标识解决方案成为你的新控制平面时,身份验证会是云访问的基础。 选择正确的身份验证方法是设置 Microsoft Entra 混合标识解决方案至关重要的第一个决定。 若要选择身份验证方法,需要考虑时间、现有基础结构、复杂性和实现所选内容的成本。 这些因素对每个组织都不同,并可能随时间变化。
云身份验证
选择此身份验证方法时,Microsoft Entra ID 会处理用户的登录过程。 当你结合使用无缝单一登录 (SSO) 时,用户无需重新输入其凭据即可登录到云应用。 如果使用的是云身份验证,可以从以下两个选项中选择:
Microsoft Entra 密码哈希同步 (PHS)。 这是在 Microsoft Entra 中为本地 Directory 对象启用身份验证的最简单方法。 用户可以使用其在本地使用的同一用户名和密码,不必部署任何其他基础结构。
- 工作量。 密码哈希同步所需的有关部署、维护和基础结构的工作量最少。 此级别的工作量通常适用于只需用户登录到 Microsoft 365、SaaS 应用以及其他基于 Microsoft Entra ID 的资源的组织。 启用后,密码哈希同步即是 Microsoft Entra Connect 同步过程的一部分,并且每两分钟运行一次。
- 用户体验。 若要改善用户的登录体验,请将无缝 SSO 随密码哈希同步一起部署。 在用户登录时,无缝 SSO 将消除不必要的提示。
- 高级方案。 如果组织选择启用,则可以通过 Microsoft Entra ID Premium P2 的 Microsoft Entra 标识保护报告使用来自标识的见解。 例如已泄漏凭据报告。 Windows Hello for Business 在使用密码哈希同步时有特定要求。 Microsoft Entra 域服务需要密码哈希同步才能在托管域中使用公司凭据创建用户。
- 业务连续性。 密码哈希同步与云身份验证结合在一起完全可以作为云服务使用,适合所有 Microsoft 数据中心。 若要确保密码哈希同步不会在长时间内无法工作,请在备用配置中部署另一个处于暂存模式的 Microsoft Entra Connect 服务器。
- 注意事项。 目前,密码哈希同步不会即时强制本地帐户状态更改生效。 在此情况下,除非用户帐户状态已同步到 Microsoft Entra ID,否则用户有权访问云应用。 组织可能希望在管理员对本地用户帐户状态执行批量更新后运行新的同步循环来克服此限制。 例如禁用帐户。
Microsoft Entra 直通身份验证 (PTA)。 通过使用在一个或多个本地服务器上运行的软件代理,为 Microsoft Entra 身份验证服务提供简单密码验证。 服务器直接使用本地 Active Directory 验证用户,这将确保云中不发生密码验证。 具有即时强制本地用户帐户状态、密码策略和登录小时数生效的安全要求的公司可能会使用此身份验证方法。
- 工作量。 对于直通身份验证,需要有一个或多个(我们建议三个)轻量代理安装在现有服务器上。 这些代理必须有权访问本地 Active Directory 域服务,包括本地 AD 域控制器。 它们需要具有对 Internet 的出站访问权限以及对域控制器的访问权限。 因此,不支持将这些代理部署在外围网络中。
- 用户体验。 若要改善用户的登录体验,请将无缝 SSO 随直通身份验证一起部署。 在用户登录后,无缝 SSO 将消除不必要的提示。
- 高级方案。 直通身份验证在登录时强制实施本地帐户策略。 例如,如果一个本地用户的帐户状态为已禁用、已锁定,或其密码已过期,则访问会被拒绝。 如果登录尝试不在用户被允许登录的时间段内,访问也可能会被拒绝。
- 业务连续性。 我们建议部署两个额外的直通身份验证代理。 这些额外的代理是 Microsoft Entra Connect 服务器上第一个代理之外的代理。 此部署可确保身份验证请求的高可用性。 如果部署了三个代理,关闭一个代理进行维护时另一个仍然可能失败。
- 注意事项。 当代理由于明显的本地故障而无法验证用户的凭据时,可以使用密码哈希同步作为直通身份验证的备份身份验证方法。 故障转移到密码哈希同步不会自动发生,必须使用 Microsoft Entra Connect 手动切换登录方法。
联合身份验证
选择此身份验证方法时,Microsoft Entra ID 会将身份验证过程移交给单独的受信任身份验证系统(例如本地 Active Directory 联合身份验证服务 [AD FS])来验证用户的密码。 身份验证系统可以提供其他高级身份验证要求。 例如,基于智能卡的身份验证或第三方多重身份验证。
工作量。 联合身份验证系统依赖于外部受信任系统对用户进行身份验证。 某些公司想要借助 Microsoft Entra 混合标识解决方案重复使用现有联合系统投资。 联合系统的维护和管理超出 Microsoft Entra ID 控制。 这由组织负责,组织可通过使用联合系统确保它已安全部署并可处理身份验证负载。
用户体验。 联合身份验证的用户体验依赖于联合服务器场功能、拓扑和配置的实现。 某些组织需要这种灵活性来调整和配置对联合服务器场的访问权限,以满足其安全要求。 例如,可以配置内部连接用户和设备以使用户自动登录,不会提示其输入凭据。 此配置之所以有效,是因为他们已经登录到自己的设备。 必要时,某些高级安全功能将使用户的登录过程更加困难。
高级方案。 客户有 Microsoft Entra ID 本机不支持的身份验证要求时,需要联合身份验证解决方案。
- 需要智能卡或证书的身份验证。
- 需要联合标识提供程序的本地 MFA 服务器或第三方多重身份验证提供程序。
- 使用第三方身份验证解决方案的身份验证。
- 需要 sAMAccountName(例如,DOMAIN\username)而不是用户主体名称 (UPN)(例如,user@domain.com)的登录。
业务连续性。 联合身份验证系统通常需要负载均衡的服务器阵列(称为场)。 此场在内部网络和外围网络拓扑中配置,以便为身份验证请求确保高可用性。
注意事项。 联合系统通常在本地基础结构方面需要更可观的投资。 大多数组织会选择此选项,前提是它们已有本地联合身份验证投资, 并且使用单标识提供者是非常强烈的业务需求。 与云身份验证解决方案相比,联合的操作和故障排除更加复杂。
体系结构关系图
下图扼要地绘出了每个可用于 Microsoft Entra 混合标识解决方案的身份验证方法所需的高级体系结构组件。 此外还提供了概述,以便帮助你比较解决方案之间的差异。
密码哈希同步解决方案的简单性:
直通身份验证的代理要求,使用两个代理提供冗余:
组织的外围和内部网络中联合身份验证所需的组件:
建议
标识系统确保用户有权访问云应用、迁移到云中的业务线应用以及在云中提供的业务线应用。 为了使授权用户保持效率并防止歹徒接触组织的敏感数据,身份验证会控制对应用的访问。
无论选择了哪种身份验证方法,都请为其使用或启用密码哈希同步,原因如下:
高可用性和灾难恢复。 直通身份验证和联合依赖于本地基础结构。 对于传递身份验证,本地内存占用包括传递身份验证代理所需的服务器硬件和网络。 对于联合身份验证,本地占用的设备更多。 它需要外围网络中的服务器来代理身份验证请求,并且还需要内部联合服务器。 若要避免单一故障点,请部署冗余服务器。 这样,如果任何组件出现故障,系统均会始终为身份验证请求提供服务。 直通身份验证和联合身份验证都也依赖于域控制器来响应身份验证请求(也可能会失败)。 这些组件中的许多组件都需要维护以保持正常运行。 如果未正确计划并实施维护,很有可能会发生服务中断。 请通过使用密码哈希同步避免服务中断,因为 Microsoft Entra 云身份验证服务可在全球缩放且始终可用。
本地服务中断生存。 网络攻击或灾难造成的本地服务中断可能导致从品牌信誉损失到瘫痪的组织无法处理攻击等一系列的严重后果。 最近,许多组织都受到恶意软件(包括有针对性的勒索软件)的攻击,导致其本地服务器停机。 Microsoft 在帮助客户处理这些类型的攻击时发现两种类型的组织:
- 启用了密码哈希同步且使用联合身份验证或直通身份验证的组织将更改其主要身份验证。 然后他们就可以使用密码哈希同步了。 它们在数小时内即可重新联机。 通过使用 Microsoft 365 访问电子邮件,他们致力于解决问题并访问其他基于云的工作负载。
- 先前未启用密码哈希同步的组织必须依靠不受信任的外部使用者电子邮件系统进行通信来解决问题。 在这些情况下,他们花费了数周时间来还原其本地标识基础结构,然后用户才能再次登录到基于云的应用。
标识保护。 保护云中用户的最佳方法之一是使用 Microsoft Entra Premium P2 的 Microsoft Entra 标识保护。 Microsoft 不断扫描 Internet 以查找歹徒在暗网上销售和提供的用户和密码列表。 Microsoft Entra 可以用此信息验证组织的任意用户名和密码是否泄漏。 因此,无论使用哪种身份验证方法(无论其是联合身份验证还是直通身份验证),启用密码哈希同步都至关重要。 泄漏的凭据将以报表形式提供。 使用此信息可阻止或强制用户在尝试使用泄漏的密码登录时更改其密码。
Microsoft Entra Connect 设计概念
本部分介绍了在实现 Microsoft Entra Connect 设计期间必须考虑到的各个方面。 这是特定领域的深入探讨,其他文档中也简要介绍了这些概念。
sourceAnchor
sourceAnchor 属性定义为在对象生存期内不会变化的属性。 它可将对象唯一标识为本地和 Microsoft Entra ID 中的相同对象。 该属性也称为 immutableId,这两个名称可以换用。 该属性用于以下方案︰
- 构建新的同步引擎服务器,或者在灾难恢复方案后进行重建时,此属性会将 Microsoft Entra ID 中的现有对象链接到本地对象。
- 如果从仅限云的标识转移到已同步的标识模型,则此属性可让对象将 Microsoft Entra ID 中的现有对象与本地对象进行“硬匹配”。
- 如果使用联合,此属性将与 userPrincipalName 一起在声明中使用,以唯一标识用户。
属性值必须遵循以下规则:
长度少于 60 个字符
- 系统将 a-z、A-Z 或 0-9 以外的字符编码并计为 3 个字符
不包含特殊字符:
\ ! # $ % & * + / = ? ^ { } | ~ > < ( ) ' ; : , [ ] " @ _
必须全局唯一
必须是字符串、整数或二进制数
不应基于用户的名称,因为名称可以更改
不应区分大小写,并避免使用可能因大小写而改变的值
应在创建对象时分配
如果你有单个本地林,应使用属性 objectGuid。 在 Microsoft Entra Connect 中使用快速设置时,还可以使用 objectGuid 属性。 还有 DirSync 使用的属性。 如果你有多个林,并且不在林和域之间移动用户,则适合使用 objectGUID 属性。 另一个解决方案是选择已知不会更改的现有属性。 常用的属性包括 employeeID。 如果考虑使用一个包含字母的属性,请确保属性值的大小写(大写与小写)不会更改。 不应使用的不合适属性包括那些包含用户名称的属性。 确定 sourceAnchor 属性以后,向导会将信息存储在 Microsoft Entra 租户中。 该信息会供将来的 Microsoft Entra Connect 安装使用。
Microsoft Entra 登录日志
本地目录与 Microsoft Entra ID 集成的同步设置可能会影响用户的身份验证方式。 Microsoft Entra 使用 userPrincipalName (UPN) 对用户进行身份验证。 但是,在同步用户时,必须小心选择要用于 userPrincipalName 值的属性。 选择属性以便提供用于 Azure 的 UPN 值时,应确保
- 属性值符合 UPN 语法 (RFC 822),格式为 username@domain
- 这些值的后缀符合 Microsoft Entra ID 中其中一个已验证的自定义域
在快速设置中,属性的假设选择是 userPrincipalName。 如果 userPrincipalName 属性不包含你希望用户用于登录 Azure 的值,则必须选择“自定义安装”。
自定义域状态和用户主体名称
确保用户主体名称 (UPN) 后缀有一个已验证的域。 John 是 contoso.com 中的用户。 在将用户同步到 Microsoft Entra 目录 contoso.onmicrosoft.com 之后,你希望 John 使用本地 UPN john@contoso.com 登录到 Azure。 为此,需要将 contoso.com 添加为 Microsoft Entra ID 中的自定义域并进行验证,才能开始同步用户。 如果 John 的 UPN 后缀(例如 contoso.com)与 Microsoft Entra ID 中已验证的域不匹配,该工具会将该 UPN 后缀替换为 contoso.onmicrosoft.com。
有些组织使用不可路由的域(例如 contoso.local)或简单的单标签域(例如 contoso)。 你不能验证不可路由的域。 Microsoft Entra Connect 只能同步到 Microsoft Entra ID 中的已验证域。 创建 Microsoft Entra 目录时,将创建可路由的域,而该域将成为 Microsoft Entra ID 的默认域,例如 contoso.onmicrosoft.com。 因此,如果不想要同步到默认的 onmicrosoft.com 域,则必须在此类方案中验证任何其他可路由的域。
Microsoft Entra Connect 将检测你是否在不可路由的域环境中运行,并在适当的情况下发出警告,提示不要继续使用快速设置。 如果你在不可路由的域中操作,用户的 UPN 可能也包含不可路由的后缀。 例如,如果在 contoso.local 下运行,Microsoft Entra Connect 会建议使用自定义设置而不是快速设置。 使用自定义设置,可以在用户同步到 Microsoft Entra ID 之后,指定应用作 UPN 以供登录 Azure 的属性。
Microsoft Entra Connect 的拓扑
本部分介绍了使用 Microsoft Entra Connect 同步作为关键集成解决方案的各种本地拓扑和 Microsoft Entra ID 拓扑;其中包括支持和不支持的配置。
常见拓扑 | 描述 |
---|---|
单个林、单个 Microsoft Entra 租户 | 最常见的拓朴是包含一个或多个域的单个本地林,以及单个 Microsoft Entra 租户。 身份验证将使用密码哈希同步。 Microsoft Entra Connect 的快速安装仅支持此拓扑。 |
单个林、单个 Microsoft Entra 租户 | 许多组织具有包含多个本地 Active Directory 林的环境。 有多种原因导致出现多个本地 Active Directory 林。 典型示例是使用帐户资源林的设计,以及合并和收购之后采用的设计。 如果具有多个林,则所有林必须可由单个 Microsoft Entra Connect 同步服务器访问。 服务器必须加入域。 如果需要访问所有林,可将服务器放在外围网络(也称为外围网络、外围安全区域或屏蔽子网)中。 |
多个林、单个同步服务器、用户仅在一个目录中表示 | 在此环境中,所有本地林都被视为独立的实体。 没有用户出现在任何其他林中。 每个林都有其自己的 Exchange 组织,并且林之间没有任何 GALSync。 合并/收购之后或者如果组织中的每个业务单位独立运营,可能会出现这种拓扑。 在 Microsoft Entra 中,这些林位于相同的组织中并与统一 GAL 一起出现。 在上图中,每个林中的每个对象会在 Metaverse 中出现一次,并在目标租户中聚合。 |
多个林:包含可选 GALSync 的完整网格 | 完整网格拓扑允许用户和资源位于任何林中。 通常,林之间建立了双向信任。 如果 Exchange 存在于多个林中,则可以选择使用本地 GALSync 解决方案。 这样,每个用户将表示为其他所有林中的联系人。 GALSync 通常是使用 FIM 2010 或 MIM 2016 实现的。 Microsoft Entra Connect 不能用于本地 GALSync。 |
多个林:帐户资源林 | 在此方案中,一个(或多个)资源林信任所有帐户林。 资源林通常包含装有 Exchange 和 Teams 的扩展 Active Directory 架构。 所有 Exchange 和 Teams 服务以及其他共享服务都位于此林中。 用户在此林中具有一个禁用的用户帐户,并且邮箱被链接到帐户林。 |
暂存服务器 | Microsoft Entra Connect 支持以暂存模式安装第二个服务器。 使用此模式的服务器从所有已连接的目录读取数据,但不会向已连接的目录写入任何数据。 它使用普通的同步周期,因此具有标识数据的更新副本。 |
多个 Microsoft Entra 租户 | Microsoft Entra Connect 同步服务器与租户之间存在 1:1 关系。 对于每个 Microsoft Entra 租户,需要安装一台 Microsoft Entra Connect 同步服务器。 AD 租户实例在设计上是隔离的。 也就是说,一个租户中的用户看不到另一个租户中的用户。 用户分离是受支持的配置。 否则,应使用单个 Microsoft Entra 租户模型。 |
每个对象仅在 Microsoft Entra 租户中出现一次 | 在此拓扑中,一台 Microsoft Entra Connect 同步服务器会连接到每个租户。 必须配置 Microsoft Entra Connect 同步服务器以进行筛选,以便每台服务器具有一组可以操作的互斥对象。 例如,可将每个服务器的范围设置为特定域或组织单位。 |
Microsoft Entra Connect 组件因素
下图显示了连接到一个林(尽管支持多个林)的预配引擎的高级体系结构。 此体系结构展示各组件之间的相互交互。
预配引擎连接到每个 Active Directory 林且连接到 Microsoft Entra ID。 从每个目录读取信息的过程称为“导入”。 导出是指从预配引擎更新目录。 同步则评估规定对象在预配引擎内的流动方式的规则。
Microsoft Entra Connect 使用以下临时区域、规则和过程,以实现从 Active Directory 到 Microsoft Entra ID 的同步:
- 连接器空间 (CS) - 在此暂存每个已连接目录(缩写为 CD,是实际目录)的对象,然后再由预配引擎处理它们。 Microsoft Entra ID 具有自己的 CS,并且连接的每个林将具有自己的 CS。
- Metaverse (MV) - 在此根据同步规则创建需要同步的对象。 对象必须存在于 MV 中,然后它们才能将对象和属性填充到其他连接的目录。 只有一个 MV。
- 同步规则 - 决定将创建(投射)哪些对象或将哪些对象连接(联接)到 MV 中的对象。 还决定要从目录或向目录复制或转换的属性值。
- 运行配置文件 - 根据暂存区域和已连接目录之间的同步规则,捆绑复制对象及其属性值的过程步骤。
Microsoft Entra 云同步
Microsoft Entra Connect 云同步旨在实现将用户、组和联系人同步到 Microsoft Entra ID 的混合标识目标。 同步是通过使用 Microsoft Entra 云预配代理,而不是使用 Microsoft Entra Connect 应用程序实现的。 它可以与 Microsoft Entra Connect 同步一起使用,并具有以下优势:
- 支持从多林离线 Active Directory 林环境同步到 Microsoft Entra 租户:常见方案包括合并和收购。 被收购公司的 AD 林独立于父公司的 AD 林。 这些公司在过去拥有多个 AD 林。
- 使用轻型预配代理简化安装:代理充当 AD 与 Microsoft Entra ID 之间的桥梁,所有同步配置托管在云中。
- 可以使用多个预配代理来简化高可用性部署,这对于依赖于从 AD 到 Microsoft Entra 之间的密码哈希同步的组织而言非常重要。
- 支持最多有 5 万名成员的大型组。 建议在同步大型组时仅使用 OU 范围筛选器。
使用 Microsoft Entra Connect 云同步时,从 AD 到 Microsoft Entra ID 的预配将在 Microsoft Online Services 中经过协调。 组织只需在其本地或 IaaS 托管环境中部署一个轻量级代理充当 Microsoft Entra ID 与 AD 之间的桥梁。 预配配置存储在服务中,并作为服务的一部分进行管理。 请注意,同步每 2 分钟运行一次。