AADSTS50020 when Okta “Authenticate with Microsoft Account” for Office 365 provisioning — user doesn’t exist in tenant + custom domain is federated (SourceAnchor error when creating users)

Question

Details I’m integrating Okta → Microsoft 365/Entra ID for sign-in and user provisioning.

What I did

Verified custom domain: PII.com

Configured WS-Federation for the domain using Microsoft Graph PowerShell (New-MgDomainFederationConfiguration). Get-MgDomainFederationConfiguration -DomainId vanguardgovsolutions.com shows the federation config exists.

In Entra, the domain page shows: Verified = Yes, Primary = Yes, Federated = Yes

In Okta, I created user ******@PII.com, created a group, assigned Microsoft 365 app to the group, added user to the group.

In Okta Microsoft Office 365 app → Provisioning, I’m trying to enable API Integration and click Authenticate with Microsoft Account.

Problem When I click “Authenticate with Microsoft Account” in Okta, the Microsoft login fails with:

AADSTS50020: User account ‘******@PII.onmicrosoft.com’ (or PIIl.onmicrosoft.com / ******@gmail.com) does not exist in tenant ‘Vanguard Government Solutions LLC’ and cannot access the application ‘ (Okta Microsoft Graph Client)’ in that tenant. The account needs to be added as an external user in the tenant first.

I also tried signing in with ******@PII.com but it’s a MicrosoftAccount identity and Okta returns “Office 365 Login Failure — account not configured, ask admin to import from Active Directory.”

Related issue When I try to create a new Entra user with UPN PII.com, creation fails: “SourceAnchor is a required property for creation of a federated user.”

What I’m trying to accomplish

Authenticate Okta O365 provisioning API integration successfully

Provision/push Okta users (like PII.com) into Entra and assign licenses

Questions

For the Okta “Authenticate with Microsoft Account” step, which Microsoft account must be used(onmicrosoft.com cloud-only admin vs custom domain user), especially when the custom domain is already federated?

How can I create a break-glass/admin user that can authenticate to the Okta Graph Client if Entra won’t let me create PII.com users due to SourceAnchor?

Is the correct fix to use a cloud-only *.onmicrosoft.com Global Admin that exists in the same tenant and/or change the Okta app’s tenant target?

Any recommended steps to confirm I’m targeting the right tenant (TenantID vs sts.windows.net/<id> in the error)?

Environment

Tenant: “Vanguard Government Solutions LLC”

Domain: vanguardgovsolutions.com

Federation: WS-Fed via Okta

• Okta O365 app provisioning via Microsoft GraphDetails I’m integrating Okta → Microsoft 365/Entra ID for sign-in and user provisioning. What I did
  • Verified custom domain: PII.com
  • Configured WS-Federation for the domain using Microsoft Graph PowerShell (New-MgDomainFederationConfiguration). Get-MgDomainFederationConfiguration -DomainId vanguardgovsolutions.com shows the federation config exists.
  • In Entra, the domain page shows: Verified = Yes, Primary = Yes, Federated = Yes
  • In Okta, I created user PII.com, created a group, assigned Microsoft 365 app to the group, added user to the group.
  • In Okta Microsoft Office 365 app → Provisioning, I’m trying to enable API Integration and click Authenticate with Microsoft Account.
  Problem
  When I click “Authenticate with Microsoft Account” in Okta, the Microsoft login fails with: AADSTS50020: User account ‘PIIonmicrosoft.com’ (or PII.onmicrosoft.com / ******@gmail.com) does not exist in tenant ‘PII’ and cannot access the application  (Okta Microsoft Graph Client)’ in that tenant. The account needs to be added as an external user in the tenant first. I also tried signing in with PIIcom but it’s a MicrosoftAccount identity and Okta returns “Office 365 Login Failure — account not configured, ask admin to import from Active Directory.” Related issue
  When I try to create a new Entra user with UPN PII.com, creation fails:
  “SourceAnchor is a required property for creation of a federated user.” What I’m trying to accomplish
  • Authenticate Okta O365 provisioning API integration successfully
  • Provision/push Okta users (like PII.com) into Entra and assign licenses Questions
  1. For the Okta “Authenticate with Microsoft Account” step, which Microsoft account must be used(onmicrosoft.com cloud-only admin vs custom domain user), especially when the custom domain is already federated?
  2. How can I create a break-glass/admin user that can authenticate to the Okta Graph Client if Entra won’t let me create PII.com users due to SourceAnchor?
  3. Is the correct fix to use a cloud-only *.onmicrosoft.com Global Admin that exists in the same tenant and/or change the Okta app’s tenant target?
  4. Any recommended steps to confirm I’m targeting the right tenant (TenantID vs sts.windows.net/<id> in the error)?
  Environment
  • Tenant: “”
  • Domain: PII.com
  • Federation: Manual WS-Fed via Okta
  • Okta O365 app provisioning via Microsoft Graph

Answer 1

Hello @Rico NY ,

Q: For the Okta “Authenticate with Microsoft Account” step, which Microsoft account must be used(onmicrosoft.com cloud-only admin vs custom domain user), especially when the custom domain is already federated?

A: Use a cloud-only Global Admin account on the tenant's default domain (tenant.onmicrosoft.com) to authenticate the Okta Microsoft Graph Client. This account directly authenticates via EntraID.

Q: How can I create a break-glass/admin user that can authenticate to the Okta Graph Client if Entra won’t let me create PII.com users due to SourceAnchor?

A: Use directly admin@tenant.onmicrosoft.com, rather than the Federated Domain.

Q: Is the correct fix to use a cloud-only *.onmicrosoft.com Global Admin that exists in the same tenant and/or change the Okta app’s tenant target?

A: Yes, correct fix is that. Verify tenant alignment by checking the Tenant ID in Entra admin center > Azure Active Directory > Overview and confirming it matches the tenant targeted by Okta.

Q: Any recommended steps to confirm I’m targeting the right tenant (TenantID vs sts.windows.net/<id> in the error)?
A: To verify the federation configuration, use PowerShell command. Check the IssuerUri field; it should contain your tenant ID in the format: https://sts.windows.net/{tenant-id}/ ... which you can cross-reference with Okta.
Additionally, you can check the endpoint's /.well-known/openid-configuration which should match the output of the previous command.

Do let me know if you have additional questions.

The answer is partly written via Claude 4.6 Opus

Best Regards,