Managing external identities to enable secure access for partners, customers, and other non-employees
There is no publicly documented External ID setting that allows @tfbnw.net Facebook test-user addresses through self-service sign-up, so this case should be escalated to Microsoft as an email-domain classification issue while using pre-created federated users as the temporary review workaround.
The evidence narrows the failure to new-user creation, not Facebook authentication or the Facebook identity-provider configuration:
- Facebook authentication completes.
- Ordinary Facebook accounts create users successfully.
- The same Meta test identity signs in after its federated user object already exists.
- No custom restrictions or authentication extensions are involved.
External ID normally creates a directory user from the identity information collected during social sign-up.^1^ Error 1002015 is not among the specific sign-up errors for which Microsoft publishes remediation, and Microsoft directs unresolved sign-up failures to support.^2^
Temporary workaround for Meta review
Continue pre-provisioning each Meta test user with its Facebook federated identity before the reviewer signs in. External ID then matches the existing account by issuer plus issuerAssignedId instead of attempting a new social sign-up. Microsoft documents this pre-created-account behavior for social-user migration.^3^
Use:
-
signInType:federated -
issuer:facebook.com -
issuerAssignedId: the Facebook app-scoped user ID, not the email address
The issuer and assigned ID combination must be unique in the tenant.^4^
Example identity payload:
{
"identities": [
{
"signInType": "federated",
"issuer": "facebook.com",
"issuerAssignedId": "<facebook-app-scoped-user-id>"
}
]
}
This bypasses self-service account creation; it does not remove the @tfbnw.net rejection for other new test users. Ensure Meta reviews the app using the exact Facebook app whose app-scoped IDs were placed in Entra.
Capture the failing sign-up event
- Reproduce the failure with a newly created Meta test user.
- Record:
- UTC timestamp
- Error
1002015 - Correlation/request ID shown by the error page or logs
- External tenant ID
- User-flow name and application ID
- A redacted screenshot of the message
- In the Microsoft Entra admin center, inspect the sign-up logs for that time and export the failing event. External ID sign-up logs are the documented diagnostic source for isolating account-creation failures.^2^
- Include a comparison event showing that the same user signs in after Graph pre-provisioning. This demonstrates that federation succeeds and that rejection occurs only during account creation.
Do not publish the test user’s email, Facebook identifier, access token, app secret, or tenant identifiers in a public Q&A post.
Escalate to Microsoft
For an external tenant, technical support requests are currently not created directly from that tenant. Use Give Feedback on the New support request page, or switch to the associated Microsoft Entra workforce tenant and open the request there.^5^
Ask support to determine whether tfbnw.net is classified as an enterprise domain by the External ID social-sign-up service and whether that classification can be corrected or exempted for Meta app-review test users. Include the artifacts above and explicitly state:
- Gmail-backed Facebook users can self-register.
-
@tfbnw.netMeta test users fail only on first-time registration. - Pre-creating the identical Facebook federated identity enables sign-in.
- No domain restriction or custom authentication extension is configured.
Reconfiguring Facebook, changing redirect URIs, or using domainless SAML federation is not indicated by these symptoms: the configured Facebook flow already works, and domainless federation applies to custom SAML/WS-Fed providers rather than the built-in Facebook provider.
References