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 uses a TLS decryption appliance without any endpoint config. 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=2148762Before 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 regular 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.
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, 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.
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"
}
]
}
}
}The default cross-tenant policy ID was accepted by Azure AD (no more AADSTS1000108)! But custom policies for external tenants were rejected. The default policy ID is also used for tenant-wide settings like cross-cloud access, so TRv2 might be tenant-wide too.
That devices property also looked interesting. After even more OSINT, it partially 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, feel free to experiment in your own tenants. In part 2, we’ll play with Windows binaries to find out how this all works, and hopefully shed some light on the extra WDAC/firewall option.