CloudAdapter in-turn replies 401 Unauthorized

Question

CloudAdapter in-turn replies 401 Unauthorized

Mali, Priyanka (Ext) 40

Hello,

We are migrating an MS Teams application which is written in Node.js/Express from Azure sdk to microsoft s365 agent.

After migrating index.js file to use the new auth changes mentioned in migration article for azure we are getting 401 Unauthorized error.

Tried all the possible solutions but no luck.
Article - https://dori-uw-1.kuma-moon.com/en-us/microsoft-365/agents-sdk/bf-migration-nodejs?tabs=before
Error - Adapter process failed: Error: Unknown error type: Request failed with status code 401"" at CloudAdapter.runMiddleware (C:\VirtualAssistant\nic-core\node_modules@microsoft\agents-hosting\dist\src\baseAdapter.js:131:27) at process.processTicksAndRejections (c:\VirtualAssistant\lib\internal\process\task_queues.js:95:5) at async CloudAdapter.process (C:\VirtualAssistant\nic-core\node_modules@microsoft\agents-hosting\dist\src\cloudAdapter.js:245:9) at async C:\VirtualAssistant\nic-core\index.js:160:7 {stack: 'Error: Unknown error type: Request failed wit…:\VirtualAssistant\nic-core\index.js:160:7', message: 'Unknown error type: Request failed with status code 401""'}
ENv

MicrosoftAppType="MultiTenant"
clientId="xyz"
clientSecret="xyz"
tenantId="xyz"

Answer accepted by question author

4 additional answers

Your answer

Answer 1

Kudos-Ng 10,625 Microsoft External Staff Moderator

Hi Mali, Priyanka (Ext),

Thank you for posting your question in the Microsoft Q&A forum.

Based on your description and the migration article you’re following, you’ve updated the authentication passed to CloudAdapter as follows:

Bot Framework SDK (before):

const botFrameworkAuthentication = new ConfigurationBotFrameworkAuthentication(process.env);
const adapter = new CloudAdapter(botFrameworkAuthentication);

Microsoft 365 Agents SDK (after):

const authConfig = loadAuthConfigFromEnv();
const adapter = new CloudAdapter(authConfig);

I verified the behavior of loadAuthConfigFromEnv(). This helper does not explicitly carry an “AppType” (multi‑tenant vs single‑tenant) flag; instead, it infers tenancy from the presence of tenantId in your environment variables:

No tenantId present > interpreted as Multi‑tenant.
tenantId present > interpreted as Single‑tenant.

From your environment, it looks like your existing bot is most likely multi‑tenant, but you still have a tenantId configured. That causes loadAuthConfigFromEnv() to build a single‑tenant AuthConfiguration, which the CloudAdapter then uses to acquire wrong access tokens.

Additional note: Microsoft has deprecated new multi‑tenant bot creation after July 31, 2025. Existing multi‑tenant bots continue to function. If your scenario relies on multi‑tenant behavior and you already have a working multi‑tenant bot, removing tenantId in the environment is the appropriate path. If you intend to migrate to single‑tenant, try creating a new Single‑tenant Azure AD (Microsoft Entra) app registration > Update your bot’s configuration to use the new clientId, clientSecret, and tenantId associated with that single‑tenant app. This avoids 401 errors caused by stale or cached registration data and ensures your tokens are issued by the correct authority for single‑tenant operation.

I hope this helps resolve the 401 you’re seeing.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Nivedipa-MSFT 3,946 Reputation points Microsoft External Staff Moderator

2025-12-02T03:41:38.4766667+00:00

Hi Mali, Priyanka (Ext) - Could you please confirm if the information above was helpful, or do you still need any additional details?
Mali, Priyanka (Ext) 40 Reputation points

2025-12-03T05:21:27.06+00:00

It helped Thankyou for clearing the issue but my app need tenent id and If I want to use new env's key value pair which are documented in microsoft sdk article along with tenant id what would be the available solution.
MicrosoftAppType="MultiTenant"
clientId="xyz"
clientSecret="xyz"
tenantId="xyz"
Kudos-Ng 10,625 Reputation points Microsoft External Staff Moderator

2025-12-03T07:43:09.2833333+00:00
Hi Mali, Priyanka (Ext),

