Managing G Suite & Office 365 in a MAT (p2).

User Provisioning.

An earlier post outlined an approach to managing both Google G Suite and Microsoft Office365 in the type of multi-domain setup commonly found as part of a MAT (Multi Academy Trust).

The objective was to a create a single organization/tenancy for both G Suite and Office365 in which each school existed as a sub-organization/domain beneath the parent body. In this situation Azure AD acts as the authentication authority and the primary directory for the user accounts. G Suite provides the collaborative workflow for the teaching teams (Classroom) and the device management platform for both G Suite and Office365 (Chromebooks).

In the first of two posts we’ll take a closer look at the technical challenges of this technique, starting with user provisioning and finishing with single sign on (SS0).

In a standard approach the role of user provisioning between Active Directory and Google G Suite would normally be handled by multiple local instances of Google Cloud Directory Sync (GCDS). However since the MAT already has a single unified user directory in Office365/Azure AD it makes far more sense to sync directly from that source.

Fortunately Azure provides user provisioning as a function of the Enterprise Application SaaS connector for Google G Suite, the details of which are described in the earlier post. However scaling up to a MAT deployment with over forty domains requires a few tricks. So here are a few of the lessons learnt during the process.

Sorting out DNS and installing GAM.
To provision users into G Suite each Office365 domain must be created as a sub-domain in the G Suite organisation. Although this isn’t particularly difficult task, it requires administrative rights on each DNS account to support the verification process, so now is a good time to check that you have that level of access. This task always throws up a few surprises.

The GAM toolset proved particularly useful when creating  the verification codes and running updates using a command similar to the one below.

             gam update verify greyfriarsschool.org txt                 

GAM was also employed later in the project, so installing the toolset against the target G Suite organization proved a key requirement.

Azure provisioning uses a strict mapping of the user ID in Office365  to the same user account in G Suite. There is no way of providing a transformation such that user@schoolA.com relates to user@schoolB.com.  If for any reason the accounts don’t map across both platforms this has to be fixed first.


Creating the provisioning objects.
Each G Suite sub-domain is controlled by its own provisioning object in Azure so the end solution has many provisioning objects but only a single object controlling SSO. Since creating the provisioning objects is a manual task it’s a good idea to use a naming schema so you can match each one to the target domain. The provisioning objects can be created at an early stage and then disabled.

At this point you need to decide how to identify or ‘scope’ the user objects in Azure. In our situation we used a new Azure group for each school -  “Google Users-Domain A” for example, which was referenced by the domains provisioning object.  Moving an Azure user into this group has the effect of creating a Google account, removing it suspends the account. Testing is very easy as it’s filtered through the group membership so there’s little risk of flooding your Google domain with thousands of false accounts. Simply enable the object and add a test account into the scoping group.

The Azure provisioning object requires a user with admin rights to be created in the target G Suite organization to allow it to manage the accounts. Whether you use a single account or one specific to each each sub-domain is largely a data security decision. Using one for each site requires somebody to maintain a password list as there no service account (OAuth) option for this process.

Account post-processing.
One feature that becomes immediately obvious when using Azure AD is the fact that the cloud directory doesn't have a hierarchical structure. Local AD accounts exist in a directory ‘tree’ which can be mapped to a similar OU tree in G Suite which controls policy.  Azure AD doesn’t have this facility so all G Suite accounts are created in root. While this situation might be manageable for a small school, a MAT with over forty domains has the capacity to dump thousands of accounts into the G Suite root container  - which is not a pretty sight.

The solution used a post-processing batch job to search for new accounts in the root container. Once identified the script reads the domain information from the logon account name and moves it to a “New Accounts” holding area under each sub-domain.  The process was written as a powershell script with embedded GAM commands and hosted on a local server although there’s no reason why it couldn't be moved to a Azure server instance making it location independent.

During testing it was clear that the script could be extended to support a more complex set of processing rules. The final production script checks back into Azure AD to pick up additional data which allows it to place student accounts into the correct sub-OU for the year group.

The script needs to be manually updated as new schools come online but this is far simpler process than integrating another instance of GCSD.

A generic example of the provisioning script without the Azure integration can be can be found here.

Next we’ll take a look at Single Sign On.