Why Are External IdP Federated Accounts Created as Disabled in Azure AD B2C?

Below is one likely explanation for what you’re seeing:

What’s Happening

Even though you’ve modified your technical profile so that the persisted claim “accountEnabled” is set with a default of “true”, the user is still being created (or left) with a disabled account. This usually happens because:

• Ordering of Technical Profiles:
  When a user signs in with an external IdP, Azure AD B2C uses the alternative security ID flow. In many setups the initial creation (or lookup) of the user is done by a technical profile that creates the new account with a default disabled state. Even though you later “override” the accountEnabled value in your persisted claims, that update may not be applied if the user already exists or if another technical profile later on is mapping the attribute in a different way.

• Read vs. Write Flow:
  If the user already exists (for example, from an earlier login attempt) then the policy might be using a read technical profile. In that case your write technical profile (which has the claim persistence) isn’t being executed and so the account remains in its original disabled state.

• Permissions and Mappings:
  It’s also important to verify that the attribute mapping in your technical profile is actually updating the “accountEnabled” attribute in the Azure AD. Sometimes—even if you set AlwaysUseDefaultValue—the underlying API call might not update the attribute as expected if the mapping isn’t correct or if you’re running into permission issues.

How to Troubleshoot/Fix

1. Review Orchestration Steps:
   Check that the technical profile which creates (or updates) the account is the one being executed for external IdP sign-in. If the account already exists from a prior run as disabled, you may need to add a separate update step to re-enable it.

2. Double‑Check Mappings:
   Ensure that the claim “accountEnabled” in your technical profile is mapped to the correct attribute in your directory. Sometimes slight mismatches in the claim type reference or the attribute name can result in the update being ignored.

3. Examine Policy Flow for Duplicates:
   Make sure there isn’t another part of your custom policy overriding or neglecting to update the accountEnabled attribute (for example, a legacy technical profile that writes the user without the accountEnabled claim).

4. Check API Permissions:
   Verify that the service principal used by your custom policy has permission to update the accountEnabled property, as sometimes the Graph API or Azure AD Graph settings can block such modifications if not properly consented.

Summary

Even though you set a default “true” in the technical profile for “accountEnabled”, the account remains disabled because the user creation/update flow for external identities may be executing in a way that does not actually apply that change (either due to ordering, mapping overrides, or permission issues). Reviewing your orchestration steps and ensuring that the account write technical profile is the one applied (or adding an additional update step if needed) should resolve the issue.

Let me know if you need further assistance with the policy details or debugging steps.