Thank you for your follow‑up question.

In the Agents SDK, loadAuthConfigFromEnv() determines tenancy based on environment variables:

No tenantId > interpreted as Multi‑tenant (authority resolves to organizations).

tenantId present > interpreted as Single‑tenant (authority resolves to that tenant).

If your application needs a tenant identifier for purposes such as app‑specific routing, home‑tenant Graph calls, or telemetry partitioning, that does not require passing tenantId to the adapter’s authentication loader. You can keep a separate configuration key (for example, HOME_TENANT_ID) for your own logic while omitting tenantId from the auth configuration, so the adapter continues to operate as multi‑tenant.

I hope this helps you decide the best next step for your scenario.
Mali, Priyanka (Ext) 40 Reputation points

2025-12-03T11:07:31.6066667+00:00
Can we keep it as old name MicrosoftAppTenantId? Will it not create a confusion like for datatypes we cannot change their type name from String to something else as Alphabets we cannot change their names.
eg.

string a = "abc";

alpthabets a = "abc"

it will indeed give us error with line 2. Can we change the key value pair for our application ? it wont create a problem like above right tenant id not found or anything else if we rename it to MicrosoftAppTenantId.
Kudos-Ng 10,625 Reputation points Microsoft External Staff Moderator

2025-12-03T11:30:35.4033333+00:00
Hi Mali, Priyanka (Ext),

Thank you for asking this follow‑up.

As far as I know, environment variables are runtime configuration, not language types. Renaming a key does not cause a compile‑time error like changing string to alphabets in code.

The only impact is whether the SDK loader expects that key. If the loader doesn’t look for MicrosoftAppTenantId, it will simply ignore it — no crash, no error, just no effect on authentication.

Using loadAuthConfigFromEnv()

It only checks for tenantId.

If you rename it to MicrosoftAppTenantId, the loader will not see any tenant ID and will treat the bot as multi‑tenant.

If you want to use this environment variable in other parts of your implementation, you can safely access it with: process.env.MicrosoftAppTenantId

This way, you keep the value for your own logic without affecting the adapter’s authentication behavior.

Hope this clarifies your concern.

Answer 2

The 401 Unauthorized error you are encountering when using the CloudAdapter in your migrated MS Teams application could be due to several reasons related to authentication issues. Here are some steps you can take to troubleshoot this error:

Check App Registration: Ensure that your application is correctly registered in Azure Active Directory. Verify that the clientId, clientSecret, and tenantId are correctly configured in your environment variables.
Service Principal: If your application is a single-tenant Azure Bot Service, make sure that it is linked to a Service Principal in the tenant. You can check this in the Azure Portal under App Registrations. If a Service Principal does not exist, create one.
Token Scope: Ensure that the token you are using has the correct scopes. For Microsoft Teams applications, the required scope should typically include https://api.botframework.com/.default.
Environment Variables: Double-check that the environment variables are being loaded correctly in your application. You can log these variables to ensure they are set as expected.
Authentication Type: Since you are using MultiTenant, ensure that your application is configured to allow multi-tenant access in the Azure Portal. This can be found under the Supported account types section of your app registration.
Error Handling: Implement error handling in your code to capture and log more detailed error messages. This can help identify the root cause of the 401 error.

If you have verified all of the above and are still facing issues, consider reviewing the migration documentation for any additional configuration steps that may have been missed.

References:

Answer 3

Mali, Priyanka (Ext) 40

I have another question.

We are actually using tenantId across our code so we indeed require this. If we change our app type to SingleTenant what will be the process?
Will the url's , id's for our app will get changed?

Kudos-Ng 10,625 Reputation points Microsoft External Staff Moderator

2025-12-03T14:50:31.9366667+00:00

Hi Mali, Priyanka (Ext),

Thank you for asking this follow‑up.

As far as I know, if you change your app type to SingleTenant by updating the Supported account types in the existing app registration, there will be no change to URLs or IDs (client ID and redirect URIs remain the same).

However, in many cases switching from multi‑tenant to single‑tenant in the same registration can still lead to 401 errors. The recommended approach is to create a new app registration as single‑tenant, then update the new client ID and app secret in your manifest.json and all configuration references to point to the new app.

Hope this helps!

Answer 4

Mali, Priyanka (Ext) 40

