转换到云

让组织中的人员不再增加 Active Directory 的使用后,便可以专注于将现有本地工作负载移动到 Microsoft Entra ID。 本文介绍各种迁移工作流。 可以根据优先级和资源执行本文中的工作流。

典型的迁移工作流包括以下阶段:

  • 发现:了解环境中当前拥有的内容。

  • 试点:将新的云功能部署到一小部分的用户、应用程序或设备,具体取决于工作流。

  • 横向扩展:扩大试点范围以完成功能到云的过渡。

  • 完全过渡(时机成熟时):停止使用旧的本地工作负载。

用户和组

启用密码自助服务

建议使用无密码环境。 在此之前,可以将密码自助服务工作流从本地系统迁移到 Microsoft Entra ID 以简化环境。 Microsoft Entra ID 自助式密码重置 (SSPR) 使用户能够更改或重置其密码,而不需要管理员或支持人员。

若要启用自助服务功能,请选择适合组织的身份验证方法。 更新身份验证方法后,可在 Microsoft Entra 身份验证环境中启用用户自助式密码功能。 如需部署指导,请参阅 Microsoft Entra 自助式密码重置的部署注意事项

其他注意事项包括:

注意

组的移动管理

转换组和通讯组列表:

将用户和组的预配移至应用程序

可以通过从本地标识管理 (IDM) 系统(如 Microsoft Identity Manager)中删除应用程序预配流简化环境。 基于应用程序发现,根据以下特征对应用程序进行分类:

有关详细信息,请查看为 Microsoft Entra ID 规划自动用户预配部署

移动到云 HR 预配

可以通过将 HR 预配工作流从本地 IDM 系统(如 Microsoft Identity Manager)移动到 Microsoft Entra ID,减少本地内存占用空间。 可以使用两种帐户类型来进行 Microsoft Entra 云 HR 预配:

  • 对于只用使用 Microsoft Entra ID 的应用程序的新员工,可以选择预配仅限云的帐户。 此预配可以帮助你抑制 Active Directory 的内存占用空间。

  • 对于需要访问依赖于 Active Directory 的应用程序的新员工,可以预配混合帐户。

Microsoft Entra 云 HR 预配还可以管理现有员工的 Active Directory 帐户。 有关详细信息,请参阅规划云 HR 应用程序到 Microsoft Entra 用户预配规划部署项目

迁移生命周期工作流

评估现有的加入者/迁移者/离开者工作流和流程,了解其适用性和与 Microsoft Entra 云环境的相关性。 然后,可以简化这些工作流并使用生命周期工作流创建新工作流

移动外部标识管理

如果你的组织要在 Active Directory 或其他本地目录中为外部标识(如供应商、承包商、顾问)预配帐户,你可以通过在云中本机管理这些第三方用户对象来简化环境。 下面是一些可能的错误:

  • 对于新的外部用户,使用 Microsoft Entra 外部标识,这会停止用户的 Active Directory 占用。

  • 对于为外部标识预配的现有 Active Directory 帐户,可以通过为企业对企业 (B2B) 协作配置本地凭据(例如密码)来消除管理本地凭据的开销。 按照邀请内部用户参与 B2B 协作中的步骤进行操作。

  • 使用 Microsoft Entra 权利管理授予对应用程序和资源的访问权限。 大多数公司都有实现此目的的专用系统和工作流,因此现在可以移出本地工具。

  • 使用访问评审,删除不再需要的访问权限和/或外部标识。

设备

移动非 Windows 工作站

可以将非 Windows 工作站与 Microsoft Entra ID 集成,增强用户体验,并从基于云的安全功能(如条件访问)中受益。

为工作站替换其他 Windows 版本

如果工作站具有以下操作系统,请考虑升级为最新版本,以从云原生管理(Microsoft Entra 联接和统一终结点管理)中受益:

  • Windows 7 和 8.x

  • Windows Server

VDI 解决方案

此项目有两个主要计划:

  • 新部署:部署不需要本地 Active Directory 的云托管虚拟桌面基础结构 (VDI) 解决方案,例如 Windows 365 或 Azure 虚拟桌面。

  • 现有部署:如果现有的 VDI 部署依赖于 Active Directory,请根据业务目标来确定是保留解决方案还是将其迁移到 Microsoft Entra ID。

有关详细信息,请参阅:

应用程序

为了帮助维护安全环境,Microsoft Entra ID 支持新式身份验证协议。 若要将应用程序身份验证从 Active Directory 转换到 Microsoft Entra ID,必须:

  • 确定哪些应用程序无需修改就可以迁移到 Microsoft Entra ID。

  • 确定哪些应用程序具有可通过升级实现迁移的升级路径。

  • 确定哪些应用程序需要进行替换或需要重大代码更改才能迁移。

