OnPasswordSubmit JIT migration listener configured per docs, extension never invoked (AADSTS50000 with no auth-events SP sign-in log)

Question

OnPasswordSubmit JIT migration listener configured per docs, extension never invoked (AADSTS50000 with no auth-events SP sign-in log)

Abir 0

Summary

JIT password migration via OnPasswordSubmit in a Microsoft Entra

External ID tenant. Resources configured per

https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-migrate-passwords-just-in-time.

All resources confirmed registered. At sign-in time, the extension is

never invoked — Microsoft errors at the password authentication step

with AADSTS50000 and produces no sign-in log entry for the

auth-events service principal

Environment

Tenant: External ID (CIAM) — workforce + consumer surfaces both present
- requestedAccessTokenVersion: 2 on the resource app
- Sign-in flow type: externalUsersSelfServiceSignUpEventsFlow
- Custom auth extension app reg: appId 5b89f114-… (redacted in production), signInAudience: AzureADMyOrg, identifierUris include the FQDN form matching the extension targetUrl
- RSA usage=Encrypt certificate registered on the app reg
- Client app triggering JIT: a separate web app reg (admin SSO)

What's wired up

Custom auth extension of type #microsoft.graph.onPasswordSubmitCustomExtension with azureAdTokenAuthentication, resourceId matches api://<fqdn>/<appId>
Listener of type #microsoft.graph.onPasswordSubmitListener, handler onPasswordMigrationCustomExtensionHandler, migrationPropertyId = extension_<appIdNoDashes>_toBeMigrated, conditions reference the client app's appId
Directory extension property toBeMigrated (Boolean) defined on the extension app
Test user has extension_<…>_toBeMigrated = true (verified via Graph GET)
Role wiring:
- Extension app's service principal holds CustomAuthenticationExtensions.Receive.Payload (214e810f-…) on Microsoft Graph
- Microsoft auth-events SP (99045fe1-7639-4a75-9d4a-577b6ca3810f) holds a custom CustomAuthenticationExtension (Application) role exposed on the extension app

Failure pattern

User clicks "Sign in with Microsoft"
CIAM hosted page shows; user enters email/password
Sign-in returns to the relying party with error=server_error&error_description=AADSTS50000:+There+was+an+error+issuing+a+token+or+an+issue+with+our+sign-in+service
Entra sign-in logs: the user sign-in shows the password authentication step failed with AADSTS50000. Failure reason: "service error." No corresponding service-principal sign-in entry for Azure Active Directory Authentication Extensions (the auth-events SP).
Our webhook is never called — confirmed via Cloudflare tunnel inspector (zero inbound requests during the failed sign-in window)
Confirmation that the listener exists in the tenant via GET /v1.0/identity/authenticationEventListeners (returns the onPasswordSubmitListener we registered with the right customExtension.id)

Specific question

Given the listener is registered and the extension exists, what causes Microsoft's auth-events service to fail at the token-issuance step before invoking the extension? The absence of a sign-in log entry for the auth-events SP suggests the failure precedes any auditable attempt to acquire a token for our resource. Is there a tenant-level capability or role wiring beyond the documented setup?

Recent failure trace IDs (most recent first):

5dc45074-f575-4bd7-873b-2b4e46620100
384217b5-1f8b-44b7-ba67-f558da640100
7a11864f-8bf2-42c9-8518-2af403440100

Login works fine if password is reset and correct password is applied. When password is incorrect and we need to migrate, this issue occurs.

Shubham Sharma 16,285 Reputation points Microsoft External Staff Moderator

2026-05-25T03:03:00.4666667+00:00
Hey Abir, AADSTS50000 in the JIT password-migration scenario usually means the auth-events service couldn’t even issue a token for your custom extension, so it never got as far as invoking your webhook. In practice this almost always comes down to one of three things:

Missing or mis-granted permissions

On your extension app registration, under API permissions make sure the Application permission CustomAuthenticationExtensions.Receive.Payload is added and admin-consented.

On the Microsoft Auth-Events service principal, confirm it has the CustomAuthenticationExtension application role assigned on your extension app, and that assignment is enabled.

Listener conditions not matching the actual sign-in

Double-check that your listener’s migrationPropertyId exactly matches the directory extension property name (i.e. extension_<AppIdNoDashes>_toBeMigrated).

