SSO from PingOne to Entra app failing; Not matching on sub value and can't find by email

Question

SSO from PingOne to Entra app failing; Not matching on sub value and can't find by email

Eric Whiteside 0

I am trying to implement SSO from PingOne to my Azure app I have registered in Entra External ID. When I don't have the PingOne account pre-provisioned, the sign-in flow provisions the account but with a bad value for the "Issuer" (the tenant id is incorrectly appended to the end of the issuer URL). This leads to a AADSTS500208 error. If I use Graph API to pre-provision the user with the proper "Issuer" URL, I get a message on the Entra prompt that says "Account Already Exists. Click next to sign in". Clicking Next gives the following error message:
We couldn't find an account with this email address

Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-31T18:26:10.24+00:00
Hello Eric Whiteside,

This behavior points to a mismatch between what PingOne sends and what Entra External ID expects.

When the user isn’t pre-created, Entra provisions the account using the SAML issuer and NameID / sub. In your case, the issuer value is not correct (it looks like an extra tenant ID is appended), which leads to AADSTS500208.

When you pre-create the user with the correct issuer, Entra detects the account. After clicking “Next”, the flow switches to email lookup and fails with “We couldn’t find an account with this email address”, which means the email isn’t set as a valid sign-in identity or doesn’t match the stored user.

To fix this, validate:

The issuer (Entity ID) in PingOne exactly matches the IdP configuration in Entra.

The NameID / sub matches the issuerAssignedId on the user.

The user is created with a federated identity using the same issuer and identifier.

The SAML response contains the expected issuer and NameID values.

For the email error, either ensure the federated identity is matched so email lookup isn’t used, or add the email as a sign-in identity.

Once these values line up, the sign-in flow should work.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-04-02T16:50:16.1233333+00:00

Hello Eric Whiteside,

Any update on this? Please confirm if you still have further queries on this.

1 answer

Your answer

Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-31T18:26:10.24+00:00

Hello Eric Whiteside,

This behavior points to a mismatch between what PingOne sends and what Entra External ID expects.

When the user isn’t pre-created, Entra provisions the account using the SAML issuer and NameID / sub. In your case, the issuer value is not correct (it looks like an extra tenant ID is appended), which leads to AADSTS500208.

When you pre-create the user with the correct issuer, Entra detects the account. After clicking “Next”, the flow switches to email lookup and fails with “We couldn’t find an account with this email address”, which means the email isn’t set as a valid sign-in identity or doesn’t match the stored user.

To fix this, validate:

The issuer (Entity ID) in PingOne exactly matches the IdP configuration in Entra.

The NameID / sub matches the issuerAssignedId on the user.

The user is created with a federated identity using the same issuer and identifier.

The SAML response contains the expected issuer and NameID values.

For the email error, either ensure the federated identity is matched so email lookup isn’t used, or add the email as a sign-in identity.

Once these values line up, the sign-in flow should work.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-04-02T16:50:16.1233333+00:00

Hello Eric Whiteside,

Any update on this? Please confirm if you still have further queries on this.

Answer 1

The behavior indicates that the external identity is not being matched consistently between PingOne and Microsoft Entra ID. There are two separate but related issues:

The subject/issuer pair used as the immutable external identity key is inconsistent (tenant ID appended in one flow but not the other).
The email address being shown on the prompt is not the attribute Entra is actually using to locate the user, so the “account already exists” banner and the “we couldn’t find an account with this email address” error appear together.

To stabilize SSO and matching:

Use a stable external identity attribute for matching
Ensure that the identifier coming from PingOne (typically sub or another unique ID) is mapped to a property that Entra can use consistently to match users. If existing users were created with a different identifier or format, matching will fail. The recommended pattern is:
- Pick a single, stable identifier (for example, a PingOne user ID, employee ID, or a stable email/UPN) that exists both in PingOne and in Entra.
- Store that value on all users in the application or in Entra, and include it in the matching rule so that the same value is used every time.
The documented approach for this type of mismatch is:
- Select or add a property in the application’s user schema.
- Populate that property on all users with a value that is already present on users in Entra (for example, email or employee ID).
- Update the Entra provisioning attribute-mappings configuration so that this property is included in the matching rule.
This prevents the situation where Entra provisions a new user with one issuer/subject combination, but later sign-ins present a different combination (for example, issuer URL with tenant ID appended), which Entra treats as a different external identity.
Align matching when email and UPN differ
If PingOne is sending an email address that does not match the user’s userPrincipalName in Entra, and the matching rule is based on userPrincipalName, Entra will not find the account even though the email looks correct on the prompt. In that case either:
- Add a property on the application user to hold the Entra userPrincipalName and populate it for all users, then use that property in the matching rule; or
- Change the matching rule to use a property that actually holds the email address being sent by PingOne.
This is the documented fix when the application stores email while Entra is matching on userPrincipalName.
Clean up and re-provision if necessary
Because some users were provisioned with an incorrect issuer value (tenant ID appended), those objects may now be “orphaned” relative to the corrected configuration. After aligning the identifier and matching rules as above, it may be necessary to:
- Remove the incorrectly provisioned external user objects, and
- Let them be re-provisioned via the corrected PingOne SSO flow or via Graph with the same stable identifier that PingOne will send at sign-in.

Once the same stable identifier is used in PingOne, in the Entra user object, and in the provisioning/matching rules, Entra will stop creating mismatched identities, and the “account already exists / couldn’t find an account with this email address” combination will no longer occur.

References:

Manage mappings and users in applications that did not match to users in Microsoft Entra ID