通过

将应用程序和身份验证迁移到 Microsoft Entra ID 的最佳做法

  • 项目

你听说了 Azure Active Directory 现在是 Microsoft Entra ID，认为现在很适合将 Active Directory 联合身份验证服务 (AD FS) 迁移到 Microsoft Entra ID 中的云身份验证 (AuthN)。 查看选项时，请参阅我们将应用迁移到 Microsoft Entra ID 的大量资源和最佳做法。

在将 AD FS 迁移到 Microsoft Entra ID 之前，请使用 Microsoft Defender for Identity 保护本地资源。 可以主动查找并更正漏洞。 使用评估、分析和数据智能、用户调查优先级评分和对已泄露标识的自动响应。 迁移到云意味着组织可以从新式身份验证中受益，例如用于进行身份验证的无密码方法。

下面是你可能选择不迁移 AD FS 的原因：

  • 你的环境的用户名缺乏层次（如员工 ID）。
  • 你需要更多自定义多重身份验证提供程序的选项。
  • 你使用来自第三方移动设备管理 (MDM) 系统（如 VMware）的设备身份验证解决方案。
  • 你的 AD FS 具有多个云的双重馈送。
  • 你需要气隙网络。

迁移应用程序

规划分阶段推出应用程序迁移，并选择用户验证 Microsoft Entra ID 以进行测试。 利用计划将应用程序迁移到 Microsoft Entra ID和将应用迁移到 Microsoft Entra ID 中的资源中的指导。

在以下视频中了解详细信息：使用 Microsoft Entra ID 轻松迁移应用程序。

应用程序迁移工具

将 AD FS 应用移动到 Microsoft Entra ID 的 AD FS 应用程序迁移目前处于预览阶段，是 IT 管理员将 AD FS 信赖方应用程序从 AD FS 迁移到 Microsoft Entra ID 的指南。 AD FS 应用程序迁移向导提供统一体验来发现、评估和配置新的 Microsoft Entra 应用程序。 它为基本 SAML URL、声明映射和用户分配提供一键式配置，以便将应用程序与 Microsoft Entra ID 集成。 端到端支持迁移本地 AD FS 应用程序，并具有这些功能：

  • 若要帮助识别应用程序使用情况和影响，可评估 AD FS 信赖方应用程序登录活动
  • 若要帮助识别迁移阻碍因素和将应用程序迁移到 Microsoft Entra ID 所需的操作，可分析将 AD FS 迁移到 Microsoft Entra 的可行性
  • 若要自动为给定的 AD FS 应用程序配置新的 Microsoft Entra 应用程序，可通过一键式应用程序迁移过程配置新的 Microsoft Entra 应用程序

阶段 1：发现应用并界定应用范围

发现应用时，添加正在开发的应用和计划的应用。 将它们限定为在迁移完成后使用 Microsoft Entra ID 进行身份验证。

使用活动报表将 AD FS 应用移动到 Microsoft Entra ID。 此报表可帮助你识别可迁移到 Microsoft Entra ID 的应用程序。 该报表可评估 AD FS 应用程序与 Microsoft Entra 的兼容性，检查是否有问题，并提供有关准备要迁移的单个应用程序的指南。

使用 AD FS 到 Microsoft Entra 应用迁移工具从 AD FS 服务器收集信赖方应用程序并分析配置。 在此分析中，报表显示哪些应用可以迁移到 Microsoft Entra ID。 对于不符合条件的应用，可以查看无法迁移的原因说明。

使用 Microsoft Entra Connect AD FS 运行状况代理安装 Microsoft Entra Connect。

了解以下内容的详细信息：“什么是 Microsoft Entra Connect？

阶段 2：对应用分类并规划试点

