Federation Microsoft Teams

Published
Length
3 min read

Luis Felipe Dias

All posts

To set up federation microsoft teams, an admin opens the central portal and adds trusted external domains. Once both sides approve the link, users can chat and call across company borders. Many engineering teams turn on open rules to speed up partner work. Still, broad domain rules let any external user ping your staff and share unvetted data. How federation microsoft teams works External chat relies on trust rules between two separate cloud tenants. Each tenant keeps its own user directory a

Identity Federation + Microsoft Entra ID (Azure AD): the complete guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free white paper. No spam. Unsubscribe anytime.

To set up federation microsoft teams, an admin opens the central portal and adds trusted external domains. Once both sides approve the link, users can chat and call across company borders. Many engineering teams turn on open rules to speed up partner work. Still, broad domain rules let any external user ping your staff and share unvetted data.

How federation microsoft teams works

External chat relies on trust rules between two separate cloud tenants. Each tenant keeps its own user directory and login checks. When a user sends a message to a partner, the local cloud checks its domain list. If the target domain is on the allow list, the system routes the message across. The receiving tenant runs the exact same check before it delivers the chat.

Admins can choose between three main domain postures. First, they can allow all external domains by default. Second, they can allow all domains except a specific block list. Third, they can block all domains and only allow approved partners. You can also assign user policies so only specific teams can talk to outside partners.

How federation differs from guest accounts

Teams often confuse external domain links with guest accounts. A federated user stays logged into their own home tenant at all times. They can join chats and calls, but they do not enter your local directory. Guest users, by contrast, get an identity added directly into your company tenant. Guests can browse shared team channels, open folders, and edit shared files.

Because federated users stay outside your boundary, they have fewer built-in rights. Still, engineers often use these external chats to debug live incidents with vendors. During an outage, staff paste database rows, error logs, and terminal output into the chat. The native domain rule only checks who can talk, not what they share.

Identity Federation + Microsoft Entra ID (Azure AD): architecture patterns and best practices

Continue reading? Get the full guide.

Free. No spam. Unsubscribe anytime.

What native domain rules solve and what they miss

Native tenant rules do a great job of stopping spam from unknown companies. They let you pick which business partners can reach your staff on chat. They also tie into your identity provider so departed partner staff lose chat privileges fast. This setup solves the basic problem of who can start a conversation.

Still, chat links leave a big gap when teams work on live systems together. Vendors and contractors often ask for database queries or server checks over chat. Or worse, teams share static database keys in chat so partners can fix an issue. Native domain rules only check who logs in to the chat app. They do not govern the actual commands, queries, or requests that run on your backend. When an engineer runs a query for a partner, raw customer data can leak out. Masking that rewrites emails, phone numbers, card numbers, and national IDs in results closes this gap.

Add runtime guardrails and masking beside your databases and APIs

Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.

Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.

Frequently asked questions

Can federated users read files in our shared channels?

No, standard federated users can only join direct chats and audio or video calls. To share channel files, you must add the person as a guest or use shared channels.

Do both companies need to allow each other's domains?

Yes, external chat requires a two-way trust between both company tenants. If one side blocks the domain, messages and calls will fail right away.

How do we stop data leaks during vendor support chats?

Never paste raw query results or static keys into an external chat window. Use database rules that rewrite emails, card numbers, and phone numbers before anyone copies the output.

Save the open-source gateway.

hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.