Checking out Azure AD cross tenant access policies

So, as one does, I was checking out the different Microsoft Graph AppRoles, which are the application scopes available. And then I found this:

Now, I now cross tenant access is something Microsoft has been working on for a while, and I have seen some preview stuff presented, but I have no access to any preview at all at this point. However, let’s see what we can find!

Disclaimer: Do not use this in production, as it is only a private preview feature I discovered.

So, for googlability, the value is Policy.ReadWrite.CrossTenantAccess and follows the common Policy.ReadWrite.Something-format, such as Policy.ReadWrite.ConditionalAccess. I figured I could replace conditional access with crosstenantaccess in the list conditional access policy url, but no luck:

My next step is usually to search GitHub for forks of docs.microsoft.com, and so I did:

Here i found this url, with a pointer to this documentation, and we can even find these:

So, we essentially have the documentation i random branch of Microsoft Docs! 🙂

Using this, we can find that we have no policies in our tenant:

But we have a default policy at https://graph.microsoft.com/beta/policies/crossTenantAccessPolicy/default:

This is our content from the response:

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#policies/crossTenantAccessPolicy/default/$entity",
    "id": "fc3ac7a4-c34e-4530-bc25-5f29c5aa58bd",
    "isServiceDefault": true,
    "tenantRestrictions": null,
    "inboundTrust": {
        "isMfaAccepted": false,
        "isCompliantDeviceAccepted": false,
        "isHybridAzureADJoinedDeviceAccepted": false
    },
    "b2bCollaborationOutbound": {
        "usersAndGroups": {
            "accessType": "allowed",
            "targets": [
                {
                    "target": "AllUsers",
                    "targetType": "user"
                }
            ]
        },
        "applications": {
            "accessType": "allowed",
            "targets": [
                {
                    "target": "AllApplications",
                    "targetType": "application"
                }
            ]
        }
    },
    "b2bCollaborationInbound": {
        "usersAndGroups": {
            "accessType": "allowed",
            "targets": [
                {
                    "target": "AllUsers",
                    "targetType": "user"
                }
            ]
        },
        "applications": {
            "accessType": "allowed",
            "targets": [
                {
                    "target": "AllApplications",
                    "targetType": "application"
                }
            ]
        }
    },
    "b2bDirectConnectOutbound": {
        "usersAndGroups": {
            "accessType": "blocked",
            "targets": [
                {
                    "target": "AllUsers",
                    "targetType": "user"
                }
            ]
        },
        "applications": {
            "accessType": "blocked",
            "targets": [
                {
                    "target": "AllApplications",
                    "targetType": "application"
                }
            ]
        }
    },
    "b2bDirectConnectInbound": {
        "usersAndGroups": {
            "accessType": "blocked",
            "targets": [
                {
                    "target": "AllUsers",
                    "targetType": "user"
                }
            ]
        },
        "applications": {
            "accessType": "blocked",
            "targets": [
                {
                    "target": "AllApplications",
                    "targetType": "application"
                }
            ]
        }
    }
}

Let’s break this down, as this is how a tenant is configured by default. Actually, on GitHub, we already have a break down of the settings!

InboundTrust

The inboundTrust part of the default policy, looks like this:

I understand this as how you treat all tenants, except the ones with more specific policies. Let’s try to adjust it!

I now expect this tenant to directly trust MFA from remote tenants, without requiring users to register MFA in my own tenant.

And indeed, trying to sign into the tenant now still requires MFA, but MFA is provided from my home tenant!

No more “register MFA in every tenant” and asking users to approve using #EXT#@tenant.onmicrosoft.com accounts. Great!

So, I essentially also configured the ability to trust compliant devices from all tenants. This is of course not a good practice, as I would expect this to circumvent all “require compliant device” policies. Let’s test:

I configure a conditional access policy targeting my guest user, requiring MFA and hybrid joined device:

Now, I am unable to access from an unenrolled device, using the same account:

However, I still get the same access denied message when trying from my hybrid joined device too. I guess this might mean that the default policy cannot be used to trust devices from other tenants, as trusting ANY trusted device from all tenants in the world makes no sense at all.

I can now create a new policy specifically targeting the tenant where my device is enrolled. This is done by posting a similar policy to the https://graph.microsoft.com/beta/policies/crossTenantAccessPolicy/partners endpoint, adding tenantId as parameter:

Still nothing, however, after adjusting the conditional access policy like this, it worked great:

That means that I actually need an enrolled device in either my own tenant, or a single trusted tenant, in order to be able to sign in!

How about the B2B settings?

I will investigate that in my next blogpost! 😉