对应用迁移进行分类是一项重要的实践。 在确定要迁移应用的顺序后，分阶段规划应用迁移和转换。 包括以下应用分类条件：

  • 新式身份验证协议，例如 Microsoft Entra 应用程序库中的第三方软件即服务 (SaaS) 应用，但不通过 Microsoft Entra ID。
  • 需要现代化的旧式身份验证协议，例如第三方 SaaS 应用程序（不在库中，但你可以添加到库）。
  • 使用 AD FS 且可以迁移到 Microsoft Entra ID 的联合应用。
  • 不可现代化的旧式身份验证协议。 现代化可能不包括 Web 应用程序代理 (WinSCP (WAP)) 背后的协议（这些协议可使用 Microsoft Entra 应用程序代理）和可使用安全混合访问的应用程序交付网络/应用程序交付控制器。
  • 新的业务线 (LOB) 应用。
  • 弃用的应用可能具有与其他系统冗余的功能，并且没有业务所有者或用途。

选择第一个迁移应用时，请选择简单的。 条件可以包括在库中支持多个标识提供者 (IdP) 连接的 SaaS 应用。 有具有测试实例访问权限的应用、具有简单声明规则的应用以及控制访问者访问权限的应用。

阶段 3：规划迁移和测试

迁移和测试工具包括用于发现、分类和迁移应用的 Microsoft Entra 应用迁移工具包。 参考 SaaS 应用教程和 Microsoft Entra 单一登录 (SSO) 部署计划的列表，它们逐步讲解端到端过程。

了解 Microsoft Entra 应用程序代理并使用完整的 Microsoft Entra 应用程序代理部署计划。 请考虑使用安全混合访问 (SHA) 将本地的和云中的旧身份验证应用程序连接到 Microsoft Entra ID，以保护这些应用程序。 使用 Microsoft Entra Connect 将 AD FS 用户和组与 Microsoft Entra ID 同步。

阶段 4：规划管理和见解

迁移应用后，请遵循管理和见解指南，确保用户可以安全地访问和管理应用。 获取和共享有关使用情况和应用运行状况的见解。

在 Microsoft Entra 管理中心，使用以下方法审核所有应用：

  • 通过“企业应用程序，审核”来审核应用，或从 Microsoft Entra 报告 API 获取相同的信息来集成到你最喜爱的工具中。
  • 对于使用 Open Authorization (OAuth)/OpenID Connect 的应用，请通过“企业应用程序，权限”查看应用权限。
  • 通过“企业应用程序，登录”和 Microsoft Entra 报告 API 获取登录见解。
  • 可视化来自 Microsoft Entra 工作簿的应用使用情况。

准备验证环境

使用 PowerShell 库中的 MSIdentityTools 来管理、排除故障和报告 Microsoft Identity 产品和服务。 使用 Microsoft Entra Connect Health 监视 AD FS 基础结构。 在 AD FS 中创建测试应用并定期生成用户活动，监视 Microsoft Entra 管理中心中的活动。

将对象同步到 Microsoft Entra ID 时，请检查 AD FS 信赖方信任声明规则，以了解在云中可用的声明规则上使用的组、用户和用户属性。 确保容器和属性同步。

应用迁移方案的差异

当环境包括以下场景时，应用迁移计划需要特别关注。 按照链接获取进一步指导。

  • 证书。 （AD FS 全局签名证书）。 在 Microsoft Entra ID 中，可以为每个应用程序使用一个证书，也可以对所有应用程序使用一个证书。 错开过期日期并配置提醒。 将证书管理委托给最低特权角色。 查看与 Microsoft Entra ID 创建的证书相关的常见问题和信息，以建立 SaaS 应用程序的联合 SSO。
  • 声明规则和基本属性映射。 对于 SaaS 应用程序，可能只需要基本的属性到声明映射。 了解如何自定义 SAML 令牌声明。
  • 从 UPN 中提取用户名。 Microsoft Entra ID 支持基于正则表达式的转换（也与自定义 SAML 令牌声明相关）。
  • 组声明。 发出由成员用户筛选且分配给应用程序的组声明。 可以使用 Microsoft Entra ID 为应用程序配置组声明。
  • Web 应用程序代理。 使用 Microsoft Entra 应用程序代理进行发布，以便在不使用 VPN 的情况下安全地连接到本地 Web 应用。 提供对本地 Web 应用的远程访问，并为旧式身份验证协议提供本机支持。