Thankyou for your quick response, if I have any further questions I will reach out to you!!

Once again Thankyou for your kind help and support!!

Kudos-Ng 10,625 Reputation points Microsoft External Staff Moderator

2025-12-04T07:19:27.5966667+00:00

Hi Mali, Priyanka (Ext),

Thank you for your kind response.

I truly appreciate that you’ve taken the time to understand the issue thoroughly.

As a Q&A forum moderator, I kindly ask if you feel the answer has addressed your concern please consider accepting my answer it as the confirmed information. Doing so helps the system recognize that the topic has been confirmed, and it provides a valuable reference for other users who may encounter similar questions in the future. It also contributes to building a stronger community and helps increase your reputation score on the platform.

Thank you again for your engagement.

Warm regards,
Kudos-Ng 10,625 Reputation points Microsoft External Staff Moderator

2025-12-05T13:41:44.52+00:00

Hi Mali, Priyanka (Ext),

Just checking in to see if you had a chance to review the previous response.

Your feedback would be very helpful in ensuring everything is on track.

Answer 5

Mali, Priyanka (Ext) 40

Hi, Thankyou for checking back. I am following MultiTenant approach, as suggested I removed the tenantId from env and tested I was no longer getting 401 in local.

When I deployed changes to our DEV env it started giving me 401 issues.
Attaching dev env for your reference.
Below is the error logs from azure.
Auth config loaded: { hasAppId: true, hasAppPassword: true }

Server listening to port 3978

Get Bot Framework Emulator: https://aka.ms/botframework-emulator

To talk to your bot, open the emulator select "Open Bot"

Processing message request...

user channel mapping2

Channel in user mapping msteams

detect api success: {"kind":"LanguageDetectionResults","results":{"documents":[{"id":"documentId","warnings":[],"detectedLanguage":{"name":"English","iso6391Name":"en","confidenceScore":1}}],"errors":[],"modelVersion":"2024-11-01"}}

Adapter process failed: Error: Unknown error type: Request failed with status code 401{"message":"Authorization has been denied for this request."}

at CloudAdapter.runMiddleware (C:\home\site\wwwroot\node_modules\@microsoft\agents-hosting\dist\src\baseAdapter.js:118:27)

at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

at async CloudAdapter.process (C:\home\site\wwwroot\node_modules\@microsoft\agents-hosting\dist\src\cloudAdapter.js:300:9)

at async C:\home\site\wwwroot\index.js:161:7

Mali, Priyanka (Ext) 40 Reputation points

2025-12-05T15:18:59.5733333+00:00

Adding more logs for clarity

BadRequestError: request aborted

at IncomingMessage.onAborted (C:\home\site\wwwroot\node_modules\raw-body\index.js:245:10)

at IncomingMessage.clsBind (C:\home\site\wwwroot\node_modules\cls-hooked\context.js:172:17)

at IncomingMessage.emit (node:events:536:35)

at IncomingMessage.emitted (C:\home\site\wwwroot\node_modules\emitter-listener\listener.js:134:21)

at IncomingMessage._destroy (node:_http_incoming:221:10)

at _destroy (node:internal/streams/destroy:121:10)

at IncomingMessage.destroy (node:internal/streams/destroy:83:5)

at abortIncoming (node:_http_server:796:9)

at socketOnClose (node:_http_server:790:3)

at Socket.emit (node:events:536:35)
Kudos-Ng 10,625 Reputation points Microsoft External Staff Moderator

2025-12-08T12:15:30.0633333+00:00
Hi Mali, Priyanka (Ext),

Thank you for the follow‑up.

From your DEV logs, the 401 still looks like a configuration mismatch on that environment.

loadAuthConfigFromEnv() returns an AuthConfiguration object: https://dori-uw-1.kuma-moon.com/en-us/javascript/api/%40microsoft/agents-hosting/authconfiguration?view=agents-sdk-js-latest

You can safely log a few non‑secret properties to verify tenancy:

tenantId: present > single‑tenant, absent > multi‑tenant

issuers: confirms any custom issuer list

If you’re aiming for multi‑tenant, ensure DEV does not have tenantId set in its environment.

Share via

CloudAdapter in-turn replies 401 Unauthorized

4 additional answers

Your answer