应用程序发现计划的结果是创建用于迁移应用程序组合的、确定了优先顺序的列表。 该列表包含需要以下操作的应用程序:

  • 需要对软件进行升级或更新,并且有可用的升级路径。

  • 需要对软件进行升级或更新,但没有可用的升级路径。

使用该列表,可以进一步评估没有现有升级路径的应用程序。 根据软件的商业价值确定是要更新软件还是停用软件。 如果该软件应停用,请决定是否需要替换。

根据结果,可以重新设计从 Active Directory 到 Microsoft Entra ID 的转换的各个方面。 对于具有不受支持的身份验证协议的应用程序,可以使用多种方法将本地 Active Directory 扩展到 Azure 基础结构即服务 (IaaS)(直接迁移)。 建议设置规定在例外情况下才能使用此方法的策略。

应用程序发现

对应用组合进行细分后,可以根据商业价值和业务优先级确定迁移优先级。 可以使用工具来创建或刷新应用清单。

可以使用三种主要方法对应用进行分类:

  • 新式身份验证应用:这些应用程序使用新式身份验证协议(如 OIDC、OAuth2、SAML、WS 联合身份验证),或使用联合身份验证服务(如 Active Directory 联合身份验证服务 (AD FS))。

  • Web 访问管理 (WAM) 工具:这些应用程序使用标头、Cookie 和类似技术来实现 SSO。 这些应用通常需要 WAM 标识提供程序,例如 Symantec SiteMinder。

  • 旧应用:这些应用程序使用旧协议,例如 Kerberos、LDAP、Radius、远程桌面、NTLM(不建议)。

Microsoft Entra ID 可与其中每种应用程序一起使用,提供各种级别的功能,这会导致产生不同的迁移策略、复杂性和作不同的权衡考虑。 某些组织具有应用程序清单,可充当发现基线。 (常有此清单不完整或不是最新状态的情况。)

为发现新式身份验证应用,请执行以下操作:

以下工具可帮助发现使用 LDAP 的应用程序:

  • Event1644Reader:使用字段工程日志收集数据的示例工具,所收集的数据是有关对域控制器进行的 LDAP 查询的数据。

  • Microsoft 365 Defender for Identity:使用登录操作监视功能的安全性解决方案。 (请注意,它使用 LDAP 而不是安全 LDAP 来捕获绑定。)

  • PSLDAPQueryLogging:GitHub 工具,用于报告 LDAP 查询。

迁移 AD FS 或其他联合身份验证服务

计划迁移到 Microsoft Entra ID 时,请考虑首先迁移使用新式身份验证协议(例如 SAML 和 Open ID Connect)的应用。 可通过 Azure 应用库中的内置连接器或通过在 Microsoft Entra ID 中注册应用程序,将这些应用程序重新配置为使用 Microsoft Entra ID 进行身份验证。

迁移了已联合到 Microsoft Entra ID 的 SaaS 应用程序后,可通过几个步骤解除本地联合身份验证系统授权:

重要

如果正在使用其他功能,请在停用 Active Directory 联合身份验证服务之前验证这些服务是否已重新定位。

移动 WAM 身份验证应用

此项目侧重于将 SSO 功能从 WAM 系统迁移到 Microsoft Entra ID。 若要了解详细信息,请参阅将应用程序从 Symantec SiteMinder 迁移到 Microsoft Entra ID

定义应用程序服务器管理策略

在基础结构管理方面,本地环境通常使用组策略对象 (GPO) 和 Microsoft Configuration Manager 功能的组合来划分管理职责。 例如,职责可以划分为安全策略管理、更新管理、配置管理和监视。

Active Directory 适用于本地 IT 环境,Microsoft Entra ID 适用于基于云的 IT 环境。 此处不存在功能的一对一奇偶一致性,因此可以通过多种方式管理应用程序服务器。

例如,使用 Microsoft Entra ID 进行标识和访问管理 (IAM) 时,Azure Arc 有助于将 Active Directory 中的许多功能集中引入一个视图。 还可以使用 Microsoft Entra 域服务将 Microsoft Entra ID 中的服务器加入域,尤其是在出于特定业务或技术原因而希望这些服务器使用 GPO 时。

使用下表确定要使用哪些基于 Azure 的工具来替换本地环境:

管理区域 本地 (Active Directory) 功能 等效 Microsoft Entra 功能
安全性策略管理 GPO、Microsoft Configuration Manager Microsoft 365 Defender for Cloud
更新管理 Microsoft Configuration Manager、Windows Server Update Services Azure 自动化更新管理
配置管理 GPO、Microsoft Configuration Manager Azure 自动化状态配置
监视 System Center Operations Manager Azure Monitor Log Analytics

以下是有关应用程序服务器管理的详细信息:

