Teams interop: all meeting chat operations return 403 Forbidden for ACS users since ~Aug 24 2026 (calls work; Teams web anonymous can chat in same meeting)
- Dominant language
- No language data
- Stars
- 340
- Forks
- 113
- PR merge metrics
- No merged PRs in 30d
Description
**Describe the bug; what happened?**
Since approximately Aug 24, 2026, every ACS (anonymous interop) user joining Microsoft Teams meetings in our tenant receives 403 Forbidden on ALL meeting chat operations — `ChatThreadClient.sendMessage` and `sendTypingNotification` both fail with:
```
CommunicationError: {
"Code": "Forbidden",
"Message": "The initiator doesn't have the permission to perform the requested operation."
}
```
— and the user receives no incoming thread messages. Calling, roster, screen share, and reactions all work normally. The CallWithChatComposite shows "You are no longer in this chat thread" immediately after joining. No changes were made on our side (no deploys, no tenant/policy changes).
**Key discriminator:** in the SAME meeting, an anonymous participant joining via the **Teams web client** (display name only, unverified — no email OTP) can send meeting chat messages normally. The failure exists only on the ACS interop path.
**What are the steps to reproduce the issue?**
1. Create a Teams meeting (either via Graph app-created `onlineMeetings` or by a human organizer in the Teams desktop app with default options — both reproduce).
2. Mint an ACS identity + token (`voip`, `chat` scopes) and join the meeting with `createAzureCommunicationCallWithChatAdapter` + `CallWithChatComposite` (minimal quickstart, no custom code).
3. Wait for call state `Connected` (fully admitted).
4. Send a chat message.
Result: `POST /chat/threads/19%3Ameeting_...%40thread.v2/messages` returns 403 (on both `api-version=2024-06-05-preview` and `2025-03-15`).
**What behavior did you expect?**
ACS interop users can send/receive meeting chat while in the call, per the documented Teams external-user capabilities.
**If applicable, provide screenshots:**
Sample failing request: `Ms-Cv: IGMF4wkAI0+MIaxuFQ0kJw.0`, 2026-08-31 16:04:38 UTC, resource in Canada region. Happy to share more Ms-Cv values and a live repro meeting privately.
**In what environment did you see the issue?**
- `@azure/communication-react`: 1.32.0
- `@azure/communication-calling`: 1.42.1
- `@azure/communication-chat`: 1.6.0-beta.7
- OS & Device: Windows 11 PC (also reproduced tenant-wide across devices/users in production)
- Browser: Google Chrome (latest); production users on multiple browsers
**Is there any additional information?**
Tenant configuration verified as Global Admin, all permissive:
- `MeetingChatEnabledType = Enabled` on ALL `CsTeamsMeetingPolicy` instances
- ACS federation configured: `EnableAcsUsers = True`, resource immutable ID present in `AllowedAcsResources`
- `EnableAcsFederationAccess = True` on all external access policies
- `BlockedAnonymousJoinClientTypes` empty
- `EnableExternalAccessRestrictionsForChatParticipants` / `EnableMutualFederationForChatParticipants` both False
- per-meeting `allowMeetingChat = enabled`
A test policy with `AnonymousUserAuthenticationMethod = None` assigned to the organizer did not help (a fresh meeting created after assignment still fails). This is NOT the known join-timing issue — the failure persists for the entire meeting while `Connected`.
A Severity-A Azure support case is open in parallel. Also posted on Microsoft Q&A: https://learn.microsoft.com/en-us/answers/questions/5990218/
Cross-posted with full details on the UI library repo: https://github.com/Azure/communication-ui-library/issues/6074 (filed there first; posting here as this appears to be a service-side issue in the ACS↔Teams interop chat gateway rather than an SDK/UI defect).
Contributor guide
No contributing guide indexed for this repository
Research direction
No repository file or test is identified; start by reproducing the failure with the listed ACS package versions, CallWithChatComposite, and the documented POST endpoint. Compare ACS behavior with an anonymous Teams web participant, then use the Azure support case and linked cross-post to determine whether a repository change is possible; done requires a confirmed resolution or maintainer guidance on ownership.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure
- Domain
- cloud
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100