AADSTS1100001 from EEID custom auth extension onAttributeCollectionSubmit — no SP sign-in logs, all visible config verified

Question

AADSTS1100001 from EEID custom auth extension onAttributeCollectionSubmit — no SP sign-in logs, all visible config verified

Jeremy Norton 0

A signup attempt against an EEID (CIAM) tenant fails with AADSTS1100001 ("No service principal found in directory") at the onAttributeCollectionSubmit custom extension call. The Function App receives zero inbound requests during the failure, and zero entries appear in AADServicePrincipalSignInLogs for any SP in the entire tenant during the failure window — confirming the failure is at EEID's pre-token-acquisition stage, not at our HTTP endpoint.

Tenant: EEID xxxxxxxxx (xxxxxxxx.onmicrosoft.com) Reproducible from: "Run user flow" in the EEID portal (so frontend / MSAL config is exonerated) Recent failing correlation IDs:

Setup:

User flow prism-signup-signin (id xxxxxx) — freshly recreated to eliminate stale state
onAttributeCollectionSubmit.customExtension.authenticationConfiguration.resourceId = api://xxxxxxxx.azurewebsites.net/2xxxxxxxxx
endpointConfiguration.targetUrl = https://xxxxxxxx.azurewebsites.net/api/registration-validator
Claims Provider app appId xxxxxxxx, objectId xxxxxxxx
Claims Provider SP objectId xxxxxxx

What I have already verified:

Claims Provider SP accountEnabled: true, disabledByMicrosoftStatus: null
identifierUris on the app: both api://{appId} and api://{hostname}/{appId} — servicePrincipalNames on the SP includes both plus the bare appId
App role CustomAuthenticationExtension.Receive.Payload (id xxxxxxxb, allowedMemberTypes: ["Application"], isEnabled: true) defined on the Claims Provider app
That app role is granted to the EEID Azure Active Directory Authentication Extensions SP (local objectId xxxxxxx8, appId xxxx)
Claims Provider SP has admin-consented CustomAuthenticationExtension.Receive.Payload on Microsoft Graph (id xxxxx)
requiredResourceAccess on Claims Provider has a single (deduped) entry for the above
signInAudience tested as both AzureADMyOrg and AzureADMultipleOrgs — same error
requestedAccessTokenVersion: 2
Zero conditional access policies in the tenant
Tenant App SP (id xxx, appId xxxxx) enabled, healthy, registered as the includeApplications entry on the flow
signIns and directoryAudits queried via Graph for all failing correlation IDs — both empty. SP sign-in logs across the entire tenant in the failure windows: also empty.
EasyAuth on the Function App correctly configured (issuer = CIAM v2, audience matches identifierUri) — but irrelevant since EEID never makes the HTTP call

