Azure Ad Trust Between Tenants
You set up an azure ad trust between tenants by defining inbound and outbound rules. Both directories must agree on shared identity claims, multi-factor checks, and device states. Teams often build these links after a merger or when contractors need internal tools. Admins grant guest users a broad directory role to get people working fast. Those wide permissions stay active long after the project ends and create security risks. How an azure ad trust between tenants works Microsoft Entra ID ma
Zero Trust Architecture + Azure RBAC: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an azure ad trust between tenants by defining inbound and outbound rules. Both directories must agree on shared identity claims, multi-factor checks, and device states. Teams often build these links after a merger or when contractors need internal tools. Admins grant guest users a broad directory role to get people working fast. Those wide permissions stay active long after the project ends and create security risks.
How an azure ad trust between tenants works
Microsoft Entra ID manages cross-tenant links through external collaboration settings. One company acts as the home directory and holds the original user account. The second company acts as the resource directory that hosts the apps and databases. Admins in both places must add each other by tenant ID or domain name.
Once linked, the resource side can trust signals from the home side. The resource directory reads the multi-factor claim from the home login token. Users do not have to register a second phone app in the external tenant. The resource side can also check if the home device meets corporate health rules.
Teams can automate user sync across the two directories as well. The home tenant pushes selected user groups into the target directory on a schedule. When a worker leaves the home company, the sync job removes their external account. This flow stops orphaned guest accounts from piling up in the resource tenant.
Where native cross-tenant rules fall short
Native tenant rules do a good job verifying who logs into the directory. They confirm the user identity and check the device state at the front door. Still, directory trust only decides who gets a session token for a cloud resource. It does not inspect what that user runs inside a database or server later.
External engineers often need to query production databases or run scripts on cloud hosts. Directory roles are too coarse to limit individual SQL queries or shell commands. You end up giving an external user full read or write rights to a database. Once logged in, that guest can pull tables containing emails, phone numbers, or card numbers.
Zero Trust Architecture + Azure RBAC: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Directory logs also miss the details of what happens during the work session. Entra sign-in logs show that a guest user opened a database or server session. They do not record the exact queries run or the data rows returned. Security teams cannot tell if a contractor fixed a bug or copied sensitive tables.
Tightening guest roles across linked directories
Start by replacing open guest invites with strict inbound and outbound tenant rules. Block all external domains by default and allow only approved partner tenant IDs. Require the home tenant to pass a valid multi-factor claim on every login. Never let guest users invite other external users into your resource directory.
Keep directory roles narrow and separate cloud portal permissions from data plane permissions. A guest who needs to read one table should not hold a subscription role. Review external group memberships every month and remove inactive guests right away. Pair your directory trust with controls that check actual commands and mask sensitive fields.
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
Does cross-tenant trust share all users between both directories automatically?
No, adding a tenant trust rule does not copy or expose all user accounts. You must still invite specific guests or assign specific groups to a sync job.
Can the resource tenant trust multi-factor checks from the home tenant?
Yes, the resource admin can enable inbound trust for multi-factor claims in external settings. Users then complete the check once in their home directory during sign-in.
What happens when a synced user leaves their home company?
When you disable the account in the home tenant, the sync service detects the change. It then blocks or deletes the matching guest account in the target directory.