用户通过外部IdP完成SSO后账户仍禁用的原因排查

用户通过外部身份提供商（IdP）完成单点登录（SSO）后，创建的B2C账户显示为禁用状态，即使在AAD-UserWriteUsingAlternativeSecurityId技术配置文件中添加了设置accountEnabled为true的持久化声明，问题依然存在。

相关配置片段：
创建账户的ClaimsExchange：

<ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />

自定义修改的技术配置文件：

<TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId">
  <PersistedClaims>
    <PersistedClaim ClaimTypeReferenceId="accountEnabled" AlwaysUseDefaultValue="true" DefaultValue="true" />
  </PersistedClaims>
</TechnicalProfile>

可能的原因及对应解决办法 #

1. 持久化声明覆盖不全导致原有配置丢失 #

直接重写<PersistedClaims>节点会替换原技术配置文件中的所有持久化声明，而非追加。原AAD-UserWriteUsingAlternativeSecurityId包含alternativeSecurityId、displayName等必要声明，缺失这些会导致用户属性写入异常，进而影响accountEnabled的设置。

解决办法：
继承原技术配置文件并完整包含所有必要的持久化声明，示例：

<TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId-Custom">
  <IncludeTechnicalProfile ReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
  <PersistedClaims>
    <!-- 保留原声明 -->
    <PersistedClaim ClaimTypeReferenceId="alternativeSecurityId" />
    <PersistedClaim ClaimTypeReferenceId="displayName" />
    <PersistedClaim ClaimTypeReferenceId="givenName" />
    <PersistedClaim ClaimTypeReferenceId="surname" />
    <!-- 覆盖accountEnabled设置 -->
    <PersistedClaim ClaimTypeReferenceId="accountEnabled" AlwaysUseDefaultValue="true" DefaultValue="true" />
  </PersistedClaims>
</TechnicalProfile>

同时更新ClaimsExchange引用这个自定义的技术配置文件：

<ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId-Custom" />

2. accountEnabled声明类型未正确定义 #

如果<ClaimTypes>节点中没有定义accountEnabled，或数据类型错误（需为boolean），持久化声明无法正确映射到Azure AD的用户属性。

解决办法：
在<BuildingBlocks>的<ClaimsSchema>中添加或确认声明类型：

<ClaimType Id="accountEnabled">
  <DisplayName>Account Enabled</DisplayName>
  <DataType>boolean</DataType>
  <UserHelpText>Indicates whether the account is enabled.</UserHelpText>
</ClaimType>

3. 用户旅程中存在后续属性修改步骤 #

如果在AADUserWrite之后还有其他修改用户属性的ClaimsExchange或技术配置文件执行，可能会覆盖accountEnabled的值。

解决办法：
检查用户旅程的流程顺序，确保设置accountEnabled的步骤是最后一个修改用户属性的操作，避免后续步骤覆盖该值。

4. 配置生效延迟或旧账户缓存 #

修改B2C策略后可能需要数分钟生效，旧账户的状态也可能因缓存未更新显示异常。

解决办法：
等待5-10分钟后重新测试，或使用一个从未在B2C中登录过的外部IdP账户创建新用户，验证新账户的状态是否正常。

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