To simplify the implementation effort and level of complexity, only two things are required in the subsidiary tenant:
- A security group to manage which users are synchronised across to host as guests
- An app registration to enable the workflows to extract data from Azure Active Directory
The security group within the subsidiary tenant is used by the workflows to identify which users should be created as guests within the host tenant.
This is done to reduce the potential clutter of having service accounts and other resources from the subsidiary’s Azure Active Directory tenant, created in the host tenant.
It is recommended that this group be configured with the membership type as Assigned to provide a greater level of control. If Dynamic is chosen, then the rules should be validated to ensure only valid users are added.
The app registration within the subsidiary tenant provides the host workflows with access to identify users that must be synchronised to the host tenant, updated, or deleted. Additionally, it enables the copying of profile information and photo.
The following images outlines the process for configuring the app registration in Azure AD.
Initial creation
Upon creation of a new app registration, specify a suitable display name that will makes sense and is logical.
For supported account types, select “Accounts in this organizational directory only”.
For Redirect URI, select “Web” from the dropdown, and enter the following URL: https://global.consent.azure-apim.net/redirect
Client secret
Navigate to Certificates & secrets menu and press the “New client secret” button.
Give the secret a description and specify a suitable duration for it to expire.
Ensure you record only the secret value, as this is required later.
App permissions
Navigate to the API permissions menu and press the “Add permission” button.
Select Microsoft Graph.
Select Application permissions.
Search for “Directory.Read.All” and select the checkbox.
Next, search for “User.Read.All”, select the checkbox, and press the “Add permissions” button.
Your API permissions screen should look like the below image.
Press the “Grant admin consent for <your organisation name>” button and select Yes when prompted.
Your permission screen should now look like the image below.
You will need to provide the secret value recorded earlier, as well as the application (client) ID and directory (tenant) ID from the Overview screen, as in the image below.
There are several components required within the host tenant for this solution to work:
- Security group(s) to store the guests who require access to the intranet
- App registration to perform guest operations such as creation, updating, and deletion
- Adjustment to intranet site permissions
- SharePoint site with lists for storage of guest sync information
The security group within the host tenant is used to manage access to the intranet.
host can choose to have a single group per subsidiary organisation, or a single group for all of them.
To simplify management membership for the group within the host tenant, a dynamic rule can be configured that automatically adds guests who are from the subsidiary tenant(s).
The structure of the dynamic rule contains two main components:
- The domain name of the UPN of the guest from their home tenant (the subsidiary)
- The user type is of “guest”
An example of such a rule can be found below:
All that is required to add a tenant to the Guest Sync Engine is to record the security group ID and app registration details from the subsidiary tenant in the Guest Sync Tenants list.
Once added, the users from the tenant will be picked up in the next run of the engine workflows.
In order to grant the newly created guests access to the SharePoint site, all that is required is to add the security group created earlier in the host Tenant Requirements section as a Site Visitor.
It is however a pre-requisite that the SharePoint site (and tenant itself) be allowed to admit existing guests.