In your listener’s conditions array, confirm the clientAppId value is the exact client-app (relying-party) Application (client) ID you see in the Sign-in logs for the token issuance flow.

Unsupported flow for OnPasswordSubmit

The OnPasswordSubmit listener only fires in local-account/password authentication flows. If you’re using a full B2C custom-policy or another federated/interactive flow, the External ID auth-events pipeline may not support JIT migration there and will throw a service error before it ever touches your listener.

What to try next

In the Azure portal, go to Enterprise applications → your extension app → Permissions. Verify the Graph permission is present and granted.

Under Enterprise applications → Azure Active Directory Authentication Extensions → Users and groups, make sure your extension app is assigned the CustomAuthenticationExtension role.

Look at the raw sign-in record for that AADSTS50000 failure: note the “Relying party application” ID and compare it to your listener’s clientAppId condition.

Hope that helps you get your listener invoked!

References:

https://learn.microsoft.com/entra/external-id/customers/how-to-migrate-passwords-just-in-time

https://learn.microsoft.com/entra/identity-platform/custom-extension-troubleshoot#error-codes-reference

https://learn.microsoft.com/graph/api/resources/authenticationeventlistener

https://learn.microsoft.com/graph/api/resources/customauthenticationextension
Abir 0 Reputation points

2026-05-25T06:42:08.49+00:00
Checked all mentioned items.

The error code is undocumented (table only goes to 1003027)

Microsoft's own validator passes

The failure-reason template variable {extensibilityErrorCode} is literally unfilled in their sign-in log UI

Every customer-side prerequisite is met

Flow type supports OnPasswordSubmit

Sign-in is local-account email + password (the standard CIAM externalUsersSelfServiceSignUpEventsFlow, not custom IEF policies), which per the JIT migration docs is the supported flow type.

Relying party app ID vs listener clientAppId

Sign-in log: <our application id>