The error progression that gives one clue: before granting MS Graph admin consent on the Claims Provider SP (item #5 above), the error was AADSTS1003021 (Custom Authentication Extension failed). After granting consent, it became AADSTS1100001. So consent moved the flow further but it now fails resolving an SP at the next stage.

Question: What identifier does AADSTS1100001 say it can't find for these correlation IDs? With no SP sign-in log entries and the Microsoft-internal STS error text not exposed to the client, I can't determine which principal the resolver is missing — every visible candidate exists and is correctly named in this tenant. Pointers to a more specific log surface, or a known scenario where this combination fails, would be hugely appreciated.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-04-24T00:35:21.43+00:00
Hello Jeremy Norton,

Since the Function App receives no request and there are no AADServicePrincipalSignInLogs, the failure is happening before EEID tries to acquire a token. This means the issue is in the custom authentication extension validation stage, not at the Function App endpoint. Your testing also confirms that the resourceId format is correct and Graph is enforcing that exact format .

The closest documented match is 1003016 – CustomExtensionResourceServicePrincipalNotFound, where the resourceId must resolve to a valid service principal in the tenant. This often appears as AADSTS1100001 – No service principal found in directory.

Since the resourceId, identifierUris, servicePrincipalNames, app role assignment, and admin consent are already verified, the next step is to focus on runtime resolution inside STS.

Please check the following:

Confirm the Enterprise Application belongs to the current app registration and not an older deleted and recreated object using the same URI.

Re-save the custom authentication extension and reattach it to the recreated user flow to rule out stale backend references.

Verify the Azure Active Directory Authentication Extensions first-party service principal is present and correctly assigned the required app role.

If possible, create a fresh Claims Provider app registration with a completely new Application ID URI and test again to rule out hidden stale object references.

The change from AADSTS1003021 to AADSTS1100001 after granting Microsoft Graph admin consent is a useful clue. It shows the request is moving further in validation, but service principal resolution is still failing before the outbound call is made.

This makes stale service principal metadata or an older object reference more likely than a configuration issue.

Please try these checks and share the results.
Jeremy Norton 0 Reputation points

2026-04-24T08:26:02.4+00:00

Sridevi — tried suggestion #2 (re-save extension via PATCH + delete/recreate user flow to reattach). Still AADSTS1100001, fresh correlation cbc29216-dd2e-467d-bccf-d78fd271474d at 2026-04-24T08:23:49Z. New flow id after recreate: 541bc047-c32f-4714-9ade-30709bf094c2.

Your integrity checks (#1 and #3) came back completely clean: no deleted apps/SPs with matching identifiers, exactly one app claims the identifierUri, exactly one SP has the SPN, SP ↔ app linkage verified, AAD Auth Extensions SP present with correct role assignment. This tenant has never held any other Claims Provider app (it's the result of a full parallel rebuild). So "stale metadata" doesn't fit what's on disk.

Before we try #4 (fresh app with brand-new URI) — is there any server-side telemetry you can pull for correlation cbc29216-dd2e-467d-bccf-d78fd271474d that would tell us what identifier STS is failing to resolve? Given Graph validates the config as correct and the SP demonstrably exists with exactly the servicePrincipalName Graph requires, understanding the mismatch would make any future provisioning robust. Otherwise #4 would fix the symptom but leave us exposed to the same failure in test/prod.
Jeremy Norton 0 Reputation points

2026-04-24T09:45:29.44+00:00
Quick update — also tried your suggestion #4 before your reply:

Created a completely fresh Claims Provider app with a brand-new appId (24fb8c6d-c6ad-4a11-919f-02600977717f) and different identifierUri (api://prism-auth-functions-dev.azurewebsites.net/24fb8c6d-...). Configured from scratch:

New SP

Defined CustomAuthenticationExtension.Receive.Payload app role (new role id 06f23b4e-...)

Requested + admin-consented MS Graph CustomAuthenticationExtension.Receive.Payload

Granted the new app role to the EEID Azure Active Directory Authentication Extensions SP (local objectId 138e914c-...)

Updated EasyAuth clientId and allowedAudiences to accept the new audience

PATCHed standalone customAuthenticationExtensions/e39ff266-... resourceId to point at the new audience

Deleted + recreated the user flow (new id 745b7f9d-fbe1-4801-8752-1b65a6e1d497)

Still AADSTS1100001, correlation 0d64e6ed-8320-4c21-a709-6486fbed036c at 2026-04-24T09:28:32Z. The new appId has never existed in this or any other directory before today.

This rules out stale object references / cached metadata as the cause. We now have two independently-provisioned Claims Provider apps (23c78427-... and the fresh 24fb8c6d-...), both correctly configured per Graph validation, both producing the same failure from every angle we can observe.

At this point we've exhausted every client-side variable. Could the EEID product team pull the STS-internal trace for 0d64e6ed-8320-4c21-a709-6486fbed036c and tell us exactly which identifier resolution fails and why? Happy to set up a screenshare or open a proper support case if that helps the escalation.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-04-24T19:53:51.38+00:00

Hello Jeremy Norton,

Thank you for testing this so thoroughly. Since the issue still occurs with a completely new Claims Provider app, new appId, new identifierUri, new custom authentication extension binding, and a recreated user flow, this rules out stale metadata, duplicate objects, and tenant-side provisioning issues.

At this stage, the visible configuration appears correct, and the failure is happening inside the EEID/STS flow before token acquisition. Since there are still no Function App calls and no AADServicePrincipalSignInLogs, the exact identifier causing AADSTS1100001 is not available in customer-facing logs.

Because the same issue occurs with two separate app registrations, this points more toward backend service principal resolution rather than app configuration.

Please include the recent correlation IDs and timestamps, especially the latest repro from the newly created Claims Provider app, as that clearly shows the issue continues even after full reprovisioning.

Jeremy Norton 0

Thank you Sridevi — appreciate the clear acknowledgement. Here's the consolidated set of recent correlation IDs, in time order, all from "Run user flow" in the EEID portal targeting tenant c16e43a7-3ac9-452a-bb97-f64c7283c2dd:

Correlation ID	Timestamp (UTC)	Configuration at time of failure
`0d64e6ed-8320-4c21-a709-6486fbed036c`	`2026-04-24T09:28:32Z`	Brand-new Claims Provider app (`24fb8c6d-c6ad-4a11-919f-02600977717f`), brand-new identifierUri, brand-new role id, fully reprovisioned permission chain, EasyAuth updated to new audience, user flow recreated with id `745b7f9d-fbe1-4801-8752-1b65a6e1d497`. App had never existed in any directory before that day.
--------	--------	--------
`0d64e6ed-8320-4c21-a709-6486fbed036c`	`2026-04-24T09:28:32Z`	Brand-new Claims Provider app (`24fb8c6d-c6ad-4a11-919f-02600977717f`), brand-new identifierUri, brand-new role id, fully reprovisioned permission chain, EasyAuth updated to new audience, user flow recreated with id `745b7f9d-fbe1-4801-8752-1b65a6e1d497`. App had never existed in any directory before that day.
`5e0f88a9-8e16-45d4-b71c-b56ce5e25e0a`	`2026-04-24T14:08:10Z`	Same as above, plus we discovered tenant-level sign-in identifiers had not been enabled (Email + UPN). Enabled via portal, waited for propagation, retested. No change.

All client-facing telemetry surfaces continue to be empty for these correlation IDs (auditLogs/signIns, auditLogs/directoryAudits, sign-in logs UI). Function App receives only its own health pings during the failure windows.

One additional note for visibility — we attempted to open a paid Azure support case to escalate in parallel but our subscription tier (MPN Sponsor) doesn't include technical-case entitlement; this Q&A thread is the only support channel available to us. If the next step requires opening a formal case, please let us know and we'll purchase a standalone Developer Support plan.

Tenant remains in the same state as correlation 5e0f88a9-... for any further repro you'd like us to run.

Jeremy Norton 0

One more datapoint that just emerged from browser DevTools telemetry capture, much more specific than the AADSTS code:

Internal telemetry event captured client-side at the failure moment:

{
  "name": "IDUX_ClientTelemetry_ServiceDiag",
  "time": "2026-04-25T12:54:22.671Z",
  "iKey": "o:b0c252808e614e949086e019ae1cb300",
  "data": {
    "dimensions": {
      "correlationId": "94861de8-7cbf-4593-b983-9bbfed470f73",
      "flavor": "fabric",
      "flow": "AttributeCollection",
      "view": "AttributeCollection",
      "clientRingId": "R2",
      "serviceId": 3,
      "hostPageId": "11407"
    },
    "metricName": "MissingContinuationToken"
  }
}

The companion API event records:

{
  "name": "IDUX_ClientTelemetry_ApiEvents",
  "data": {
    "apiName": "https://cirrusprismdev2.ciamlogin.com/common/validateuserattributes",
    "responseCode": 200,
    "networkDuration": 405,
    "totalProcessingTime": 405
  }
}

Jeremy Norton 0 Reputation points

2026-04-25T13:10:50.1566667+00:00

One more datapoint: we now have full diagnostic settings flowing from EEID c16e43a7-... into our Log Analytics workspace via Lighthouse delegation (all 9 categories enabled — SigninLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, AuditLogs, ProvisioningLogs, RiskyUsers, UserRiskEvents, RiskyServicePrincipals, ServicePrincipalRiskEvents, MicrosoftGraphActivityLogs).

Confirmed flowing — my portal admin activity surfaces correctly. But searching the workspace for the failed correlation 94861de8-7cbf-4593-b983-9bbfed470f73 (or the literal string "1100001") returns zero hits across every table over the failure window. EEID's STS is not writing this failure to any customer-accessible diagnostic category.

So client-side telemetry (MissingContinuationToken) is the only signal we can capture. Internal STS traces are the only place this failure can be diagnosed. Please could the EEID team pull theirs?

Your answer

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-04-24T00:35:21.43+00:00

Hello Jeremy Norton,

Since the Function App receives no request and there are no AADServicePrincipalSignInLogs, the failure is happening before EEID tries to acquire a token. This means the issue is in the custom authentication extension validation stage, not at the Function App endpoint. Your testing also confirms that the resourceId format is correct and Graph is enforcing that exact format .

The closest documented match is 1003016 – CustomExtensionResourceServicePrincipalNotFound, where the resourceId must resolve to a valid service principal in the tenant. This often appears as AADSTS1100001 – No service principal found in directory.

Since the resourceId, identifierUris, servicePrincipalNames, app role assignment, and admin consent are already verified, the next step is to focus on runtime resolution inside STS.

Please check the following:

Confirm the Enterprise Application belongs to the current app registration and not an older deleted and recreated object using the same URI.

Re-save the custom authentication extension and reattach it to the recreated user flow to rule out stale backend references.

Verify the Azure Active Directory Authentication Extensions first-party service principal is present and correctly assigned the required app role.

If possible, create a fresh Claims Provider app registration with a completely new Application ID URI and test again to rule out hidden stale object references.

The change from AADSTS1003021 to AADSTS1100001 after granting Microsoft Graph admin consent is a useful clue. It shows the request is moving further in validation, but service principal resolution is still failing before the outbound call is made.

This makes stale service principal metadata or an older object reference more likely than a configuration issue.

Please try these checks and share the results.
Jeremy Norton 0 Reputation points

2026-04-24T08:26:02.4+00:00

Sridevi — tried suggestion #2 (re-save extension via PATCH + delete/recreate user flow to reattach). Still AADSTS1100001, fresh correlation cbc29216-dd2e-467d-bccf-d78fd271474d at 2026-04-24T08:23:49Z. New flow id after recreate: 541bc047-c32f-4714-9ade-30709bf094c2.

Your integrity checks (#1 and #3) came back completely clean: no deleted apps/SPs with matching identifiers, exactly one app claims the identifierUri, exactly one SP has the SPN, SP ↔ app linkage verified, AAD Auth Extensions SP present with correct role assignment. This tenant has never held any other Claims Provider app (it's the result of a full parallel rebuild). So "stale metadata" doesn't fit what's on disk.

Before we try #4 (fresh app with brand-new URI) — is there any server-side telemetry you can pull for correlation cbc29216-dd2e-467d-bccf-d78fd271474d that would tell us what identifier STS is failing to resolve? Given Graph validates the config as correct and the SP demonstrably exists with exactly the servicePrincipalName Graph requires, understanding the mismatch would make any future provisioning robust. Otherwise #4 would fix the symptom but leave us exposed to the same failure in test/prod.
Jeremy Norton 0 Reputation points

2026-04-24T09:45:29.44+00:00

Quick update — also tried your suggestion #4 before your reply:

Created a completely fresh Claims Provider app with a brand-new appId (24fb8c6d-c6ad-4a11-919f-02600977717f) and different identifierUri (api://prism-auth-functions-dev.azurewebsites.net/24fb8c6d-...). Configured from scratch:

New SP

Defined CustomAuthenticationExtension.Receive.Payload app role (new role id 06f23b4e-...)

Requested + admin-consented MS Graph CustomAuthenticationExtension.Receive.Payload

Granted the new app role to the EEID Azure Active Directory Authentication Extensions SP (local objectId 138e914c-...)

Updated EasyAuth clientId and allowedAudiences to accept the new audience

PATCHed standalone customAuthenticationExtensions/e39ff266-... resourceId to point at the new audience

Deleted + recreated the user flow (new id 745b7f9d-fbe1-4801-8752-1b65a6e1d497)

Still AADSTS1100001, correlation 0d64e6ed-8320-4c21-a709-6486fbed036c at 2026-04-24T09:28:32Z. The new appId has never existed in this or any other directory before today.

This rules out stale object references / cached metadata as the cause. We now have two independently-provisioned Claims Provider apps (23c78427-... and the fresh 24fb8c6d-...), both correctly configured per Graph validation, both producing the same failure from every angle we can observe.

At this point we've exhausted every client-side variable. Could the EEID product team pull the STS-internal trace for 0d64e6ed-8320-4c21-a709-6486fbed036c and tell us exactly which identifier resolution fails and why? Happy to set up a screenshare or open a proper support case if that helps the escalation.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-04-24T19:53:51.38+00:00

Hello Jeremy Norton,

Thank you for testing this so thoroughly. Since the issue still occurs with a completely new Claims Provider app, new appId, new identifierUri, new custom authentication extension binding, and a recreated user flow, this rules out stale metadata, duplicate objects, and tenant-side provisioning issues.

At this stage, the visible configuration appears correct, and the failure is happening inside the EEID/STS flow before token acquisition. Since there are still no Function App calls and no AADServicePrincipalSignInLogs, the exact identifier causing AADSTS1100001 is not available in customer-facing logs.

Because the same issue occurs with two separate app registrations, this points more toward backend service principal resolution rather than app configuration.

Please include the recent correlation IDs and timestamps, especially the latest repro from the newly created Claims Provider app, as that clearly shows the issue continues even after full reprovisioning.
Jeremy Norton 0 Reputation points

2026-04-25T13:04:35.72+00:00

One more datapoint that just emerged from browser DevTools telemetry capture, much more specific than the AADSTS code:

Internal telemetry event captured client-side at the failure moment:

{ "name": "IDUX_ClientTelemetry_ServiceDiag", "time": "2026-04-25T12:54:22.671Z", "iKey": "o:b0c252808e614e949086e019ae1cb300", "data": { "dimensions": { "correlationId": "94861de8-7cbf-4593-b983-9bbfed470f73", "flavor": "fabric", "flow": "AttributeCollection", "view": "AttributeCollection", "clientRingId": "R2", "serviceId": 3, "hostPageId": "11407" }, "metricName": "MissingContinuationToken" } }

The companion API event records:

{ "name": "IDUX_ClientTelemetry_ApiEvents", "data": { "apiName": "https://cirrusprismdev2.ciamlogin.com/common/validateuserattributes", "responseCode": 200, "networkDuration": 405, "totalProcessingTime": 405 } }
Jeremy Norton 0 Reputation points

2026-04-25T13:10:50.1566667+00:00

One more datapoint: we now have full diagnostic settings flowing from EEID c16e43a7-... into our Log Analytics workspace via Lighthouse delegation (all 9 categories enabled — SigninLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, AuditLogs, ProvisioningLogs, RiskyUsers, UserRiskEvents, RiskyServicePrincipals, ServicePrincipalRiskEvents, MicrosoftGraphActivityLogs).

Confirmed flowing — my portal admin activity surfaces correctly. But searching the workspace for the failed correlation 94861de8-7cbf-4593-b983-9bbfed470f73 (or the literal string "1100001") returns zero hits across every table over the failure window. EEID's STS is not writing this failure to any customer-accessible diagnostic category.

So client-side telemetry (MissingContinuationToken) is the only signal we can capture. Internal STS traces are the only place this failure can be diagnosed. Please could the EEID team pull theirs?