Migration of Function App From In Process to Isolated Model

Question

Migration of Function App From In Process to Isolated Model

Anand Muthusamy 0

Hi All,

I am currently migrating my function App from In Process to Isolated Model.
During testing I encountered some exceptions.
I need help on how to proceed and resolve this exception. Below is the exception
Exception: MSAL.NetCore.4.79.0.0.MsalClaimsChallengeException: ErrorCode: invalid_grant Microsoft.Identity.Client.MsalClaimsChallengeException: AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance. Trace ID: xxx, Correlation ID: xxx, Timestamp: xxx The returned error contains a claims challenge
- ResponseBody: {"error":"invalid_grant","error_description":"AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance. Trace ID: xxx, Correlation ID: xxx , Timestamp: xxx","error_codes":[53003],"timestamp":"xxx","trace_id":"xxx,"correlation_id":"xxx","error_uri":"[https://login.microsoftonline.com/errorHidden Credential]","suberror":"message_only","claims":"{"access_token":{"capolids":{"essential":true,"values":["3d79d567-88b8-4901-ae54-01418818a0e8"]}}}"}
FYI, I am using ClientAssertionCredential and FederatedIdentity
I did some troubleshooting and found the below potential reasons
In-process (dotnet): The Functions host process loads its own bundled dependencies. Due to assembly binding conflicts, the host's older MSAL (4.60.x) overrides the project's MSAL 4.79.0 at runtime. This older MSAL does NOT trigger CA policy evaluation
Isolated (dotnet-isolated): The worker runs in a separate process and loads exactly Azure.Identity 1.17.1 + MSAL 4.79.0 as referenced. This newer MSAL opts into CA policy enforcement, causing Azure AD to evaluate and block the request

Kindly let me know for any possible fixes / resolution for this.

Thanks in Advance

Rukmini 43,900 Reputation points Microsoft External Staff Moderator

2026-07-21T04:20:10.3666667+00:00

Hello @Anand Muthusamy Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Rukmini 43,900 Reputation points Microsoft External Staff Moderator

2026-07-31T04:15:17.49+00:00

Hello @Anand Muthusamy Following up to see if the above provided information was helpful. If you have any further queries do let us know.

2 answers

Your answer

Rukmini 43,900 Reputation points Microsoft External Staff Moderator

2026-07-21T04:20:10.3666667+00:00

Hello @Anand Muthusamy Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Rukmini 43,900 Reputation points Microsoft External Staff Moderator

2026-07-31T04:15:17.49+00:00

Hello @Anand Muthusamy Following up to see if the above provided information was helpful. If you have any further queries do let us know.

Answer 1

Hey @Anand Muthusamy Thanks for the detailed report—this exception is coming from Azure AD during token acquisition, and the key part of the error is:

AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.

So, regardless of the Functions migration mechanics, once the isolated worker starts using the newer MSAL/Auth flow, your conditional access policy is now evaluating the request and blocking it.

That aligns with your observation:

In-process: host loads an older MSAL (4.60.x) due to dependency/assembly resolution, so CA isn’t being enforced in the same way.
Isolated: worker loads Azure.Identity 1.17.1 + MSAL 4.79.0, so CA policy enforcement happens, and the token issuance is blocked.

Based on the provided Azure Functions migration guidance, the migration itself should be done as a coherent “code + config” change (not only a setting flip). In practice, to fix your scenario you’ll need to ensure the isolated worker’s auth behavior is allowed by your Conditional Access policy.

Confirm the migration is complete/correct (staging-slot approach) Microsoft guidance recommends using a staging slot, updating both the runtime setting and stack appropriately, validating, then swapping.

Ensure FUNCTIONS_WORKER_RUNTIME is set to dotnet-isolated in the app configuration for the slot you’re testing (and that it’s not marked as a slot setting).
Ensure you’ve updated the project packages/references for the isolated model (per the migration guide).

Make Conditional Access allow the isolated worker token request Because the isolated worker causes MSAL to trigger the CA evaluation (while in-process didn’t), the resolution is on the Conditional Access side: the access policy needs to permit token issuance for the authentication pattern used by the isolated worker.

In the meantime, you can also treat this as a configuration-drift issue to validate:

Does the isolated worker use the same identity, app registration, federation/credential configuration, and auth parameters as the in-process version?
Does the CA policy include conditions that differ between the two runs (even subtly)—for example, differences in the authentication request characteristics due to MSAL version/claims challenge?

If you want to keep behavior consistent with in-process Your current diagnosis suggests dependency/version differences between host and worker. While this might “work” temporarily, the isolated model is designed to run with the worker’s own dependency set, so the sustainable approach is to align Conditional Access to the isolated auth behavior rather than relying on the in-process host overriding MSAL.

To make progress quickly (and safely), check in your Azure AD sign-in logs / CA diagnostics for the blocked request from the isolated worker, and compare it to what happens in the in-process case.

Let me know if any further queries - feel free to reach out!

Anand Muthusamy 0 Reputation points

2026-07-17T12:19:36.59+00:00

Hi @Rukmini , Thanks for your response. I checked the below option and could you let know what level of permissions are required..

I navigated to Entra Id --> Conditional Access Policies and could see that option is disabled
Rukmini 43,900 Reputation points Microsoft External Staff Moderator

2026-07-19T07:04:39.4033333+00:00

Hello @Anand Muthusamy

If the Conditional Access option is disabled in the Microsoft Entra admin center, it typically indicates that your account doesn't have sufficient permissions to manage or view Conditional Access policies.

To access and troubleshoot Conditional Access policies, you would generally need one of the following Microsoft Entra roles:

Conditional Access Administrator (recommended)

Security Administrator

Global Administrator
Anand Muthusamy 0 Reputation points

2026-07-27T08:10:59.3766667+00:00

Hi @Rukmini ,

Thank you for your response.

I have reached out to the relevant support teams to request the required access.

In the meantime, if you could guide us to the specific team, Teams channel, or support group responsible for granting this access, it would be very helpful. Alternatively, if there is a designated support process or incident queue through which we can raise a request, please let us know.
I also tried to submit the request myself using the link mentioned in the document. However, I receive a permission error when accessing it.

https://microsoft.sharepoint.com/sites/Identity_Authentication/SitePages/New-Process-for-Requesting-Role-Assignments-in-the-MSFT-Corp-Tenant.aspx

But it says there is no permission for it
Rukmini 43,900 Reputation points Microsoft External Staff Moderator

2026-07-30T02:52:54.99+00:00

Hello @Anand Muthusamy To obtain the required access, please contact your organization's Global Administrator, Privileged Role Administrator, or your internal IT/Identity Administration team, as they are responsible for managing and approving access requests. If your organization has a dedicated access management process or service desk, they should also be able to assist you.

Answer 2

hi Anand Muthusamy & thx for sharing urs issue here at Q&A portal,

the real root cause is the Conditional Access policy, not the migration to the isolated worker model. AADSTS53003 means Entra evaluated policy ID 3d79d567-88b8-4901-ae54-01418818a0e8 and blocked token issuance. The MsalClaimsChallengeException is just how the newer MSAL version surfaces that denial. I wouldn’t rely on the theory that the older in-process MSAL skipped Conditional Access. More likely, the old path simply behaved differently or didn’t expose the claims challenge clearly.

Check the Entra sign-in logs using the trace/correlation ID and timestamp. That should show exactly which workload identity policy blocked the service principal and why. Review whether the policy requires a condition that a non-interactive workload identity can’t satisfy, such as device compliance or MFA.

For client credential and federated identity flows, the app can’t complete an interactive claims challenge. The fix is to adjust the Conditional Access policy or exclude this workload identity, not to catch and retry the exception in code.

https://learn.microsoft.com/entra/identity/conditional-access/workload-identity & https://learn.microsoft.com/entra/workload-id/workload-identity-federation

So the isolated migration exposed the problem, but it didn’t create it. The CA policy is the actual blocker.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/

Anand Muthusamy 0 Reputation points

2026-07-17T12:27:09.01+00:00

Hi @Alex Burlachenko , Thanks for your response. I checked the below option and could you let know what level of permissions are required.
I navigated to Entra Id --> Conditional Access Policies and could see that option is disabled