Persisted listener (verified directly via Graph GET): conditions.applications.includeApplications: [{"appId": "<our application id from sign-in log> }]

Exact match.
Shubham Sharma 16,285 Reputation points Microsoft External Staff Moderator

2026-05-25T08:59:00.6866667+00:00
Abir

Thank you for your reply.

Key Observation

No auth-events SP sign-in log

No Authentication Events tab data

No outbound call attempt

When the extension is invoked, Entra logs API call details (status, retries, etc.) in sign-in logs.

https://learn.microsoft.com/en-us/entra/identity-platform/custom-extension-troubleshoot?tabs=api-testing-tools

Since you see none of that → the pipeline never reached the extension.

What This Means

The failure is NOT:

webhook endpoint issue

extension handler issue

response schema problem

Instead, it is pre-extension token acquisition failure for the extension resource

Root Cause

Misconfigured resource app access token conditions

Your extension uses:

azureAdTokenAuthentication

resourceId = api://<fqdn>/<appId>

For auth-events to invoke your extension:

It must perform a client credentials flow to your extension app

That requires a valid application ID URI (audience) and token issuance path

Docs: -

Extension call uses Entra token flow before REST invocation

https://github.com/MicrosoftDocs/entra-docs/blob/main/docs/identity-platform/custom-extension-overview.md

The extension resource must support token issuance for the auth-events SP

If anything blocks that, you get exactly:

AADSTS50000

No SP sign-in

No logs

No webhook call

Specific Misconfigurations That Cause THIS Exact Pattern

Invalid / non-token-issuable identifierUris

Even if it “looks correct”, it can break silently:

Common issues:

FQDN URI not verified domain

Multiple identifierUris → ambiguity

api:// + FQDN mix

trailing slash mismatch

mismatch between:

resourceId vs identifierUris

This prevents token issuance → auth-events never starts

2. requestedAccessTokenVersion = 2 mismatch edge case

You explicitly set:

requestedAccessTokenVersion = 2

Known issue pattern:

auth-events may try to acquire v1 token

resource enforces v2-only

results in silent token issuance failure → AADSTS50000

3. Extension app not exposed correctly as API

Even if roles exist:

You MUST have:

“Expose an API” configured

Valid Application ID URI

At least one app role enabled and assignable

If not:

token cannot be minted → same failure

4. Auth-events SP role exists but not effective

Even if visible:

Disabled assignment

Wrong tenant instance

stale assignment

auth-events cannot request token

5. Unsupported audience (AzureADMyOrg constraint issue)

You set:

signInAudience: AzureADMyOrg

In CIAM/External ID:

auth-events service principal sometimes behaves as multi-tenant caller

restrictive audience can block token issuance

Why It Works When Password Is Correct

Because:

OnPasswordSubmit is ONLY triggered when:

user fails primary password authentication AND

migrationProperty is true

If primary auth succeeds:

extension is skipped → no issue

This aligns exactly with expected JIT design

https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-migrate-passwords-just-in-time

Below are the resolution steps: -

Normalize Application ID URI

Set ONLY ONE: api://<appId>

Remove: api://<fqdn>/<appId>

Then update extension:

resourceId = api://<appId>

Remove Token Version Restriction

Set in manifest: "requestedAccessTokenVersion": null

(or remove property)

3. Recreate Role Assignment (Clean)

Do BOTH:

Remove existing assignment

Re-assign: Auth-events SP → your extension app → CustomAuthenticationExtension role

4. Verify API exposure

Under Expose an API:

Application ID URI exists

App role exists

Role allowed for Applications

5. Temporarily widen audience (test)

Change: signInAudience → AzureADMultipleOrgs

If it works → confirms audience restriction issue

6. Validate with Graph

Run: GET /servicePrincipals/{auth-events-SP-id}/appRoleAssignments

Confirm:

Assignment exists

resource = your extension app

Expected Behavior After Fix

You will now see:

Service principal sign-in log (auth-events SP)

Authentication Events tab populated

Webhook invoked

Migration proceeds or fails with extension-specific error (1003xxx)
Shubham Sharma 16,285 Reputation points Microsoft External Staff Moderator

2026-05-27T08:39:57.8933333+00:00

Abir

Following up to check if the resolution provided was helpful. Let us know if you need any further assistance.
Abir 0 Reputation points

2026-05-27T08:44:32.53+00:00
Suggestion #1 (use api://<appId> only, remove FQDN form)

This contradicts Microsoft's own earlier errors. When we used api://<guid> without the FQDN, we got IncorrectResourceIdFormat (code 1003014: "should be api://{fqdn}/{appid}"), and DomainNameDoesNotMatch (1003015: "targetUrl and resourceId must share the same FQDN").

The FQDN form is required. Reverting would put us back in a known-broken state.

Suggestion #2

requestedAccessTokenVersion can't be changed — Microsoft rejects v1/null:

InvalidAccessTokenVersion: Access Token Accepted Version may not be 1 or null.

So suggestion #2 is impossible — v2 is mandatory for this app type in External ID, and we already have it. The "v1/v2 mismatch" theory is ruled out by Microsoft itself: if auth-events couldn't handle v2, JIT would be broken for every customer, since v2 is the only allowed value.

Tried suggestion #5, same issue no change

Note: the following is no longer correct:

No auth-events SP sign-in log

No Authentication Events tab data

No outbound call attempt

We are getting entries in sign on logs

Sign-in logs ARE populated (the earlier "no entries" was a tab/filter issue, not missing data).

The failure is specific to the OnPasswordSubmit JIT path — not a general CIAM, app, or token problem. Admin SSO's OIDC flow itself reaches Microsoft (resource = Microsoft Graph for the openid/profile scopes); it's the password-submit→extension hop that breaks.

REgular login when the password is correct works as expected

Abir 0

@Shubham Sharma This is a high level table of what was checked

	#	Check / Suggested fix	What we verified or tried	Result
	1	Custom extension exists & well-formed	Created `onPasswordSubmitCustomExtension` (`b59fb8c4-…`), `azureAdTokenAuthentication`,
correct endpoint + resourceId	✅ Exists, correct
	2	Microsoft's own config validator	`POST /beta/.../validateAuthenticationConfiguration`	✅ `{"errors": [], "warnings": []}`
	3	OnPasswordSubmit listener exists	Verified via Graph GET — `ca3bd8cb-…`, type `onPasswordSubmitListener`	✅ Present in tenant
	4	Listener `includeApplications` matches relying party	Sign-in log app `961c17f9-…` vs listener condition `961c17f9-…`	✅ Exact
match
	5	`migrationPropertyId` matches directory ext. property	`extension_5b89f114…_toBeMigrated` on both	✅ Exact match
	6	`customExtension.id` in listener	References `b59fb8c4-…`	✅ Correct
	7	Directory extension property defined	`toBeMigrated` (Boolean, target=User) on extension app	✅ Defined
	1	Custom extension exists & well-formed	Created `onPasswordSubmitCustomExtension` (`b59fb8c4-…`), `azureAdTokenAuthentication`, correct endpoint + resourceId	✅ Exists, correct
	2	Microsoft's own config validator	`POST /beta/.../validateAuthenticationConfiguration`	✅ `{"errors": [], "warnings": []}`
	3	OnPasswordSubmit listener exists	Verified via Graph GET — `ca3bd8cb-…`, type `onPasswordSubmitListener`	✅ Present in tenant
	4	Listener `includeApplications` matches relying party	Sign-in log app `961c17f9-…` vs listener condition `961c17f9-…`	✅ Exact match
	5	`migrationPropertyId` matches directory ext. property	`extension_5b89f114…_toBeMigrated` on both	✅ Exact match
	6	`customExtension.id` in listener	References `b59fb8c4-…`	✅ Correct
	7	Directory extension property defined	`toBeMigrated` (Boolean, target=User) on extension app	✅ Defined
	8	Test user has migration flag	`toBeMigrated=true` on user (`56a3c7d9-…`)	✅ Confirmed via Graph
	9	Extension app `Receive.Payload` on MS Graph	`214e810f-…` app role assigned to extension SP, admin-consented	✅ Granted
	10	MS Auth-Events SP role on extension app	Custom `CustomAuthenticationExtension` role assigned to `99045fe1-…` SP	✅ Granted, verified via Graph
	11	Extension app has a service principal	`5ca19704-…`	✅ Exists
	12	MS Auth-Events SP exists in tenant	`9e30f8aa-…`	✅ Exists
	13	Webhook reachable over HTTPS	Direct POST → 401 (no auth), GET → 405	✅ Reachable
	14	resourceId / targetUrl FQDN match	Both use `harvest-amusement-mower.ngrok-free.dev`	✅ Match (enforced by earlier 1003015)
	15	identifierUri format	`api://<fqdn>/<appId>` present	✅ Required form (earlier 1003014 forced it)
	16	Suggested: remove FQDN URI, use `api://<appId>`	Would revert to bare-GUID form	❌ Breaks — triggers 1003014/1003015
	17	Suggested: `requestedAccessTokenVersion` → v1/null	Attempted PATCH	❌ Microsoft rejects: "may not be 1 or null" (v2 mandatory)
	18	Suggested: widen `signInAudience` to multi-tenant	Set `AzureADMultipleOrgs`, retested, reverted	❌ No change — still 1003050
	19	Webhook actually invoked at runtime	Tunnel inspector during failed sign-ins	❌ Zero inbound traffic — extension never called
	20	Portal failure-reason rendering	Sign-in log "Failure reason" field	🐞 Shows literal `{extensibilityErrorCode}` placeholder (unrendered template)

Shubham Sharma 16,285 Reputation points Microsoft External Staff Moderator

2026-05-28T01:36:53.5+00:00

Abir

Thank you for your reply.

We are checking and we will get back to you shortly.
Michael E 25 Reputation points

2026-05-28T15:14:07.5666667+00:00

Jumping in because I've been hitting what looks like the same thing for the last few days and the symptoms line up almost exactly with yours, Abir.

Same setup. CIAM tenant, externalUsersSelfServiceSignUpEventsFlow, onPasswordSubmitCustomExtension paired with an onPasswordMigrationCustomExtensionHandler. migrationPropertyId in the extension_<appIdNoHyphens>_toBeMigrated form pointing at a Boolean directory extension on the b2c-extensions-app. Cert with usage Encrypt uploaded to the extension app reg, CustomAuthenticationExtension.Receive.Payload admin-consented on the extension SP, signInAudience AzureADMyOrg, requestedAccessTokenVersion 2. Function endpoint never receives an inbound request. Sign-in fails with AADSTS50000 in about 100 to 500ms.

I reproduced this on two completely separate CIAM tenants. The second one I created cleanly through the Azure portal Create a resource flow for Microsoft Entra External ID, with the Azure subscription linked properly, in EU region, specifically to rule out any tenant-setup quirks from the first one. Same failure. With the listener removed from the app, sign-in works fine for the same user. The moment the listener exists and is scoped to the client app, every sign-in to that app dies.

One detail that might be useful for whoever at Microsoft is looking, because it could either be a hint or just a different shape of the same underlying issue, thought I'd mention it. In our case sign-in fails even when the cloud password is correct. I have a test user with a known passwordProfile and no migration flag set on them at all. Without the listener, that user signs in fine. With the listener in place, AADSTS50000 every time, function never gets called either way. So in our case the listener seems to be breaking the cloud-password path as well as the migration path, not only the latter. Could just be that External ID is consulting the listener earlier in our flow than in yours, or could be something slightly different.

validateAuthenticationConfiguration on the beta endpoint returns no errors or warnings for our extension, same as you found. I haven't checked the Authentication Events tab specifically yet for the 1003050 code, will do that and reply if I see it.

For reference, here's a failing sign-in from the fresh tenant for that test user with the listener bound to the client app and no migration flag on the user. Correlation cc70e2af-892c-47a3-ba38-8d1be5fd8e6c, trace 460ddc6c-35a8-485e-842b-1238d5f50000, around 2026-05-21 20:42 UTC.

If anyone from Microsoft is tracking this as a single incident, that's useful to know. Happy to share more trace and correlation IDs from a fresh repro if it would help the investigation. Mostly we'd just like a rough sense of timeline or any documented workaround, because we're a bit stuck on this and our migration is gated on it.

1 answer

Your answer

Abir 0 Reputation points

2026-05-25T06:42:08.49+00:00

Checked all mentioned items.

The error code is undocumented (table only goes to 1003027)

Microsoft's own validator passes

The failure-reason template variable {extensibilityErrorCode} is literally unfilled in their sign-in log UI

Every customer-side prerequisite is met

Flow type supports OnPasswordSubmit

Sign-in is local-account email + password (the standard CIAM externalUsersSelfServiceSignUpEventsFlow, not custom IEF policies), which per the JIT migration docs is the supported flow type.

Relying party app ID vs listener clientAppId

Sign-in log: <our application id>

Persisted listener (verified directly via Graph GET): conditions.applications.includeApplications: [{"appId": "<our application id from sign-in log> }]

Exact match.
Shubham Sharma 16,285 Reputation points Microsoft External Staff Moderator

2026-05-27T08:39:57.8933333+00:00

Abir

Following up to check if the resolution provided was helpful. Let us know if you need any further assistance.
Abir 0 Reputation points

2026-05-27T08:44:32.53+00:00

Suggestion #1 (use api://<appId> only, remove FQDN form)

This contradicts Microsoft's own earlier errors. When we used api://<guid> without the FQDN, we got IncorrectResourceIdFormat (code 1003014: "should be api://{fqdn}/{appid}"), and DomainNameDoesNotMatch (1003015: "targetUrl and resourceId must share the same FQDN").

The FQDN form is required. Reverting would put us back in a known-broken state.

Suggestion #2

requestedAccessTokenVersion can't be changed — Microsoft rejects v1/null:

InvalidAccessTokenVersion: Access Token Accepted Version may not be 1 or null.

So suggestion #2 is impossible — v2 is mandatory for this app type in External ID, and we already have it. The "v1/v2 mismatch" theory is ruled out by Microsoft itself: if auth-events couldn't handle v2, JIT would be broken for every customer, since v2 is the only allowed value.

Tried suggestion #5, same issue no change

Note: the following is no longer correct:

No auth-events SP sign-in log

No Authentication Events tab data

No outbound call attempt

We are getting entries in sign on logs

Sign-in logs ARE populated (the earlier "no entries" was a tab/filter issue, not missing data).

The failure is specific to the OnPasswordSubmit JIT path — not a general CIAM, app, or token problem. Admin SSO's OIDC flow itself reaches Microsoft (resource = Microsoft Graph for the openid/profile scopes); it's the password-submit→extension hop that breaks.

REgular login when the password is correct works as expected
Shubham Sharma 16,285 Reputation points Microsoft External Staff Moderator

2026-05-28T01:36:53.5+00:00

Abir

Thank you for your reply.

We are checking and we will get back to you shortly.

Answer 1

Hello Abir,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you are having issues with the OnPasswordSubmit JIT migration listener configured per docs, extension never invoked (AADSTS50000 with no auth-events SP sign-in log).

Regarding your explanation, your webhook is not the problem yet. The failure is occurring before Microsoft Entra dispatches the OnPasswordSubmit callout. You can isolate and fix it by the below:

Run validateAuthenticationConfiguration against the OnPasswordSubmit custom extension to catch endpoint/authentication-contract errors pre-runtime. Use the beta validation API because Microsoft’s beta validation explicitly supports onPasswordSubmitCustomExtension. - https://learn.microsoft.com/en-us/graph/api/customauthenticationextension-validateauthenticationconfiguration?view=graph-rest-beta
On the failing sign-in, open Sign-in logs → Authentication Events and capture the 10030xx error code. Do not rely on service-principal sign-in logs as your primary signal; Microsoft documents the Authentication Events tab as the supported diagnostic view for custom authentication extension failures. - https://learn.microsoft.com/en-us/entra/identity-platform/custom-extension-troubleshoot
If you get 1003014/1003015, fix the extension contract so that resourceId is exactly api://<same-fqdn-as-targetUrl>/<appId> and the FQDN matches the targetUrl. - https://learn.microsoft.com/en-us/entra/identity-platform/custom-extension-troubleshoot, https://learn.microsoft.com/en-us/graph/api/resources/onpasswordsubmitcustomextension?view=graph-rest-1.0
If you get 1003016/1003017/1003018/1003019, fix the service-principal state for the API app referenced by resourceId: it must exist in the tenant and be enabled. - https://learn.microsoft.com/en-us/entra/identity-platform/custom-extension-troubleshoot
If you get 1003021, grant/admin-consent Microsoft Graph → CustomAuthenticationExtensions.Receive.Payload to the API app used by the extension. Microsoft documents this exact missing consent as a blocking error. - https://learn.microsoft.com/en-us/entra/identity-platform/custom-extension-tokenissuancestart-configuration,
Rebuild the extension/API authentication using Microsoft’s documented model: create a dedicated API app registration from the custom extension API Authentication step, then secure the Azure Function/API with the external tenant issuer https://{domain}.ciamlogin.com/{tenantId}/v2.0, allow client app 99045fe1-7639-4a75-9d4a-577b6ca3810f, and allow only your tenant. - https://learn.microsoft.com/en-us/entra/identity-platform/custom-extension-tokenissuancestart-configuration, https://learn.microsoft.com/en-us/entra/identity-platform/custom-extension-overview

Meanwhile, use the associated links for more readings and detail steps. It's all about you run the validation API, capture the Authentication Events error code, fix the exact configuration defect it identifies, and only after those two supported checks are clean should you treat the case as a likely Microsoft service-side incident requiring a support ticket with the supplied trace IDs. Ans you can raise ticket via your Azure Portal.

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Abir 0 Reputation points

2026-05-25T05:59:23.7166667+00:00

Hi @Sina Salam

Thanks so much for helping troubleshoot

Ran POST /beta/identity/customAuthenticationExtensions/{id}/validateAuthenticationConfiguration and got HTTP 200 with empty errors and warnings arrays

At runtime the sign-in fails with AADSTS1100001: Non-retryable error has occurred. Underlying error code: 1003050. Code 1003050 is not in the published troubleshooting table at https://learn.microsoft.com/en-us/entra/identity-platform/custom-extension-troubleshoot (which documents 1003000-1003027). What does 1003050 specifically diagnose?

I also managed to find the activity log matching the correlation id (c1e26bd8-48c7-49b7-9e29-8903adc49d61) that was returned

The failure-reason template variable {extensibilityErrorCode} is literally unfilled in their sign-in log UI
Sina Salam 29,596 Reputation points Volunteer Moderator

2026-05-27T16:08:20.4566667+00:00

Hi Abir,

Thank you for your feedback and clarifying the diagnostic steps:

This issue (AADSTS1100001 + underlying 1003050) is now best classified as beyond documented customer self-remediation and likely requires Microsoft internal support or engineering review. I will escalate from here and at thesame time while follow up with you, use your commont above to raise support ticket via your Portal or use Priority Customer Support (PCS).

Success
Abir 0 Reputation points

2026-05-28T13:56:55.3066667+00:00

Ticket raised 2 days ago without response: 2605260040008068

Share via

OnPasswordSubmit JIT migration listener configured per docs, extension never invoked (AADSTS50000 with no auth-events SP sign-in log)

Summary

Environment

What's wired up

Failure pattern

Specific question

1 answer

Your answer