应用程序迁移过程计划

请考虑在应用程序迁移过程中添加以下步骤。

  • 克隆 AD FS 应用配置。 设置该应用的测试实例，或在测试 Microsoft Entra 租户上使用模拟应用。 将 AD FS 设置映射到 Microsoft Entra 配置。 计划回滚。 将测试实例切换到 Microsoft Entra ID 并验证。
  • 配置声明和标识符。 若要确认和排除故障，模拟生产应用。 将应用的测试实例指向 Microsoft Entra ID 测试应用程序。 验证并排查访问问题，并根据需要更新配置。
  • 准备迁移生产实例。 根据测试结果将生产应用程序添加到 Microsoft Entra ID。 对于允许存在多个标识提供者 (IdP) 的应用程序，请将 Microsoft Entra ID 配置为向生产实例添加的 IdP。
  • 切换生产实例以使用 Microsoft Entra ID。 对于允许同时存在多个 IdP 的应用程序，请将默认 IdP 更改为 Microsoft Entra ID。 否则，请将 Microsoft Entra ID 配置为生产实例的 IdP。 更新生产实例，以将 Microsoft Entra 生产应用程序用作主 IdP。
  • 迁移第一个应用、运行迁移测试并解决问题。 在 AD FS 应用程序活动报告中引用迁移状态，这些报告为解决潜在迁移问题提供指导。
  • 大规模迁移。 分阶段迁移应用和用户。 使用 Microsoft Entra ID 管理迁移的应用和用户，同时充分测试身份验证。
  • 删除联合身份验证。 确认 AD FS 场不再用于身份验证。 使用故障回复、备份并导出相关配置。

迁移身份验证

准备身份验证迁移时，请确定组织需要哪些身份验证方法。

密码和身份验证策略

使用本地 AD FS 和 Microsoft Entra ID 的专用策略，对齐本地和 Microsoft Entra ID 中的密码过期策略。 请考虑实施组合密码策略，并检查 Microsoft Entra ID 中的弱密码。 切换到托管域后，两种密码过期策略均适用。

允许用户使用自助式密码重置 (SSPR) 重置忘记的密码，以减少支持人员成本。 限制基于设备的身份验证方法。 使密码策略现代化，使其没有定期过期的限制，并能够在出现风险时撤销。 阻止使用弱密码，并使用禁止的密码列表检查密码。 为本地 AD FS 和云启用密码保护。

将分别控制多重身份验证和 SSPR 的 Microsoft Entra ID 旧策略设置迁移到使用身份验证方法策略的统一管理。 过程可逆的迁移策略设置。 在为用户和组精确配置身份验证方法时，可以继续使用租户范围的多重身份验证和 SSPR 策略。

由于 Windows 登录和其他无密码方法需要详细的配置，请通过 Microsoft Authenticator 和 FIDO2 安全密钥启用登录。 使用组来管理部署和限定用户范围。

可以使用主页领域发现策略配置自动加速登录。 了解如何使用自动加速登录来跳过用户名输入界面，并自动将用户转发到联合登录终结点。 使用主页领域发现策略来阻止自动加速登录，以使用多种方式控制用户进行身份验证的方式和位置。

帐户过期策略

用户帐户管理的 accountExpires 属性不会同步到 Microsoft Entra ID。 因此，环境中为密码哈希同步配置的过期 Active Directory 帐户会在 Microsoft Entra ID 中处于活动状态。 使用计划的 PowerShell 脚本在用户 Microsoft Windows Server Active Directory 帐户过期后禁用该帐户，例如 Set-ADUser cmdlet。 相反，从 Microsoft Windows Server Active Directory 帐户中删除过期的帐户后，可重新启用该帐户。