如果需要使用 Microsoft Configuration Manager 管理应用程序服务器,则无法使用 Microsoft Entra 域服务满足此需求。 不支持在 Microsoft Entra 域服务环境中运行 Microsoft Configuration Manager。 相反,需将本地 Active Directory 实例扩展到 Azure VM 上运行的域控制器。 或者,需将新的 Active Directory 实例部署到 Azure IaaS 虚拟网络。

定义旧应用程序迁移策略

旧应用程序对 Active Directory 具有以下依赖项:

  • 用户身份验证和授权:Kerberos、NTLM、LDAP 绑定、ACL。

  • 访问目录数据:LDAP 查询、架构扩展、目录对象的读取/写入。

  • 服务器管理:由服务器管理策略确定。

若要减少或消除这些依赖项,可以使用三种主要方法。

方法 1

在此首选方法中,执行相应项目,从旧应用程序迁移到使用新式身份验证的 SaaS 替代项。 让 SaaS 替代项直接向 Microsoft Entra ID 进行身份验证:

  1. 将 Microsoft Entra 域服务部署到 Azure 虚拟网络,并且扩展架构以合并应用程序所需的其他属性。

  2. 将旧应用直接迁移到已在 Microsoft Entra 域服务中加入域的 Azure 虚拟网络上的 VM。

  3. 使用 Microsoft Entra 应用程序代理或安全混合访问合作伙伴将旧应用发布到云。

  4. 由于旧应用通过消耗的方式停用,最终停用在 Azure 虚拟网络中运行的 Microsoft Entra 域服务。

注意

方法 2

如果第一种方法不可行且应用程序对 Active Directory 具有强依赖性,则可以将本地 Active Directory 扩展到 Azure IaaS。

可以重新设置平台以支持新式无服务器托管,例如使用平台即服务 (PaaS)。 也可以更新代码以支持新式身份验证。 还可以直接将应用与 Microsoft Entra ID 集成。 了解 Microsoft 标识平台中的 Microsoft 身份验证库

  1. 通过虚拟专用网络 (VPN) 或 Azure ExpressRoute 将 Azure 虚拟网络连接到本地网络。

  2. 将本地 Active Directory 实例的新域控制器作为虚拟机部署到 Azure 虚拟网络中。

  3. 将旧应用直接迁移到已加入域的 Azure 虚拟网络上的 VM。

  4. 使用 Microsoft Entra 应用程序代理或安全混合访问合作伙伴将旧应用发布到云。

  5. 最终,停用本地 Active Directory 基础结构,并完全在 Azure 虚拟网络中运行 Active Directory。

  6. 由于旧应用通过消耗的方式停用,最终停用在 Azure 虚拟网络中运行的 Active Directory 实例。

方法 3

如果第一种迁移不可行且应用程序对 Active Directory 具有强依赖性,则可以将新的 Active Directory 实例部署到 Azure IaaS。 在可预见的未来一段时间内保留旧应用程序或停用这些应用程序,直到合适时机出现。

此方法使你可以将应用与现有 Active Directory 实例分离,从而减少外围应用。 建议尽量不要使用此方法。

  1. 将新的 Active Directory 实例作为虚拟机部署到 Azure 虚拟网络。

  2. 将旧应用直接迁移到已在新 Active Directory 实例中加入域的 Azure 虚拟网络上的 VM。

  3. 使用 Microsoft Entra 应用程序代理或安全混合访问合作伙伴将旧应用发布到云。

  4. 由于旧应用通过消耗的方式停用,最终停用在 Azure 虚拟网络中运行的 Active Directory 实例。

策略比较

策略 Microsoft Entra 域服务 将 Active Directory 扩展到 IaaS IaaS 中的独立 Active Directory 实例
与本地 Active Directory 分离 No
允许架构扩展
完全管理控制
可能需要重新配置应用(例如 ACL 或授权) No

移动 VPN 身份验证

此项目的重点是将 VPN 身份验证移动到 Microsoft Entra ID。 必须知道,VPN 网关连接可以使用不同的配置。 必须确定哪种配置最适合自己的需要。 有关设计解决方案的详细信息,请参阅 VPN 网关设计

以下是有关将 Microsoft Entra ID 用于 VPN 身份验证的一些要点:

将远程访问移动到内部应用程序

为了简化环境,可以使用 Microsoft Entra 应用程序代理安全混合访问合作伙伴来提供远程访问。 这样就可以消除对本地反向代理解决方案的依赖。

值得一提的是,使用上述方法启用对应用程序的远程访问是一个中间步骤。 要将应用程序与 Active Directory 完全分离需完成更多工作。

Microsoft Entra 域服务使你能够将应用程序服务器迁移到云 IaaS 并从 Active Directory 分离,同时使用 Microsoft Entra 应用程序代理启用远程访问。 有关此场景的更多信息,请参阅为 Microsoft Entra 域服务部署 Microsoft Entra 应用代理

后续步骤