The Windows 11 ADMXs released a while back, and there’s an interesting new category - “Tenant Restrictions”. It shares a name with an Azure AD feature for restricting endpoints to specific tenants, but that typically requires a beefy TLS decryption appliance and expensive supporting infrastructure (VPNs etc). The ADMX category only has one policy, “Cloud Policy Details” (ID trv2_payload), but fortunately it has a detailed description:

This setting enables and configures the device-based tenant restrictions feature for Azure Active Directory.

When you enable this setting, compliant applications will be prevented from accessing disallowed tenants, according to a policy set in your Azure AD tenant.

Note: Creation of a policy in your home tenant is required, and additional security measures for managed devices are recommended for best protection. Refer to Azure AD Tenant Restrictions for more details. https://go.microsoft.com/fwlink/?linkid=2148762

Before enabling firewall protection, ensure that a Windows Defender Application Control (WDAC) policy that correctly tags applications has been applied to the target devices. Enabling firewall protection without a corresponding WDAC policy will prevent all applications from reaching Microsoft endpoints. This firewall setting is not supported on all versions of Windows - see the following link for more information. For details about setting up WDAC with tenant restrictions, see https://go.microsoft.com/fwlink/?linkid=2155230

Sounds like an endpoint-based version of the existing feature? Sure enough, the ADMX’s description reads “Prototype policies for Tenant Restrictions v2”. And both those links currently redirect to unrelated docs pages; a common Microsoft tactic for unreleased features. At least the policy has some options:

Cloud ID (optional): sounds like an option for sovereign clouds (eg US GCC), defaulting to the standard commercial cloud (microsoftonline.com)

Azure AD Directory ID: tenant ID

Policy GUID: short text

Enable firewall protection of Microsoft endpoints: boolean

Plus three optional large text fields: Hostnames, Subdomain Supported Hostnames, and IP Ranges. Setting the tenant ID and a dummy policy ID results in an AADSTS1000108 error when authenticating:

The policy ID <GUID> provided in the sec-Restrict-Tenant-Access-Policy header did not match a policy ID in tenant <tenant display name>. Please contact your administrator for assistance.

DevTools shows TRv2 is adding a Sec-Restrict-Tenant-Access-Policy: tenantId:policyId HTTP header on requests to certain domains, similar to how Restrict-Access-To-Tenants was used with TRv1. There’s also a new xms_trpid ID token claim issued on tenant-restricted sessions (thanks jwt.ms), containing the policyId.

Time for some OSINT (aka google-fu). There’s a StackOverflow post implying Microsoft have used TRv2 internally since mid-2020, and a GitHub issue for “TRv2 interaction in the Wizard” on a popular WDAC tool, but no technical details. I finally stumbled upon a blog post from Vasil Michev on cross-tenant access policies, which referenced a tenantRestrictions property. Graph Explorer was ideal for testing this.

GET https://graph.microsoft.com/beta/policies/crossTenantAccessPolicy/default

{
    "id": "<GUID>",
    "tenantRestrictions": {
        "devices": null,
        "usersAndGroups": {
            "accessType": "blocked",
            "targets": [
                {
                    "target": "AllUsers",
                    "targetType": "user"
                }
            ]
        },
        "applications": {
            "accessType": "blocked",
            "targets": [
                {
                    "target": "AllApplications",
                    "targetType": "application"
                }
            ]
        }
    }
}

Setting the GPO policy ID to the default cross-tenant policy GUID was successful (no more AADSTS1000108)! But custom cross-tenant policies for external tenants were rejected. The default policy is also used for tenant-wide settings like cross-cloud access, so TRv2 config might be tenant-wide too.

That devices property also looked interesting. After even more OSINT, it leaked in a recent Graph Java SDK release. The expected schema is:

{
	"devices": {
		"mode": "allowed",
		"rule": "device filter"
	}
}

The rule supports standard Azure AD device filters, which could be particularly useful for PAW implementations.

That’s about it for implementing this feature. When it releases, it will allow security-conscious organisations to take another step forward on their cloud journeys, removing one last dependency on expensive on-premises hardware.

In part 2, we’ll experiment with Windows binaries to find out how this all works, and hopefully shed some light on the extra WDAC/firewall option.

2023 Update  link

I recently found the following description on a Microsoft compliance doc, but it’s not sourced from GitHub so I’m not sure when it was added. It confirms that Microsoft are using TRv2 internally.

Microsoft understands that a key part of business involves collaboration and communication with other enterprises. Collaboration and guest access carry their own inherent risks. Employees can be invited to use their home identities to become guests in another tenant or invite guests from another tenant into their own. Employees might also attempt to use the enterprise accounts of another tenant to access said tenant from within their network, creating an exfiltration channel. Malicious or negligent users may also use their personal Microsoft resources for storage of sensitive corporate data (e.g., Outlook, personal OneDrive). This is why Microsoft employs Tenant Restrictions v2 (TRv2). TRv2 is a cloud-policy based authorization control plane that allows control over employee access to external tenants. With TRv2, users on organizationally managed devices or devices inside the corporate network can be blocked from accessing unsanctioned foreign tenants. Cross-Tenant access policies (XTAP) further enable control over how you collaborate within other organization’s tenants (outbound) and how other organizations collaborate within your own organization (inbound). Using XTAP, users can become guests in only explicitly approved tenants.

TRv2 can also be used to prevent token import. Token import takes place when a user logs into an unapproved external tenant from outside the corporate network, then their token is sent to an associate inside the corporate network. The user inside the corporate network then attempts to use the access token to log into an unapproved tenant for the purpose of data exfiltration. TRv2 prevents token import by blocking the internal user from accessing non-allowlisted foreign tenants. In this scenario, the user would not be able to authenticate to the external tenant with the token because of TRv2.