Azure AD B2C JIT迁移后获取强身份验证设备失败排查

该故障的典型特征已经指向核心诱因：Azure AD B2C目录采用多区域最终一致性模型，你通过迁移接口创建完用户后立刻进入后续登录流程，用户关联的强认证方法元数据尚未完成全节点同步，导致TOTP流程查询可用强认证设备时命中未同步完成的副本，抛出内部服务错误。这也能解释为什么重试登录就正常、非首次登录无异常——重试时用户对象已经完成全节点同步。

可按以下步骤排查定位：

• 配置自定义策略全链路日志
  为自定义策略接入Application Insights追踪，开启详细日志模式，记录登录流程中每个技术配置文件（TechnicalProfile）的执行时序、传入传出声明、异常详情。重点核对迁移接口执行完成到触发强认证设备查询步骤的时间间隔，以及该查询步骤返回的具体底层错误信息，确认是否存在用户对象/强认证属性不存在的报错。
• 做延迟对照测试验证根因
  临时将迁移API中创建用户后的固定等待时长调整为15秒，批量执行至少50次首次迁移登录测试，如果故障完全消失，即可100%确认是目录复制延迟导致的问题。你当前参考示例写的数秒等待时长在跨区域副本同步压力大时很容易不够用。
• 核查用户创建时的属性配置
  拉取迁移API创建B2C用户时的请求内容，检查是否错误配置了和强认证相关的属性：比如误给新迁移用户打上了“已注册强认证方法”的标记、写入了无效的TOTP方法关联ID，导致后续查询强认证设备时匹配到不存在的关联数据报错。
• 通过请求ID拉取后台错误详情
  提取故障时段审计日志中对应请求的关联ID（Correlation ID），提交Azure支持工单查询后台服务的错误栈，确认强认证设备查询接口的具体失败原因，排除目录服务本身的偶发故障。

对应的修复优化方向：

• 替换固定等待为主动校验逻辑
  移除迁移API中写死的等待逻辑，改为创建用户后循环调用目录接口查询该用户的对象状态、强认证方法节点状态，直到确认对象完整可访问后再向B2C返回响应，相比固定等待既不会出现等待时长不足的问题，也不会拉长正常流程的响应时间。
• 调整迁移流程的执行时序
  不要把用户创建逻辑放在登录页的校验技术配置文件（ValidationTechnicalProfile）中同步执行，可以调整为：迁移接口校验密码通过后返回“待迁移”声明，经声明转换跳转到轻量的迁移过渡页，页面停留3~5秒（或主动轮询迁移完成状态）后再继续后续登录、TOTP校验流程，给目录同步留出缓冲时间。
• 给强认证查询步骤增加重试逻辑
  为查询可用强认证设备的技术配置文件配置重试策略，设置查询失败后间隔2秒重试2~3次，自动覆盖偶发的同步延迟场景，不需要用户手动返回重试。
• 优化TOTP流程的前置判断
  调整TOTP策略的执行逻辑：查询用户已有强认证设备前先判断用户是否完成过TOTP注册，刚完成迁移的新用户不存在已注册的TOTP方法时，直接跳转到TOTP注册流程，跳过现有设备查询步骤，从逻辑上规避刚创建用户时的查询报错。

你当前的自定义策略配置中，迁移接口和非交互式登录的执行顺序本身没有问题，核心问题出在新建用户后的同步延迟上，不需要调整这部分的顺序配置。相关配置参考如下：

<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
  <Metadata>
    <Item Key="setting.showSignupLink">false</Item>
  </Metadata>
    <ValidationTechnicalProfiles>
      <ValidationTechnicalProfile ReferenceId="REST-UserMigration-LocalAccount-SignIn" ContinueOnError="false" />
      <ValidationTechnicalProfile ReferenceId="login-NonInteractive" />
    </ValidationTechnicalProfiles>
</TechnicalProfile>

内容的提问来源于stack exchange，提问作者Nait