onPasswordSubmitListener breaks sign-in (AADSTS50000) on CIAM tenant even when user has no migration flag set

@Sina Salam A new issue in the final step:

An error occurred: AADSTS50219: User is resetting their password after verifying identity as part of OnPasswordSubmit event's Just-In-Time migration flow Trace ID: 35e2e730-19d2-49eb-b354-08cade1c0200 Correlation ID: 019e8254-adf3-7ba0-8c00-635a8cae9c76 Timestamp: 2026-06-01 08:37:34Z

Hi @TU2

Thank you for your detail feedback.

The fix is to stop sending the user into the password-reset branch unless that branch is intentionally enabled and fully configured. If the goal is seamless first-login migration, the custom extension should return MigratePassword after successful legacy-password validation, not UpdatePassword. If UpdatePassword is intentional, then the same External ID user flow must have self-service password reset enabled with a valid reset method available to the user.- https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-migrate-passwords-just-in-time, https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-enable-password-reset-customers, https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sspr-policy

What this mean in practical terms:

• If your goal is transparent JIT password migration: validate the legacy password, return MigratePassword, and let External ID complete the migration normally.
• If your goal is to force the user to choose a new password immediately: keep UpdatePassword, but make sure self-service password reset is enabled in the External ID user flow and the user can complete the verification method required for reset.

Cheers.

@Sina Salam The azure function returns MigratePassword after successful legacy-password validation. The custom azure function only returns three actions: microsoft.graph.passwordSubmit.MigratePassword, microsoft.graph.passwordSubmit.Retry, microsoft.graph.passwordSubmit.Block. All other processes have been tested and passed. I don't know why returning MigratePassword results in AADSTS50219 error.

@TU2

Thank you for your feedback.

Your issue is a different issue, kindly use Azure Support via your Portal or use PCS as stated in the first link or repost a new thread on AADSTS50219 as a new issue with all description to get fast attention. That's if the below additional response could not resolve permanently. You can use @myname if you like me to answer you.

In addition to my response:

Returning microsoft.graph.passwordSubmit.MigratePassword is already correct, therefore the issue is not caused by using UpdatePassword. The next step is to validate the exact Authentication Event result and the Azure Function response payload. Microsoft documentation confirms that External ID expects the response schema and nonce value to exactly match the request. Any schema mismatch, nonce mismatch, or response-processing failure can prevent migration from completing successfully. In addition, Microsoft documents a known issue where a legacy password that is valid in the source identity provider but does not satisfy Microsoft Entra External ID password complexity requirements can produce migration errors during Native Authentication flows. - https://learn.microsoft.com/es-es/entra/external-id/customers/how-to-migrate-passwords-just-in-time

Otherwise, thump up and accept as an answer if it resolves the issue.

Cheers

Hello @Michael E ，

Has the JIT password migration issue been resolved?

Quick update for anyone tracking this, particularly @Sridevi Machavarapu and @Sina Salam .

I checked the Authentication Events tab on a fresh failure as Sina suggested. It shows "No authentication events were triggered as part of the authentication", but the sign-in itself fails with AADSTS1100001, underlying code 7002139. So Microsoft's own diagnostics are saying the extensibility framework failed and that no extensibility events ran, at the same time, for the same sign-in. The portal also has the unrendered {extensibilityErrorCode} template variable bug that Abir flagged on the related thread, so the underlying code is only visible in the browser URL, not in the sign-in log.

7002139 is outside the documented 1003000 to 1003027 range that the troubleshooting docs cover, and it's different from the 1003019 that TU2 hit. So we're cleanly in "beyond documented self-remediation" territory.

Just to be explicit about what's been checked on a fresh CIAM tenant created via the Azure portal wizard with subscription linked, signing in as a user with no migration flag set and a known cloud password:

