Welcome, Guest

Enabling Automation

To automate B2B collaboration with xTAS, you need to define the trust settings for B2B for inbound and outbound collaboration. The Graph API tool settings are found in the crossTenantAccessPolicy object. However, the main object only contains the control data. The tenant-wide settings are found in the default sub-object, and the partner-specific settings can be found in partners:

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

Initial information acquisition, before you get started with automation, takes place in the usual way with Postman or Graph Explorer [2], which let you explore the API structure. A more detailed description by Microsoft of the cross-tenant access settings API is available online [3].

All settings from the administration interface are also reflected in the API: inboundTrust for the MFA and device settings and b2bCollaboration-Outbound and b2bCollaborationInbound for the basic configuration for outbound and inbound collaboration. If you are only interested in detailed aspects of the default settings, you can use $select to retrieve the details in the usual way:

GET https://graph.microsoft.com/beta/policies/crossTenantAccessPolicy/default?$select=inboundTrust

For an overview of all partner-specific settings, use:

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

The list shows all of the defined partners and their special options. If a setting is tagged null , the tenant default settings from the default object are in effect. If you are interested in a particular partner, you can request the graph with the tenant ID:

GET https://graph.microsoft.com/beta/policies/crossTenantAccessPolicy/partners/72f988bf-86f1-41af-91ab-2d7cd011db47

The results will look similar to Listing 1.

{
   "@odata.context": "https://graph.microsoft.com/beta/$metadata#policies/crossTenantAccessPolicy/partners/$entity",
   "tenantId": "72f988bf-86f1-41af-91ab-2d7cd011db47",
   "isServiceProvider": null,
   "b2bCollaborationOutbound": null,
   "b2bCollaborationInbound": null,
   "b2bDirectConnectOutbound": null,
   "b2bDirectConnectInbound": null,
   "tenantRestrictions": null,
   "inboundTrust": {
      "isMfaAccepted": true,
      "isCompliantDeviceAccepted": true,
      "isHybridAzureADJoinedDeviceAccepted": false
   }
}

To change individual settings (e.g., in the MFA and device settings), you can apply the PATCH function to the inboundTrust object:

PATCH https://graph.microsoft.com/ beta/policies/crossTenantAccessPolicy/partners/72f988bf-86f1-41af-91ab-2d7cd011db47

You need to pass in the details of the change to the graph as the payload in the request body. Even if you want to change only one of the three options in inboundTrust, you have to describe all the settings again (i.e., define the desired state of the inboundTrust object):

{
  "inboundTrust": {
    "isMfaAccepted": true,
    "isCompliantDeviceAccepted": true,
    "isHybridAzureADJoinedDeviceAccepted": true
  }
}

If your company does business with a large number of partners and you want to simplify the resolution from a domain like contoso.com to the tenant ID required for B2B settings in Graph, you can ask Azure AD and its OpenID Connect configuration endpoint for help. The standard requires metadata for the domains, so if you type

https://login.microsoftonline.com/domain.com/v2.0/.well-known/openid-configuration

in your browser or in a script and parse the response, you can easily read the tenant ID from the response.

Better Overview with Workbook

Once you have gained an overview of the possible settings, you only need to decide on the business partners for whom you want to define detailed settings and what these settings should contain. Azure AD gives you an overview of the existing collaborations with partner companies in the form of a workbook that divides the collaboration into inbound and outbound.

The workbook can be found in Azure Active Directory | Workbooks in the Cross-tenant access activity workbook. To ensure meaningful insights and data, you need to export sign-in logs from Azure AD to a log analytics workspace. The workbook can then also access earlier data than the history of the last 30 days [4]. The workbook gives you information on external persons logging in to your tenant – or your own employees logging in to partner tenants (Figure 2).

Figure 2: The cross-tenant access activity dashboard shows the existing collaboration.

Access Reviews

Full control over collaboration and the guest accounts in your own tenant means you need to clean up regularly. With Microsoft Graph and PowerShell, you can discover the last login dates of all guests and delete guests with long periods of inactivity. If you are not just interested in getting rid of inactive guests, but also want to check their permissions for your tenant, Azure AD Access Reviews offers a couple of options: You can use this feature to check individual resources (e.g., group or team memberships, privileged roles, applications) or entire access packages – just for guests, if so desired.

One new feature in Access Reviews is a multilevel review with up to three stages. Everybody ultimately needs to agree on a user keeping track of group memberships and permissions. This task is especially interesting for guest accounts, when employees are overwhelmed by the large number of access checks needed to check up on "their" guests.

In the first stage, you can have the guests confirm that they are still members of projects and therefore still need access to work packages and teams. As each guest confirms this status, and only then, the guest is then presented to an internal employee, who says yes or no to access. Guests who do not answer or return a negative response do not even make it to the second round.

The same thing applies for guests governed by the Block sign-in and remove after 30 days feature provided by Access Reviews. Instead of kicking guests out of a group, you can prevent them signing in to your tenant and, if they fail to contact the help desk, remove them and delete the guest account after 30 days. Multi-stage reviews works in the same way. All guests first need to express their ongoing interest in collaboration, and only those guests who confirm are subject to closer scrutiny by your staff.

Creating a multilevel review is simple: Just navigate to Azure Active Directory | Identity Governance | Access Reviews and create a new review by selecting New Access Review . In this example – reviewing guest accounts for guests who are members of a group – you need to select Teams  + Groups for Select what to review , then decide on the group and select Guest users only as the scope. In the Reviews step, check the (Preview) Multi-stage review box. This option tells the portal to display the First stage review and Second stage review options, where you can specify a reviewer and a review length in days for each. If you need a third review stage, you can enable it by selecting Add a stage .

The Users review their own access option is a good choice for the first stage; for the second, you will want Group owner(s) or Selected user(s) or group(s) . The Reveal review results section lets you determine whether the reviewers in later steps should be able to see the previous decisions. Finally, you need to determine which guests pass from one stage to the next and remain in the review pool.

The Reviewees going to the next stage setting gives you checkboxes to define the desired responses. Approved reviewees would mean that only guests who have already consented make it to the next level. If you additionally want to have non-responders reviewed in the second stage, include Not reviewed reviewees . The other settings in the Settings menu are not so important and have little influence on the multistage settings. Finally, assign a review name, and you can get started.