借助 Microsoft Entra ID，可以使用智能锁定来防止攻击。 锁定云中的帐户，然后在本地锁定帐户，以缓解暴力攻击。 云间隔较短，可确保本地阈值至少是 Microsoft Entra 阈值的两到三倍。 将 Microsoft Entra 锁定持续时间设置为长于本地持续时间。 迁移完成后，配置 AD FS Extranet 智能锁定 (ESL) 保护。

规划条件访问部署

条件访问策略灵活性需要仔细规划。 请转到规划 Microsoft Entra 条件访问部署，了解规划步骤。 下面是需要牢记的要点：

  • 使用有意义的命名约定起草条件访问策略
  • 使用包含以下字段的设计决策点电子表格：
    • 分配因素：用户、云应用
    • 条件：位置、设备类型、客户端应用类型、登录风险
    • 控制：阻止、需要多重身份验证、已加入混合 Microsoft Windows Server Active Directory、符合设备要求、批准的客户端应用类型
  • 为条件访问策略选择少量的测试用户
  • 在仅报告模式下测试条件访问策略
  • 使用 what if 策略工具验证条件访问策略
  • 使用条件访问模板，尤其是在组织不熟悉条件访问时

条件访问策略

完成第一重身份验证后，强制实施条件访问策略。 条件访问并不是拒绝服务 (DoS) 攻击等场景的一线防御。 但条件访问可以使用来自这些事件的信号（例如请求的登录风险和位置）来确定访问。 条件访问策略的流将查看会话及其条件，然后将结果馈送到中心策略引擎中。

使用条件访问，通过 Intune 应用保护策略限制对经批准、支持新式身份验证的客户端应用的访问。 对于可能不支持应用保护策略的旧客户端应用，请限制对经批准的客户端应用的访问。

根据属性自动保护应用。 若要更改客户安全属性，请使用云应用程序的动态筛选来添加和删除应用程序策略范围。 使用自定义安全属性以针对未显示在条件访问应用程序选取器中的 Microsoft 第一方应用程序。

使用条件访问身份验证强度控制来指定可访问资源的身份验证方法组合。 例如，可以只使用防钓鱼的身份验证方法来访问敏感资源。

评估条件访问中的自定义控件。 用户重定向到兼容的服务，以满足 Microsoft Entra ID 外部的身份验证要求。 Microsoft Entra ID 会验证响应，如果用户已完成身份验证或验证，该用户将继续留在条件访问流中。 如即将推出的自定义控件更改中所述，合作伙伴提供的身份验证功能可与 Microsoft Entra 管理员和最终用户体验无缝协作。

自定义多重身份验证解决方案

如果使用自定义多重身份验证提供程序，请考虑从多重身份验证服务器迁移到 Microsoft Entra 多重身份验证。 如果需要，请使用多重身份验证服务器迁移实用工具迁移到多重身份验证。 通过帐户锁定阈值、欺诈警报和通知设置来自定义最终用户体验。

了解如何迁移到 Microsoft Entra 多重身份验证和 Microsoft Entra 用户身份验证。 将所有应用程序、多重身份验证服务和用户身份验证移动到 Microsoft Entra ID。

可以启用 Microsoft Entra 多重身份验证，并了解如何为用户组创建条件访问策略、配置提示进行多重身份验证的策略条件，以及测试用户配置和使用多重身份验证。

适用于多重身份验证的网络策略服务器 (NPS) 扩展可以使用服务器将基于云的多重身份验证功能添加到身份验证基础结构。 如果将 Microsoft Entra 多重身份验证与 NPS 配合使用，请确定可迁移到新式协议（如安全断言标记语言 (SAML)）和 OAuth2 的内容。 评估用于远程访问的 Microsoft Entra 应用程序代理，并使用安全混合访问 (SHA) 通过 Microsoft Entra ID 保护旧版应用。

监视登录

