现代企业正承受着越来越大的压力，通过现代化标识管理和简化运营来提高安全性。 本文档提供了一个战略和技术框架，使 IT 架构师能够使用权威来源（SOA）转换，将用户和组管理从本地 Active Directory（AD）转移到 Microsoft Entra ID。 旧版 AD 环境可能非常复杂、成本高昂，而且如果不保持最新状态，则越来越容易受到新式威胁的影响。 Microsoft的目标是通过允许混合客户为标识管理建立Microsoft Entra ID 来提供保护混合客户的选项。 转移 SOA 可实现分阶段、低风险的迁移路径，避免“大爆炸”式的直接转换引起的中断。
本指南为 IT 架构师提供了云优先标识管理的全面概述。 其中介绍了迁移到基于云的标识的业务和安全优势，概述了从混合环境过渡到云优先状态和 AD 最小化状态的分阶段路线图，并介绍了如何评估用户和组 SOA 传输的准备情况。 本指南还详细介绍了尚未准备好完全转移的组织以应用为中心的方法，涵盖了 Kerberos 和基于 LDAP 的应用程序的集成策略，重点介绍了混合共存的关键限制和注意事项，并提供一个实际清单，用于在整个迁移过程中支持规划、执行和治理。
业务和安全优势
长期以来，Active Directory 一直被视为组织的“王国的关键”，如果遭到入侵，则成为攻击者的有吸引力的目标。 通过迁移应用程序身份验证以使用 Microsoft Entra ID，减少对 AD 的依赖，从而提高受条件访问和 MFA 保护的用户的安全性。 将标识和身份验证迁移到 Microsoft Entra ID 还会解锁新式功能，例如条件访问策略、无密码身份验证以及用户和应用程序的高级标识治理，包括最初托管在本地的标识管理。 从本质上讲，Microsoft Entra ID 中的集中管理增强了组织的整体安全态势。
提高 IT 效率和用户体验
云优先方法可通过以下方式帮助提高组织中的 IT 效率和用户体验：
IT 管理员可以通过 Microsoft Entra ID 的管理中心和 Microsoft Graph API 来管理用户标识、组和联合或预配的应用程序访问策略。
Microsoft Entra ID 治理功能（如权利管理、访问评审和生命周期工作流）简化了依赖于以前在 AD 中管理的组的应用的治理。 这引入了自动化，有助于贯穿整个身份生命周期的合规性。
用户可以通过现代访问控制（例如基于风险的条件访问策略）在云和本地应用程序中获得跨应用的单一登录的好处。 迁移后，员工可以使用其Microsoft Entra ID 凭据（如无钓鱼密码方法）无缝访问旧 Intranet 应用程序。 减少了对管理多个 AD 密码的需求，并缓解了凭据扩散的问题。
云身份路线图：从混合到云优先/AD最小化状态
组织通常通过“通往云的道路”的不同阶段前进，从 混合 方法开始，该方法包括在其环境中同时使用云和本地 AD。 随后是 云优先 阶段，其中资源越来越多地转移到云。 下一阶段组织实现的是 AD 最小化 状态。 用户、组和联系人的服务导向架构（SOA）传输通过允许将身份逐步迁移到 Microsoft Entra ID 来促进这一过程。 SOA 支持一种分阶段的方法，而不是一次性停用 AD，这会需要对许多应用程序进行重写或迁移到新平台。 使用此方法，组织可以立即将合适的标识迁移到云，并随着时间的推移逐渐减少其 AD 占用量。
注释
在启动 SOA 传输之前，始终先从应用程序清单开始。 这有助于维护绑定到旧版 AD 应用的用户的访问权限。
可以解锁的场景
最大程度地减少 AD 中不再需要的用户和组的 AD 占用空间
过渡到云服务和新式应用程序后，某些 AD 帐户和组可能会过时。 如今，这些用户和组仍通过传统标识管理解决方案（如 MIM）在 AD 中创建。 这样做是因为在云中手动创建这些对象是一项密集的手动工作。 在开始确定您想为谁转移 SOA 时，您可以决定不考虑这些用户和组的 AD。 这使你能够将它们从 AD 和 Microsoft Entra 中删除；或者，如果它们仅在 Microsoft Entra 中是必须的，则可以在单独从 AD 删除之前转移其 SOA（面向服务的架构）。 这种有针对性的转换使组织能够自动执行迁移，并监视其进度，同时最大程度地减少运营中断。 有关详细信息，请参阅： 使用 Microsoft Entra ID Governance 最大程度地减少 AD 用户和治理用户生命周期。
将生命周期管理转移到云
可以使用 Microsoft Entra ID Governance 启用从云中由 SOA 转移的用户和组的生命周期和访问治理。 对于用户，这意味着你现在直接将用户预配到 Microsoft Entra ID 中，并且可以使用 Microsoft Entra 的 ID 治理功能来管理这些用户。 对于组，你可以对组进行现代化改造，并启用从云绑定到这些组的应用的访问治理。 在这里需要注意的是，像 Mail-Enabled 安全组（MESG）和通讯组列表（DLs）这样的 Exchange 构造组需要在云中管理之前进行现代化改造。 有关详细信息，请参阅 组 SOA 指南。
SOA 是否适合你？
下图概述了是否已准备好转移用户和组的授权源（SOA）：
注意事项
用户： SOA 适用于没有链接到 AD DS 的任何应用程序依赖项的用户。 确定与特定应用程序关联的用户对于有效迁移规划至关重要。
组： 对于组，建议首先将安全组转移到云。 当资源在云中后，可根据需要从 Microsoft Entra ID 重新预配到 AD。 对于通讯组列表（DLS）和 Mail-Enabled 安全组（MESG），建议在所有 Exchange 工作负荷都位于云中后将其转移，不再需要本地 Exchange 服务器。
Application-Centric 方法：实现本地身份验证的现代化
本部分概述了 AD 密集型环境的主要云迁移策略，称为以应用程序为中心的方法。 此方法使本地应用程序能够利用 Microsoft Entra ID 进行标识管理。 本部分还包括解决旧应用程序密码同步等难题的详细步骤、先决条件和指南。 以应用程序为中心的方法适用于已经深入无密码旅程的客户。 对于需要密码的应用，目前没有将用户转移到云的路径。
以应用程序为中心的方法从应用程序的角度处理云迁移。 在此方法中，通过应用以下框架来尝试实现应用身份验证的现代化：
清单应用程序： 列出使用 AD 进行身份验证的所有本地应用（Kerberos/NTLM 或 LDAP）。
集成目标： 将每个应用重新配置为使用 Microsoft Entra ID 进行身份验证，从而减少对本地 AD 的依赖。
桥接解决方案： 使用 Microsoft Entra 应用程序代理、Microsoft Entra 域服务或其他云服务，在不进行重大重写的情况下将旧版应用连接到 Microsoft Entra ID。
针对以应用程序为中心的迁移的建议顺序
还可以通过 Active Directory 联合身份验证服务（AD FS）或第三方 IdP 等新式协议（例如 SAML/OIDC）使用某些应用。 这些应用更易于直接迁移到 Microsoft Entra，而其他一些旧案例（如仅硬编码的 NTLM 应用）可能需要特殊处理。
应用程序清单和身份验证分析
在规划迁移之前 ，发现和分类所有本地应用程序 至关重要。 目标是为每个应用确定： 它当前如何对用户进行身份验证，以及 将身份验证与 Microsoft Entra ID 集成或现代化的最佳路径是什么？
彻底的应用程序分析构成了在 AD 密集型环境中成功迁移到基于云的标识管理的基础。 此过程涉及有条不紊地评估依赖于 Active Directory 进行身份验证的每个应用程序，确定每个应用程序如何对用户进行身份验证，并映射符合每个应用程序的独特要求的现代化或集成计划。 对于以应用为中心的迁移，建议执行以下步骤：
步骤 1. 编录 Active Directory 集成应用程序
通过标识使用 AD 进行身份验证或授权的所有应用程序来开始迁移。 了解其依赖项以计划迁移到云标识管理，并指出哪些 AD 组和用户帐户与每个应用程序连接。 这有助于确定用户和组首先转换的优先级，尤其是那些链接到业务关键应用的用户和组。
发现 Active Directory 集成应用程序
使用 Microsoft Entra Global Secure Access Application Discovery 和 AD 域控制器日志等工具来确定员工访问的应用，以及这些应用与 AD 的交互方式。 使用按用户计数排序并按单个用户活动筛选的仪表板确定高使用率应用程序优先级。
将应用程序映射到 AD 安全组
对于找到的每个应用，请标识控制其访问权限的 AD 安全组。 与所有者协作，或查看配置以列出这些组。 如有必要，请使用脚本或 AD 查询来查找相关组，尤其是在组名称或说明引用应用时。 有关标识安全组的详细信息，请参阅： 清理单个域中未使用的 Active Directory 域服务组。
标识每个应用程序的用户
通过提取每个应用程序的 AD 组的组成员身份和分析实际使用情况数据来确定用户。 合并成员身份列表和使用情况日志，为每个应用创建一个明确的用户列表。 使用此信息来指导云迁移规划，确保在整个过程中维护访问权限。
步骤 2. 确定身份验证方法
对于清单中的每个应用程序，请标识它使用的身份验证机制。 此步骤对于选择最合适的迁移或集成策略至关重要。 要考虑的主要类别包括：
集成 Windows 身份验证 （Kerberos/NTLM） - 使用 Windows 身份验证、文件服务器、SharePoint 和类似平台的 IIS/.NET 应用程序中很常见。 这些通常允许用户使用域凭据登录，通常无需单独的提示。
LDAP 身份验证/查询 – 应用程序可以具有 指向 AD 的 LDAP 服务器设置 ，并执行绑定或查找、自定义开发或第三方产品，提示用户输入 AD 凭据。
联合/新式身份验证 – 某些应用程序已通过 AD FS 联合，或支持新式协议，例如 SAML 或 OAuth。 通常可以通过简单的重新配置来使用 Microsoft Entra ID。
其他旧方法 - 包括应用对 AD 或本地帐户使用 RADIUS 的情况。 尽管不是主要焦点，但为了完整性，还是应当记录这些内容。 有关详细信息，请参阅： 使用 Microsoft Entra ID 进行 RADIUS 身份验证。
步骤 3. 评估现代化可行性
评估每个应用程序原生采用现代身份验证协议（SAML/OIDC）的能力。 如果有供应商更新可用，或者如果应用是在内部开发并且可以重新编码的，那么转换为 Microsoft Entra ID 作为身份提供者通常是长期来看最佳的解决方案。 此方法删除 AD 依赖项并解锁云标识管理的全部优势。 但是，对于无法轻松更新的较旧应用程序，请规划一个“bridge”解决方案，以便将它们与 Microsoft Entra ID 集成，即使需要间接集成也是如此。
某些较旧的应用程序可能对 AD 进行了硬编码的假设，例如预期在特定 OU 中找到用户，或将属性写入 AD。 这些应用不在此类标识迁移的范围之内。 Microsoft Entra ID 或 Microsoft Entra 域服务难以轻松支持这些应用程序，除非你保留写入权限，这虽然可以实现，但随后会导致数据不一致。 请确保识别任何应用是否执行 LDAP 写入操作或依赖于鲜为人知的 AD 功能，例如动态辅助类。 这些用户可能必须保留在 AD 上，直到他们退休。 如所述，重点是通过 AD 读取/身份验证 的应用程序，因为这些应用程序可以迁移到云端身份验证。
步骤 4. 对应用程序和计划集成方法进行分类
确定身份验证方法和现代化可行性后，将应用程序分组为不同的类别，以指导集成计划：
尽量减少需要管理的应用数量： 对于计划在目标日期淘汰的应用，可以将这些应用视为不在管理范围内，并且绑定到这些应用的任何用户/组的任何管理都可以转移到云中。 对于冗余的应用，合并应用并确定它是否可以现代化。
已使用或能够进行新式身份验证的应用： 可以将这些 ID 直接迁移到标识提供者Microsoft Entra ID，例如将 AD FS 应用程序更新为指向Microsoft Entra ID 或将文件移动到 Azure 文件共享。 虽然不是中心焦点，但解决这些问题可减少整体旧依赖项。 绑定到这些应用的用户/组的任何管理都可以转移到云中。
Kerberos/NTLM 应用（不容易现代化）： 通过应用程序代理或类似解决方案使用 Microsoft Entra 作为前端。 应用程序保留在本地，但用户身份验证会切换到 Microsoft Entra ID 令牌，这些令牌将转换为 AD 中的 Kerberos 票证。
LDAP绑定应用： 在 Azure 中引入受管理的 AD 实例，特别是 Microsoft Entra 域服务，允许这些应用绑定到云托管 AD 而不是本地环境。
其他特殊情况： 对于无法更改或代理的应用程序（例如限制为已加入 AD 的计算机的较旧客户端服务器应用），请考虑将它们托管在 VDI 解决方案（如 Azure 虚拟桌面、Windows 365 云电脑等）上。 这为这些应用程序维护托管环境，同时在其他地方支持云迁移。 这应该是最后的手段，因为增加了复杂性和成本。
离线应用：对于有业务需求在没有网路连接或断开连接的环境中工作的应用，需要部署在本地。 使用这些应用的用户不符合转移 SOA 的条件。
步骤 5. 地图和计划
通过结束分析阶段，应明确映射哪些应用程序属于“Kerberos 类别”、“LDAP 类别”或其他存储桶，以及每个应用程序都需要的特定集成机制。 此规划步骤至关重要，因为每个应用程序都具有在选择迁移策略之前必须仔细考虑的独特特征。 Microsoft Entra ID 幸运的是为大多数基于 AD 的身份验证模式提供了解决方案，即使是无法修改的旧版应用程序也可以受益于安全的混合访问和新式治理。
步骤 6. 将组迁移到云
在以应用为中心的方法中，最好先将安全组和应用访问控制迁移到云。 这可实现集中式访问管理，并确保在移动用户之前组成员身份保持不变。 Microsoft建议在用户之前转移组的 SOA，以保持成员身份完整性并允许测试。 还可以调整每个应用的顺序，例如使用其组对应用程序进行试点，以及测试用户端到端。 迁移到云时，我们概述了有关如何将它们映射到云组的具体指导，如 Microsoft Entra ID（预览版）中使用组的权威源（SOA）的指南 中所述，或观看以下视频：
小窍门
首先将安全组迁移到云。 此功能允许你在移动用户之前测试应用的访问控制功能。
步骤 7. 处理基于 LDAP 的应用程序（Directory-Bound 应用）
LDAP 绑定的应用程序 或服务直接通过 LDAP 查询 Active Directory 域服务（AD DS），通常是使用简单绑定用户名和密码进行身份验证，或者用于目录读取。 常见示例包括旧版企业应用程序、网络设备或依赖于 LDAP 绑定来验证凭据的自定义开发应用。 这些应用程序通常需要 LDAP 服务器，并且无法轻松转换为新式身份验证协议。 有关详细信息，请参阅： 使用 Microsoft Entra ID 进行 LDAP 身份验证。
建议的解决方案：Microsoft Entra 域服务
在云中支持 LDAP 绑定应用的建议解决方案是Microsoft Entra 域服务。 托管在 Azure 上，Microsoft Entra 域服务提供 LDAP、Kerberos 和 NTLM 端点，并同步来自 Microsoft Entra ID 租户的用户帐户和凭据。 这样，旧应用程序就可以使用云托管 AD 进行身份验证，而无需切换到新式协议。 托管域主要支持 LDAP 客户端的读取和身份验证。 有关详细信息，请参阅： 什么是Microsoft Entra 域服务？
步骤 8。 处理基于 Kerberos 的应用程序（Windows 集成身份验证）
基于 Kerberos 的应用 通常包括使用 Windows 身份验证、依赖于 Kerberos 票证的文件服务器（SMB）的内部 Web 应用程序，以及需要 Active Directory （AD） 登录的其他服务。 Microsoft提供了中间解决方案，用于将这些应用程序与 Microsoft Entra ID 集成。
使用 Kerberos 约束委派进行 Microsoft Entra 应用程序代理或专用访问（KCD）：
建议的解决方案：
Microsoft Entra 应用程序代理或专用访问与 Kerberos 约束委派（KCD）： 此云服务允许通过 Microsoft Entra ID 发布本地 Web 应用程序。 用户向 Microsoft Entra ID 进行身份验证，例如使用 OAuth/OpenID Connect，而本地运行的应用程序代理连接器使用 KCD 代表用户获取后端应用程序的 Kerberos 票证。 Microsoft Entra ID 作为身份验证网关，将身份验证转换为应用程序专用的 Kerberos。 此解决方案支持基于 Web 的应用程序（HTTP/HTTPS），并且可以为云托管用户提供单一登录（SSO）， 前提是这些用户在 AD 中有一个帐户。 有关详细信息，请参阅： Microsoft Entra 应用程序代理 和 Microsoft Entra Private Access
使用云 Kerberos 信任的无密码： 当用户使用无密码身份验证（例如 Windows Hello 企业版和 FIDO2）通过 Microsoft Entra ID 凭据登录时，此方法允许Microsoft Entra ID 颁发本地 AD 资源的 Kerberos 票证。 它要求将 AD 域配置为信任 Microsoft Entra ID 的云 Kerberos 服务，并确保用户的 AD 对象具有必要的密钥。 此过程完全无密码，因此非常适合云用户访问本地资源。 有关更多信息，请参阅：Kerberos 云信任。
迁移 Kerberos 工作负载之前的重要注意事项
在转移与 Kerberos 应用程序相关的用户和组工作负荷之前，以下是一些关键考虑因素：
用户生命周期管理： 即使将用户转换为云管理，具有匹配 UserPrincipalName 的 AD 帐户也必须保留用于 Kerberos 功能。
身份验证和属性： 不要迁移需要访问依赖于密码进行身份验证的应用程序的用户，并且无法更新为使用 Kerberos 身份验证。 需要同步 Active Directory 中的属性并支持 Kerberos 身份验证和属性查询的应用程序可能需要对 Microsoft Entra ID 和 Active Directory 进行双写入。
加入 Microsoft Entra ID 的设备： 要实现真正的单一登录，访问 Kerberos 资源的设备应加入 Microsoft Entra ID 或混合加入。 当用户使用 Microsoft Entra ID 凭据登录到设备时，设备可以从Microsoft Entra ID 获取令牌，该 ID 可通过信任或连接器转换为 Kerberos 票证。 如果设备仅加入企业域，并且用户是云管理的，则无缝 SSO 可能会很困难，可能需要手动输入凭据。 Microsoft建议在云转型过程中将设备迁移到具有云信任的 Microsoft Entra ID 联接，以便用户和设备的信任保持一致。
注释
设备迁移超出了传输 SOA 的当前范围。
本地应用的条件访问： 为应用程序部署应用代理或Microsoft Entra Private Access 后，可以在应用程序访问上强制实施条件访问策略（例如 MFA），因为身份验证通过 Microsoft Entra ID。 这增强了安全性，因为即使旧版应用也受益于零信任条件，而无需修改。 对于 Kerberos 信任方案，条件访问在用户最初对设备上的 Microsoft Entra ID 进行身份验证时适用。
步骤 9. 验证和优化
全面测试每个集成应用程序。 确保现有 AD 源用户可以通过新方法访问应用程序。 确保通过组预配过程将来自 Microsoft Entra ID 的组成员身份得到认可到 AD。 监视性能和登录日志。 优化用于生产的任何设置。
确保转移了其授权来源的所有用户仍能够访问应用程序。 确保 AD 中存在的组成员身份也存在于 Microsoft Entra ID 中。 使用 组日志 和 用户日志 验证是否已成功传输颁发机构源。
结论
下表汇总了用于在云优先模型中处理本地应用的选项：
| 应用类型 | 云集成方法与工具 | 要求和注意事项 |
|---|---|---|
|
基于 Kerberos 的应用 （Windows 集成身份验证、Intranet Web 应用、文件共享） |
使用 Kerberos Microsoft Entra ID 应用程序代理（KCD）： 通过 Microsoft Entra ID 发布本地 Web 应用，并使用本地 Kerberos 连接器。 Microsoft Entra ID 云 Kerberos 信任： 对于已加入 Microsoft Entra ID 的设备（非 Web，例如文件共享）。 |
要求： - 在本地部署的 Microsoft Entra Private Access - 配置的 SPN 和委派权限 - Entra ID P1/P2 或 Suite 许可证 - 用户的 AD 帐户（已同步或预配） Considerations: - 使用 Entra ID 凭据提供无缝 SSO，或为基于 Kerberos 的应用提供无密码，并使用防钓鱼方法来保护和访问本地资源 |
|
基于 LDAP 的应用 （通过 LDAP 绑定到 AD DS 的应用进行身份验证/查询） |
Entra ID 域服务（托管 AD）： 与 Microsoft ID 同步的云托管 AD 域;将应用的 LDAP 连接重新指向此域（LDAPS）。 |
要求： - 在 Azure 中设置 Microsoft Entra 域服务实例 - 配置虚拟网络、安全 LDAP 证书、防火墙规则 - 用户/组必须位于 Microsoft Entra ID 中（已同步到 Microsoft Entra 域服务） - 可能需要密码重置才能生成哈希 Considerations: - 最小的应用更改（只是新的 LDAP 终结点） - Microsoft Entra ID DS 中存在的云用户密码 - 如果Microsoft Entra 域服务不可行，则备选方案为将用户预配到本地 AD 并手动维护密码一致性。 |
面向 IT 架构师的 SOA 传输清单
了解战略优势
通过最小化本地 AD 依赖项来降低安全风险。
启用新式标识功能（条件访问、无密码、零信任）。
简化Microsoft Entra ID 中的标识管理和治理。
评估就绪情况
清点所有用户、组和应用程序。
确定不再与依赖 AD 的应用程序绑定的用户/组。
映射每个应用程序的身份验证依赖项（Kerberos、LDAP、SAML/OIDC）。
计划组迁移
将安全组迁移到云端; 如有需要，从 Microsoft Entra ID 将其重新预配回 AD。
只有在 Exchange 工作负载完全采用云技术后，才能转移 DLs 和 MESGs。
现代化应用程序身份验证
对于 Kerberos/NTLM 应用程序：
云端 Kerberos 信任对于 LDAP 应用：
LDAP 概述对于新式/联合应用：
重新配置以针对 Microsoft Entra ID（SAML/OIDC）直接进行身份验证。
启用无密码身份验证
部署 Hello 企业版
与 云 kerberos 信任 集成，实现无缝基于票证的身份验证。
实现 Entra ID 治理
解决关键限制
云用户不支持密码回写。 如果需要写回，请保留混合目录
具有硬编码 AD 依赖项的旧应用可能需要自定义代理或保留在本地。
监视和迭代
跟踪迁移进度：用户/组已转换，应用现代化。
持续查看安全状况和合规性。
小窍门
始终从以应用为中心的分析开始，以避免用户无法访问与传统 AD 应用程序绑定的资源。 使用分阶段迁移以避免“大爆炸式迁移”。