请求分享从OKTA迁移至Azure AD的实践经验

我刚帮几家企业完成了从Okta到Azure AD的全场景迁移，结合你提到的客户需求（SSO覆盖内外应用、SCIM用户管理、Radius+MFA用于VPN/DevOps服务器），给你梳理下实操中最实用的经验和避坑指南：

• 先做全资产盘点：把所有依赖Okta的应用列成清单，区分SaaS应用（如Salesforce、Zoom）、内部自定义应用、Radius关联的VPN/服务器，标注每个应用的认证协议（SAML 2.0/OIDC/SCIM）、用户同步规则、MFA强制要求，别漏了DevOps团队常用的小众工具。
• 提前对齐功能差异：Okta的部分细粒度配置（比如基于用户属性的动态应用分配）在Azure AD里要靠条件访问或自定义角色替代，提前做适配方案，避免迁移时卡壳。
• 拉跨职能团队：IT运维、DevOps、应用管理员必须一起参与，DevOps的Linux服务器场景很容易被忽略，得提前沟通需求。

• SCIM用户同步迁移：大部分支持Okta SCIM的SaaS应用都兼容Azure AD，步骤很清晰：
  1. 在Azure AD中添加对应应用，开启SCIM同步，拿到Azure的SCIM端点和认证令牌。
  2. 登录SaaS应用，把SCIM数据源从Okta切换到Azure AD，替换配置信息。
  3. 先做增量测试：选一个测试群组同步，验证用户创建、群组添加、属性映射是否和Okta一致，没问题再全量同步。
• SSO认证切换：
  • SAML应用：在Azure AD中配置SAML断言时，务必匹配Okta原来的属性规则（比如NameID格式、自定义字段映射），然后在SaaS应用的身份提供商设置里切换到Azure AD的SAML元数据。建议先开并行模式（用户可选择Okta或Azure AD登录），稳定后再切断Okta。
  • OIDC应用：Azure AD的OIDC配置更标准化，直接更新应用的授权端点、客户端ID/密钥，测试登录流程即可，踩坑概率很低。
• 应用权限分配：用Azure AD的动态群组替代Okta的规则分配，比如基于用户部门、职位自动分配应用权限，减少后续手动维护成本。

这是迁移中的核心难点，分享两种经过验证的方案：

• 方案1：Azure AD NPS扩展（兼容原有Radius架构）
  适合不想大改现有VPN/服务器配置的场景：
  1. 部署NPS（网络策略服务器）在本地或Azure VM，安装Azure AD NPS扩展并关联到租户。
  2. 在NPS中配置Radius客户端（VPN设备、Linux服务器），创建认证策略并启用Azure AD MFA。
  3. 替换Linux服务器上的Radius客户端配置（比如修改/etc/pam.d/radius文件），指向新的NPS服务器。
  4. 测试验证：用Linux用户登录，确认是否触发Azure AD MFA（短信、Microsoft Authenticator app均可）。
• 方案2：Azure AD Passwordless + SSH证书（DevOps最优解）
  彻底替代Radius+MFA，更安全且运维更简单：
  1. 在Azure AD中启用SSH证书颁发功能，为DevOps用户配置证书权限。
  2. 在Linux服务器上配置SSHD服务，接受Azure AD颁发的SSH证书，同时禁用密码登录。
  3. 用户通过Microsoft Authenticator app获取SSH证书，直接登录服务器，无需二次MFA验证（证书已绑定身份）。
     我们的客户DevOps团队反馈这个方案比Radius更流畅，还避免了Radius代理的单点故障。

• 用户同步：如果用户源是本地AD，直接用Azure AD Connect同步，确保用户属性（邮箱、部门等）和Okta一致；如果是Okta本地用户，用Azure AD的批量导入工具或Graph API批量创建，注意保留用户的唯一标识（比如UPN）。
• MFA方法迁移：Azure AD不支持直接导入Okta的MFA设备，我们的做法是提前2周通知用户通过Azure AD MFA自助注册门户完成设备绑定，迁移过渡期间允许用户用Okta或Azure AD的MFA登录，避免影响业务。
• 群组迁移：用Azure AD的批量群组导入工具或Graph API同步Okta群组，尽量保持群组名称/ID一致，避免应用分配混乱。

• 并行运行阶段：建议至少留2周并行期，用户可选择Okta或Azure AD登录应用，IT团队实时监控两种认证方式的日志，快速解决异常问题。
• 逐步切断Okta：先从非核心应用开始切换，再到核心业务应用，最后切断Radius关联，降低风险。
• 回滚预案：提前保存Okta的所有配置备份，如果迁移中出现严重问题，立即切换回Okta的SSO配置、恢复Radius代理指向Okta，确保业务不中断。

• 属性映射不一致：比如Okta中的userPrincipalName格式和Azure AD不同，会导致SCIM同步失败，一定要提前核对所有应用的属性映射规则。
• MFA注册率低：提前做用户培训（比如线上直播教程、一对一支持），否则迁移后大量用户无法登录，影响业务。
• Linux服务器PAM配置：部分老版本Linux的PAM模块不兼容新的Radius服务器，要么升级PAM包，要么直接用SSH证书方案替代。
• 日志监控：迁移期间务必开启Azure AD的登录日志和审计日志，实时排查登录失败、同步错误的问题。

内容的提问来源于stack exchange，提问作者A de Koning