此参考体系结构展示如何将本地 Active Directory 域扩展到 Azure 以提供分布式身份验证服务。
体系结构
下载此体系结构的 Visio 文件。
此体系结构扩展了使用 VPN 网关将本地网络连接到 Azure 中显示的混合网络体系结构。
工作流
- 本地网络。 本地网络包括可以对位于本地的组件执行身份验证和授权的本地 Active Directory 服务器。
- Active Directory 服务器。 这些服务器是域控制器,用于实现在云中作为 VM 运行的目录服务 (AD DS)。 它们可以为在 Azure 虚拟网络中运行的组件提供身份验证。
- Active Directory 子网。 Active Directory 域服务 (AD DS) 服务器托管在单独的子网中。 网络安全组 (NSG) 规则对 AD DS 服务器进行保护,并提供防火墙以阻止来自意外来源的流量。
- Azure VPN 网关和 Active Directory 同步。 VPN 网关在本地网络与 Azure 虚拟网络之间提供连接。 此连接可以是 VPN 连接,也可以 Azure ExpressRoute 连接。 云中的 Active Directory 服务器与本地 Active Directory 服务器之间的所有同步请求都通过该网关。 用户定义的路由 (UDR) 处理传递到 Azure 的本地流量的路由。
组件
- Microsoft Entra ID 是一种企业标识服务,提供单一登录、多重身份验证和条件访问。
- VPN 网关是一项服务,使用虚拟网络网关通过公共 Internet 在 Azure 虚拟网络和本地位置之间发送加密的流量。
- 使用 ExpressRoute 可通过连接服务提供商所提供的专用连接,将本地网络扩展到 Microsoft 云。
- 虚拟网络是 Azure 中专用网络的基本构建块。 可以使用它让 Azure 资源(例如虚拟机)彼此通信、与 Internet 通信以及与本地网络通信。
方案详细信息
如果应用程序一部分托管在本地,一部分托管在 Azure 中,则在 Azure 中复制 AD DS 可能更高效。 这样进行复制可以减少因将身份验证请求从云发送回本地运行的 AD DS 而导致的延迟。
有关其他注意事项,请参阅选择用于将本地 Active Directory 与 Azure 相集成的解决方案。
可能的用例
当 VPN 或 Azure ExpressRoute 连接连接本地和 Azure 虚拟网络时,通常使用此体系结构。 此体系结构还支持双向复制,这意味着既可以在本地又可以在云中进行更改,并且两个源都将保持一致。 此体系结构的典型用途包括功能分布在本地和 Azure 中的混合应用程序以及使用 Active Directory 执行身份验证的应用程序和服务。
建议
以下建议适用于大多数场景。 除非有优先于这些建议的特定要求,否则请遵循这些建议。
VM 建议
根据预计的身份验证请求量决定 VM 大小。 使用在本地托管着 AD DS 的计算机的规范作为起点,并使其与 Azure VM 大小相匹配。 在部署后,监视利用率并根据 VM 上的实际负载纵向扩展或收缩。 有关确定 AD DS 域控制器大小的详细信息,请参阅 Capacity Planning for Active Directory Domain Services(Active Directory 域服务的容量规划)。
创建一个单独的虚拟数据磁盘,用以存储 Active Directory 的数据库、日志和 sysvol 文件夹。 不要将这些项与操作系统存储在同一磁盘上。 默认情况下,附加到 VM 的数据磁盘使用直写式缓存。 但是,这种形式的缓存可能会与 AD DS 的要求发生冲突。 因此,请将数据磁盘上的“主机缓存首选项”设置设为“无”。
部署至少两个将 AD DS 作为域控制器运行的 VM,并将它们添加到不同的可用性区域中。 如果区域中不可用,请在可用性集中进行部署。
网络建议
为每个 AD DS 服务器的 VM 网络接口 (NIC) 配置一个静态专用 IP 地址,以提供完整的域名服务 (DNS) 支持。 有关详细信息,请参阅如何在 Azure 门户中设置静态专用 IP 地址。
注意
不要为任何 AD DS 的 VM NIC 配置公共 IP 地址。 有关更多详细信息,请参阅安全注意事项。
Active Directory 子网 NSG 要求规则允许来自本地的传入流量和传出到本地的流量。 有关 AD DS 使用的端口的详细信息,请参阅 Active Directory and Active Directory Domain Services Port Requirements(Active Directory 和 Active Directory 域服务端口要求)。
如果新的域控制器 VM 也具有 DNS 服务器的角色,建议将它们配置为虚拟网络级别的自定义 DNS 服务器,如更改 DNS 服务器中所述。 对于托管新域控制器和对等互连网络的虚拟网络,如果其他 VM 必须在其中解析 Active Directory 域名,应执行此操作。 有关如何配置混合 DNS 名称解析的详细信息,请参阅 Azure 虚拟网络中资源的名称解析。
如果是首次配置,可能需要调整 Azure 中其中一个域控制器的网络接口,让其指向本地域控制器作为主 DNS 源。
将其 IP 地址包含在 DNS 服务器列表中可提高性能并提高 DNS 服务器的可用性。 但是,如果 DNS 服务器也是域控制器,并且仅指向自身或首先指向自身进行名称解析,则可能会导致启动延迟。 出于此原因,如果服务器也是域控制器,请在适配器上配置环回地址时要小心。
这可能意味着覆盖 Azure 中的网络接口 DNS 设置,以指向主 DNS 服务器在 Azure 中或本地托管的另一个域控制器。 应仅将环回地址配置为域控制器上的二级或三级 DNS 服务器。
Active Directory 站点
在 AD DS 中,站点表示一个物理位置、网络或表示设备集合。 AD DS 站点用来管理 AD DS 数据库复制,它们将位置彼此靠近且由高速网络连接的 AD DS 对象分组到一起。 AD DS 包含相应的逻辑来选择用于在站点之间复制 AD DS 数据库的最佳策略。
建议你创建一个 AD DS 站点,并使其包括在 Azure 中为你的应用程序定义的子网。 然后,可以配置本地 AD DS 站点之间的站点链接,AD DS 将自动执行最高效的数据库复制。 除了初始配置之外,此数据库复制还要求进行少量其他配置。
Active Directory 操作主机
可以向 AD DS 域控制器分配操作主机角色以支持在复制的 AD DS 数据库实例之间执行一致性检查。 有五个操作主机角色 (FSMO):架构主机、域命名主机、相对标识符主机、主域控制器主机模拟器和基础结构主机。 有关这些角色的详细信息,请参阅规划操作主机角色放置。 此外,建议至少为两个新的 Azure DC 提供全局目录 (GC) 角色。 可以在此处找到有关 GC 放置的更多详细信息。
监视
监视域控制器 VM 以及 AD DS 服务的资源并创建一个计划来快速更正任何问题。 有关详细信息,请参阅 Monitoring Active Directory(监视 Active Directory)。 可以在监视服务器上(请参阅体系结构图)安装 Microsoft Systems Center 之类的工具来帮助执行这些任务。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则,即一套可用于改进工作负荷质量的指导原则。 有关详细信息,请参阅 Microsoft Azure 架构良好的框架。
可靠性
可靠性可确保应用程序符合你对客户的承诺。 有关详细信息,请参阅可靠性支柱概述。
将运行 AD DS 的 VM 部署到至少两个可用性区域。 如果该区域中没有可用性区域,请使用可用性集。 另外,请考虑根据需要向至少一台(可能更多)服务器分配备用操作主机角色。 备用操作主机是操作主机的主动副本,在故障转移期间可以替代主操作主机服务器。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统保障措施。 有关详细信息,请参阅安全性支柱概述。
AD DS 服务器提供身份验证服务并且是引入注目的攻击目标。 若要保护它们,请通过以下方法阻止直接 Internet 连接:将 AD DS 服务器放置在一个单独的子网中并使用 NSG 作为防火墙。 关闭 AD DS 服务器上的所有端口,但身份验证、授权和服务器同步所需的那些端口除外。 有关详细信息,请参阅 Active Directory and Active Directory Domain Services Port Requirements(Active Directory 和 Active Directory 域服务端口要求)。
使用 BitLocker 或 Azure 磁盘加密对托管着 AD DS 数据库的磁盘进行加密。
Azure DDoS 防护与应用程序设计最佳做法相结合,提供增强的 DDoS 缓解功能来更全面地防御 DDoS 攻击。 应在任何外围虚拟网络上启用 Azure DDOS 防护。
卓越运营
卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息,请参阅卓越运营支柱概述。
使用基础结构即代码 (IaC) 做法来预配和配置网络安全基础结构。 一个选择是 Azure 资源管理器模板。
隔离工作负荷,使 DevOps 能够执行持续集成和持续交付 (CI/CD),因为每个工作负荷都由其相应的 DevOps 团队关联和管理。
在此体系结构中,包含不同应用层、管理 jumpbox 和 Microsoft Entra 域服务的整个虚拟网络被标识为一个独立工作负荷。
使用虚拟机扩展和其他工具(如用于在虚拟机上配置 AD DS 的 Desired State Configuration (DSC))对虚拟机进行配置。
请考虑使用 Azure DevOps 或任何其他 CI/CD 解决方案来自动执行部署。 Azure Pipelines 是 Azure DevOps Services 的推荐组件,它可将解决方案生成和部署过程自动化,并在 Azure 生态系统中高度集成。
使用 Azure Monitor 分析基础结构的性能。 它还支持在不登录到虚拟机的情况下监视和诊断网络问题。 Application Insights 提供丰富的指标和日志来验证基础结构的状态。
有关详细信息,请参阅 Microsoft Azure 架构良好的框架中的“DevOps”部分。
可管理性
执行定期 AD DS 备份。 不要复制域控制器的 VHD 文件,而是要执行定期备份,因为在复制 VHD 上的 AD DS 数据库文件时,该文件可能未处于一致,导致无法重启数据库。
不建议使用 Azure 门户关闭域控制器 VM。 相反,请从来宾操作系统进行关闭和重新启动。 关闭 Azure 门户会导致 VM 解除分配,这会导致域控制器 VM 重启时产生以下影响:
- 重置 Active Directory 存储库的
VM-GenerationID
和invocationID
- 放弃当前的 Active Directory 相对标识符 (RID) 池
- 将 sysvol 文件夹标记为非授权
第一个问题偏良性。 重复重置 invocationID
会导致复制期间额外占用少量带宽,但这通常并不重要。
第二个问题可能会导致域中的 RID 池耗尽,尤其是在 RID 池大小已配置为大于默认值的情况下。 考虑到如果域已经存在很长时间,或者该域用于需要重复创建和删除帐户的工作流,则该域可能已接近 RID 池耗尽状态。 监视域中的 RID 池耗尽警告事件是不错的做法 - 请查看管理 RID 颁发一文。
只要 Azure 中的域控制器 VM 重启时权威域控制器可用,第三个问题就偏良性。 如果域中的所有域控制器都在 Azure 中运行,并且它们全都同时关闭并解除分配,则重启每个域控制器时将无法找到权威副本。 修复此情况需要手动干预 - 请查看如何对 DFSR 复制的 sysvol 复制强制执行权威和非权威同步一文。
性能效率
性能效率是指工作负荷能够以高效地扩展以满足用户对它的要求。 有关详细信息,请参阅性能效率要素概述。
AD DS 是为实现可伸缩性而设计的。 你不需要配置负载均衡器或流量控制器来将请求定向到 AD DS 域控制器。 唯一的可伸缩性注意事项是为运行 AD DS 的 VM 配置满足你的网络负载要求的合适大小,监视 VM 上的负载并根据需要纵向扩展或收缩。
成本优化
成本优化就是减少不必要的费用和提高运营效率。 有关详细信息,请参阅成本优化支柱概述。
使用 Azure 定价计算器估算成本。 Microsoft Azure 架构良好的框架的“成本”部分描述了其他注意事项。
下面是有关此体系结构中所使用服务的成本注意事项。
AD 域服务
请考虑将 Active Directory 域服务用作由多个工作负荷用来降低成本的共享服务。 有关详细信息,请参阅 Active Directory 域服务定价。
VPN 网关
此体系结构的主要组件是 VPN 网关服务。 会基于预配和提供网关的时间进行收费。
所有入站流量都是免费的,所有出站流量都是收费的。 Internet 带宽费用适用于 VPN 出站流量。
有关详细信息,请参阅 VPN 网关定价。
虚拟网络
虚拟网络是免费的。 允许每个订阅在所有区域中最多创建 1,000 个虚拟网络。 在虚拟网络边界内产生的所有流量都是免费的,因此,同一虚拟网络中两个 VM 之间的通信是免费的。
后续步骤
- 什么是 Microsoft Entra ID?
- Azure DevOps
- Azure Pipelines
- Azure Monitor
- Active Directory 和 Active Directory 域服务端口要求
- Desired State Configuration (DSC)
- 使用 VPN 网关将本地网络连接到 Azure