401 "Authorization has been denied" when bot sends a message in single-tenant configuration.

Question

401 "Authorization has been denied" when bot sends a message in single-tenant configuration.

Kevin Boban 45

Issue: 401 "Authorization has been denied" when bot sends a message via the Send Message API in single-tenant configuration.

Environment

Display Name: DG Single Tenant App
Client ID: [Moderator note: personal info removed]
Tenant ID: [Moderator note: personal info removed]
Domain: [Moderator note: personal info removed]

The bot was set up via the bot dev portal.(https://dev.teams.cloud.microsoft/)

Problem When the bot tries to send a message using the Send Message API, we're getting a 401 error with message: "Authorization has been denied for this request.".

In the Azure portal(https://portal.azure.com/), "Supported account types" is set to Single tenant only – salessavvy, following the guidance https://learn.microsoft.com/en-us/answers/questions/5621905/running-into-401-errors-when-bot-is-trying-to-post

If we set "Supported account types" to "Multiple Entra ID tenants", the bot starts working. However, this is not ideal - customers are understandably hesitant to use a multi-tenant configuration due to security concerns.

[Moderator note: personal info removed] is our internal test tenant. We also have a customer blocked on the same issue, so we'd appreciate an urgent resolution. Thanks!

Prasad-MSFT 10,546 Reputation points Microsoft External Staff Moderator

2026-08-25T05:53:47.9333333+00:00
Engineering confirmed that the 401 is happening because the bot is currently generating a multi-tenant token, while the Entra app is configured as Single tenant.

The bot code needs to be updated to follow the single-tenant bot configuration:

Set the bot authentication type to SingleTenant.

Use the correct Tenant ID in the bot configuration.

Ensure token acquisition uses the tenant-specific authority: https://login.microsoftonline.com/<TENANT_ID>/

Do not use common or organizations authorities, as these generate multi-tenant tokens.

Ensure the App/Client ID and credential belong to the same single-tenant Entra app.

In short, changing Supported account types in Azure is not enough—the bot itself must request a tenant-specific token. Once this is updated, we can retest the Send Message API with the app remaining Single tenant.

2 answers

Your answer

Prasad-MSFT 10,546 Reputation points Microsoft External Staff Moderator

2026-08-25T05:53:47.9333333+00:00

Engineering confirmed that the 401 is happening because the bot is currently generating a multi-tenant token, while the Entra app is configured as Single tenant.

The bot code needs to be updated to follow the single-tenant bot configuration:

Set the bot authentication type to SingleTenant.

Use the correct Tenant ID in the bot configuration.

Ensure token acquisition uses the tenant-specific authority: https://login.microsoftonline.com/<TENANT_ID>/

Do not use common or organizations authorities, as these generate multi-tenant tokens.

Ensure the App/Client ID and credential belong to the same single-tenant Entra app.

In short, changing Supported account types in Azure is not enough—the bot itself must request a tenant-specific token. Once this is updated, we can retest the Send Message API with the app remaining Single tenant.

Answer 1

The 401 in a single-tenant setup is caused by how the bot’s identity and tenant configuration are wired, not by a general Teams or Direct Line issue. In a single-tenant bot, the app registration, bot resource, and the tenant where the bot runs must be aligned, and the adapter must be initialized correctly for that single-tenant identity.

From the provided context, there are two directly relevant patterns:

Single-tenant bot identity must be configured correctly in the bot code
For a single-tenant bot, the configuration must explicitly use:
- MicrosoftAppType = SingleTenant
- MicrosoftAppId = the bot’s app (client) ID
- MicrosoftAppPassword = the bot’s app secret
- MicrosoftAppTenantId = the tenant ID where the app is registered
This must be set in the bot’s configuration file (for example, appsettings.json for C#, .env for JavaScript, config.py for Python). If any of these values are missing or mismatched (for example, wrong tenant ID or app type), token acquisition will fail and outbound calls (such as Send Message) will return 401.
Service principal must exist for single-tenant bots
For a single-tenant Azure Bot Service (msaAppType: 'SingleTenant'), the app registration must be linked to a service principal in the tenant. If the service principal is missing, token requests to login.microsoftonline.com/{tenantId} fail with 401. The fix is:
1. In Azure portal, go to App registrations.
2. Open the bot’s app registration using the bot’s Client ID.
3. Check the Managed application in local directory field:
  - If a value is present, the service principal exists.
  - If it shows Create Service Principal, select that to create it.
4. After creation, restart the bot so it can acquire tokens using the new principal.
Adapter initialization for single-tenant / cross-tenant scenarios
A similar 401 issue in Teams was resolved when the bot’s adapter (CloudAdapter) was initialized correctly for cross-tenant communication. If the adapter is still configured as if the app were multi-tenant, or if it does not use the correct MicrosoftAppType and tenant ID, the bot will receive 401 when sending messages even though it can receive them. The working pattern is:
- Ensure the adapter uses the same identity configuration as above (SingleTenant, correct AppId, TenantId, and secret).
- For cross-tenant Teams usage with a single-tenant bot, the bot still authenticates only against its home tenant; the adapter must not be configured as multi-tenant just to reach other tenants.
Why multi-tenant appears to “fix” it
When the app registration is changed to “Multiple Entra ID tenants”, the platform can fall back to multi-tenant token validation, which can mask a missing or misconfigured single-tenant identity (service principal or MicrosoftAppType/tenant ID mismatch). This is why it works in multi-tenant mode but fails in single-tenant mode. However, the Bot Framework and Teams support secure single-tenant bots. The correct fix is to:
- Keep the app registration as single tenant.
- Ensure the service principal exists.
- Ensure the bot’s configuration and adapter use SingleTenant with the correct tenant ID and secret.
Checklist to resolve the 401 in single-tenant mode
1. In Azure portal → App registrations:
  - Confirm the bot app is single tenant.
  - Confirm a Managed application in local directory exists; if not, select Create Service Principal.
2. In the bot’s configuration file:
  - Set MicrosoftAppType = SingleTenant.
  - Set MicrosoftAppId to d957be44-985d-4286-a773-f34cbae2e7a4.
  - Set MicrosoftAppTenantId to 1134ea03-328d-4b26-9caf-505e7392d4aa.
  - Set MicrosoftAppPassword to the current client secret for that app.
3. Ensure the adapter (CloudAdapter or equivalent) is initialized using those values.
4. Restart the bot and retry the Send Message call.

Once the service principal and identity configuration are correct, the bot can remain single-tenant and still send messages via the Send Message API without 401 errors, including in cross-tenant Teams scenarios.

References:

Answer 2

Anonymous

Please note that Q&A forum is a public platform, and moderators will modify the question to hide personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

Hello Kevin Boban

Based on the behavior you described, it’s very likely that the bot was originally created as a multi‑tenant bot and later reused by switching it to single‑tenant. If this is the case, please note that reusing or converting an existing multi‑tenant bot to single‑tenant often results in 401 “Authorization has been denied” errors when sending messages. This same behavior is also reproduced in the thread you shared.

To make a single‑tenant bot work reliably, Microsoft’s supported approach (and what I’ve seen work in practice) is to create a brand‑new app registration and bot configured as single‑tenant from the start, rather than reusing or converting an existing multi‑tenant bot. After creating a new bot and updating the App ID and client secret in the bot configuration, sending messages should work as expected.

Please try this approach and let me know your feedback.

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.

Anonymous

2026-04-20T08:57:21.29+00:00

Hello Kevin Boban

Is there any update from you?

If yes, please feel free to let me know.
Kevin Boban 45 Reputation points

2026-04-20T10:13:36.47+00:00

Thanks for your response, the bot was set up via the bot dev portal.(https://dev.teams.cloud.microsoft/)

Here, when creating the bot, there's no option to set the signInAudience(tenancy) in the UI

Once I click "Create Bot", I notice that the signInAudience in the request is hard-coded to "AzureADMultipleOrgs", which means the bot is being created as a multi-tenant app.Request body: {"displayName": "TeamsBot", "signInAudience": "AzureADMultipleOrgs"}

How can I create a bot that is single-tenant from the start?
Anonymous

2026-04-20T15:03:00.0066667+00:00

Hi Kevin Boban

Please allow me some time to test this approach on my side.

In the meantime, based on my experience, a common approach is to create the app registration manually in Microsoft Entra ID as single‑tenant first, then create and link an Azure Bot resource to that registration, and finally add it in the Teams Developer Portal. This helps ensure the bot is backed by a clean, fully provisioned single‑tenant identity from the very beginning and avoids any leftover multi‑tenant artifacts that often cause outbound messaging failures.

I will continue testing and will update here with the results. In the meantime, you may also want to try this flow, as the Teams Developer Portal can sometimes introduce configuration inconsistencies when it auto‑creates or manages the underlying app registration.

Additionally, may I ask how you are currently acquiring the access token? In many cases, using the common endpoint tends to work only for multi‑tenant scenarios, whereas using a tenant‑specific endpoint (i.e., /{tenant_id}) is required for single‑tenant configurations.
Kevin Boban 45 Reputation points

2026-04-21T07:24:13.44+00:00
Hi Gabriel,

Thank you for the suggestions! We are aware of both the Azure bot resource setup path and the tenant-specific endpoint requirement for single-tenant token acquisition — we are already using the latter.

To clarify our position:

We currently prescribe the Bot Framework portal setup path to our customers, and migrating to the Azure bot resource approach would require significant validation effort — covering all our scenarios and a migration path for existing customers.

Single-tenant bot setup via the Bot Framework portal has worked successfully across multiple customer tenants, so the issue is not with our token acquisition logic or general configuration.

We have now hit this problem in two tenants (one internal, one customer), which makes this urgent for us.

Given the above, we are specifically looking for a clean fix within the Bot Framework portal setup flow, since we've seen it affect only 2 tenants so far. Could you please escalate this internally or confirm whether there is a known bug or workaround scoped to that path?
Anonymous

2026-04-21T12:17:30.1733333+00:00

Hi Kevin Boban

To be honest, from my perspective as a forum moderator, I’ve already shared everything I can based on my experience and current visibility, and I do not have the ability to escalate this issue further on my end. Unfortunately, at this point, I believe this issue may require deeper investigation on the backend.

Since this is affecting both your environment and your customer’s tenant, and given the urgency, I would strongly recommend raising a support ticket through the Microsoft 365 Admin Center (under Teams / Teams Apps / Bots) so the support team can access backend diagnostics and investigate further.

From what I see, this may go beyond typical configuration and could require validation of service-side settings or platform behavior, which is not something we can access from the forum side.

I’m really sorry that I’m not able to assist further on this one, but opening a support case would be the most appropriate next step here.