使用 Connect Health 集成 AD FS 登录，以关联 AD FS 中的多个事件 ID（具体取决于服务器版本），获取有关请求和错误详情的信息。 Microsoft Entra 登录报告包含有关用户、应用程序和受管理资源何时登录到 Microsoft Entra ID 并访问资源的信息。 此信息与 Microsoft Entra 登录报表架构相关联，并显示在 Microsoft Entra 登录报告用户体验中。 使用报告时，Log Analytics 流提供 AD FS 数据。 使用和修改用于方案分析的 Azure Monitor 工作簿模板。 例如 AD FS 帐户锁定、密码尝试错误，以及意外登录尝试增加。

Microsoft Entra 将所有登录记录到 Azure 租户中，其中包括内部应用程序和资源。 查看登录错误和模式，以深入了解用户访问应用程序和服务的方式。 Microsoft Entra ID 中的登录日志是适合用于分析的活动日志。 根据许可配置最多 30 天数据保留期的日志，并将其导出到 Azure Monitor、Sentinel、Splunk 和其他安全信息和事件管理 (SIEM) 系统。

企业网络声明内部

无论请求出自何处或者访问什么资源，零信任模型都教我们“从不信任，始终验证”。保护所有位置，就像它们位于企业网络之外一样。 将网络内部声明为受信任的位置，以减少标识保护误报。 为所有用户强制实施多重身份验证，并建立基于设备的条件访问策略。

在登录日志上运行查询，以发现从企业网络内部连接但并非 Microsoft Entra ID 混合加入或不符合的用户。 考虑使用合规设备的用户，以及使用没有扩展、不受支持的浏览器（如 Firefox 和 Chrome）的情况。 请改用计算机域和符合性状态。

分阶段身份验证迁移测试和直接转换

若要进行测试，请使用分阶段推出的 Microsoft Entra Connect 云身份验证来控制对组的测试用户的身份验证。 使用 Microsoft Entra 多重身份验证、条件访问和 Microsoft Entra ID 保护等云身份验证功能来选择性地测试用户组。 但是，不要对增量迁移使用分阶段推出。

若要完成迁移到云身份验证，请使用分阶段推出来测试新的登录方法。 将域从联合身份验证转换为托管身份验证。 从测试域或具有最低用户数的域开始。

在非工作时间规划域直接转换，以防需要回滚。 若要规划回滚，请使用当前的联合设置。 请参阅联合设计和部署指南。

包括在回滚过程中将托管域转换为联合域。 使用 New-MgDomainFederationConfiguration cmdlet。 必要时需配置额外的声明规则。 若要确保完成过程，请在直接转换后将回滚分阶段推出保留 24 到 48 小时。 从分阶段推出中删除用户和组，然后将其关闭。

直接转换后，每隔 30 天滚动更新一次密钥以实现无缝 SSO：

Update-AzureADSSOForest -OnPremCredentials $creds -PreserveCustomPermissionsOnDesktopSsoAccount

停用 AD FS

从 AD FS 的 Connect Health 使用情况分析监视 AD FS活动。 首先，启用 AD FS 审核。 在停用 AD FS 场之前，请确保没有 AD FS 活动。 使用 AD FS 停用指南和 AD FS 停用参考。 下面是关键停用步骤的摘要。

  1. 在停用 AD FS 服务器之前进行最终备份。
  2. 从内部和外部负载均衡器中删除 AD FS 条目。
  3. 删除 AD FS 服务器场名称的相应域名服务器 (DNS) 条目。
  4. 在主 AD FS 服务器上，运行 Get-ADFSProperties 并查找 CertificateSharingContainer。

    注意

    在安装即将结束、经过几次重启、域名不再可用时，删除域名 (DN)。

  5. 如果 AD FS 配置数据库使用 SQL Server 数据库实例作为存储区，请将其删除。
  6. 卸载 WAP 服务器。
  7. 卸载 AD FS 服务器。
  8. 从每个服务器存储中删除 AD FS 安全套接字层 (SSL) 证书。
  9. 使用完整磁盘格式重置 AD FS 服务器映像。
  10. 删除 AD FS 帐户。
  11. 使用 Active Directory 服务界面 (ADSI) 编辑以删除 CertificateSharingContainer DN 的内容。

后续步骤