• Sign-in works perfectly with no listener bound. Same user, same URL.
• Adding the onPasswordSubmitListener via Graph, with the exact JSON shape from the official how-to-migrate-passwords-just-in-time doc, immediately breaks sign-in for that user.
• The user's cloud password is correct, so per Microsoft's own doc the listener should be a no-op and authentication should proceed via cloud verification. It doesn't.
• The extension app reg has tokenEncryptionKeyId set to match the cert keyId (this was missed earlier, didn't change the outcome), cert uploaded with usage Encrypt, CustomAuthenticationExtension.Receive.Payload admin-consented on the extension SP. All SPs in the chain (extension app, Azure Active Directory Authentication Extensions, client app) have accountEnabled true, no disabledByMicrosoftStatus.
• Listener JSON matches the docs field-for-field. Number of apps in includeApplications makes no difference.
• Function app endpoint never receives a POST, so it's definitely upstream of the function call.
• Reproduced on two CIAM tenants now.

Failing example from a fresh repro: correlation 41aa5cb3-c964-4dca-b764-52946098466a, trace 6b08de62-7095-479c-80c2-86ebf6850000, 2026-06-12T10:25:14Z.

I don't have a paid Azure support plan, so a ticket isn't really an option here. If anyone from Microsoft engineering or support could pick this up internally based on the thread, I'd really appreciate it. The repro is fully reliable and I'm happy to share the listener JSON, sign-in log JSON, customAuthenticationExtension config, anything you want. The test tenant is still up and I can leave it that way for as long as needed.

@TU2 , glad you got past the 1003019. If you remember what specifically resolved it, sharing that here would help whoever else hits this thread next.

Hello @Michael E,

Thank you for your endurance and detail feedback.

I would like to dig deeper:

Your latest evidence narrows the problem to the listener selection/binding stage, not to the Azure Function or password migration logic.

The important facts are:

• Authentication Events says no authentication events were triggered.
• appliedEventListeners is empty.
• The Azure Function never receives a POST.
• The same sign-in succeeds immediately when the listener is removed.
• The failure occurs even for a user without the migration flag.

That means the failure occurs before External ID evaluates the migration property and before it invokes the custom authentication extension.

So the next fix is not to change the Function response, nonce, MigratePassword, password complexity, or legacy validation. Those are all downstream of a successful listener invocation.

The most likely customer-side configuration issue is that the stored onPasswordSubmitListener is not correctly bound to the External ID authentication events flow, and/or the listener stored in Graph does not match the documented object shape. Microsoft Graph documents onPasswordSubmitListener as the listener for password submission events and JIT migration scenarios, and the listener resource includes authenticationEventsFlowId inherited from authenticationEventListener.

At this point, the only customer-side you can do as a remediation that matches all of your evidence is to validate and correct the listener binding to the External ID authentication events flow.

Therefore, you will need to read back the listener exactly as stored:

GET https://graph.microsoft.com/v1.0/identity/authenticationEventListeners/{listener-id}

The listener must contain the correct External ID user flow binding:

"authenticationEventsFlowId": "<externalUsersSelfServiceSignUpEventsFlow-id>"

If that property is missing, null, empty, or points to the wrong authentication events flow, delete and recreate the listener. Do not patch it.

Use this as remediation:

1. DELETE https://graph.microsoft.com/v1.0/identity/authenticationEventListeners/{listener-id}
2. GET https://graph.microsoft.com/v1.0/identity/authenticationEventsFlowsUse the ID of the flow used by your application, specifically the externalUsersSelfServiceSignUpEventsFlow.
3. Recreate the listener with both flow binding and app scoping by using POST https://graph.microsoft.com/v1.0/identity/authenticationEventListeners Content-Type: application/json

      {
        "@odata.type": "#microsoft.graph.onPasswordSubmitListener",
        "displayName": "JIT password migration listener",
        "authenticationEventsFlowId": "<externalUsersSelfServiceSignUpEventsFlow-id>",
        "conditions": {
          "applications": {
            "includeApplications": [
              {
                "appId": "<client-app-registration-appId>"
              }
            ]
          }
        },
        "handler": {
          "@odata.type": "#microsoft.graph.onPasswordMigrationCustomExtensionHandler",
          "customExtension": {
            "id": "<customAuthenticationExtension-id>"
          },
          "migrationPropertyId": "extension_<b2cExtensionsAppIdWithoutHyphens>_toBeMigrated"
        }
      }
   

4. Make sure you read it back and verify the stored object by using GET https://graph.microsoft.com/v1.0/identity/authenticationEventListeners/{new-listener-id}

Confirm these are present and correct:

   {
     "@odata.type": "#microsoft.graph.onPasswordSubmitListener",
     "authenticationEventsFlowId": "<externalUsersSelfServiceSignUpEventsFlow-id>",
     "handler": {
       "@odata.type": "#microsoft.graph.onPasswordMigrationCustomExtensionHandler",
       "customExtension": {
         "id": "<customAuthenticationExtension-id>"
       },

After the listener is correctly bound, you should have:

• A user with no migration flag or toBeMigrated = false should authenticate with the existing cloud password and should not call the Azure Function.
• A user with toBeMigrated = true and a non-matching temporary/cloud password should trigger the password-submit extension.
• The Azure Function should receive the encrypted password-submit payload.
• A successful legacy validation should return MigratePassword.

Microsoft’s JIT migration documentation describes that External ID invokes a custom API during sign-in to validate credentials against a legacy identity provider, and that MigratePassword stores the password in External ID and clears the migration flag for future sign-ins.

Success.

NB: Waiting for your response.

Thanks @Sina Salam Sina, much appreciated.

I tried the exact remediation you proposed and Graph rejected the create call:

POST /v1.0/identity/authenticationEventListeners
{
  "@odata.type": "#microsoft.graph.onPasswordSubmitListener",
  "displayName": "JIT password migration listener",
  "authenticationEventsFlowId": "a10a8462-79f5-47db-9a2e-5a8619fc1dda",
  "conditions": { "applications": { "includeApplications": [{ "appId": "..." }] } },
  "handler": {
    "@odata.type": "#microsoft.graph.onPasswordMigrationCustomExtensionHandler",
    "customExtension": { "id": "..." },
    "migrationPropertyId": "extension_<...>_toBeMigrated"
  }
}

Response:

{
  "error": {
    "code": "AADB2C",
    "message": "Listener is not editable because it is associated with a AuthenticationEventsFlow."
  }
}

I also tried this back in May by PATCHing authenticationEventsFlowId onto an existing listener (after deleting and recreating it without that field), and got the same error message. So as far as I can tell, the field is internally managed by Graph for onPasswordSubmitListener and isn't actually settable by customers, either at POST time or via PATCH. Every onPasswordSubmitListener I have created so far reads back with "authenticationEventsFlowId": null even when the listener is otherwise functional and bound by app conditions to the right user flow.

If there's a different shape, beta path, or admin-portal entry point that actually lets a customer set authenticationEventsFlowId on this listener type, I'd love to know what it is. Otherwise I think this is a strong indicator that the issue is actually on Microsoft's side, since the documentation and your suggested remediation both depend on a field the API won't let us set.

For reference, this is on a fresh CIAM tenant created via the proper Azure portal wizard with the subscription linked, and the listener config otherwise matches the docs at how-to-migrate-passwords-just-in-time exactly. The latest failure is correlation 41aa5cb3-c964-4dca-b764-52946098466a, trace 6b08de62-7095-479c-80c2-86ebf6850000, 2026-06-12T10:25:14Z. Happy to share any further details, and the tenant is still available for any investigation that might help.

Hi @Michael E

Thank you always for the detail information.

Your last result is decisive. It invalidates the authenticationEventsFlowId remediation I suggested.

Your POST/PATCH result shows that authenticationEventsFlowId is not customer-editable for this onPasswordSubmitListener scenario. Although the property appears in the Microsoft Graph resource model, the create listener API does not publicly document it as a writable create field for this listener path, and Graph is explicitly rejecting attempts to set it with:

Listener is not editable because it is associated with a AuthenticationEventsFlow.

Therefore, the null authenticationEventsFlowId value is not enough to blame your configuration. At this point the remaining evidence points to an upstream Microsoft Entra External ID extensibility pipeline failure.

That means the issue occurs before migration-property evaluation and before custom extension invocation.

The only customer-side action that restores service is to delete the listener, since your test confirms Graph rejects that path.

DELETE https://graph.microsoft.com/v1.0/identity/authenticationEventListeners/{listener-id} That fixes the sign-in outage, but it disables JIT password migration.

In two ways:

For production migration, keep this listener enabled on a live app while it causes tenant-wide app sign-in failure. The correct practical path is:

1. Remove the onPasswordSubmitListener from the affected app.
2. Do not attempt to set authenticationEventsFlowId; since Graph rejects it.
3. Keep the documented listener JSON as the repro payload.
4. Use a non-JIT migration path until Microsoft corrects the service behavior or documentation.

Alternatively:

• If passwords are available at rest or runtime, proactively populate credentials during migration. Microsoft’s JIT migration documentation explicitly notes that if passwords are available, they can be proactively populated instead of relying on JIT.
• If passwords are not available, migrate users with temporary/random passwords and require password reset on first sign-in.
• Keep the legacy B2C sign-in live until External ID JIT password migration works reliably in the target tenant.

My conclusion is: The documented JIT password migration listener configuration is failing inside the External ID authentication extensibility runtime for this tenant/app path. Until Microsoft fixes the service behavior or documentation, the safe workaround is to remove the listener and use a non-JIT migration method: proactive password population if passwords are available, or forced password reset/temporary password migration if they are not. Your trace/correlation/timestamp are the right evidence for Microsoft to investigate the internal 7002139 failure.

I will surely escalate for more investigation on 7002139 failure.

Success.

@Michael E @Sina Salam When creating the onPasswordSubmitListener, the authenticationEventsFlowId should be omitted, consistent with the JIT documentation examples. Although the custom Azure Function was successfully triggered, an issue with error code ‌AADSTS50219‌ occurred at the final step. Please refer to the ticket for more details.