A cloud based approach to Single Sign On and user provisioning.
An IT setup that combines both Microsoft Office365 and Google G Suite is more common than you might expect, especially in UK schools. Managing both platforms is fairly straightforward for a single site but things start to get interesting when you try to incorporate multiple schools, all feeding back into a central organization - a situation commonly found within regional districts and trusts.
In a series of posts we’ll examine one approach to management based on a recent engagement with a Multi-Academy Trust (MAT) that planned to incorporate Google G Suite across a number of schools currently using Microsoft Office365. The goal was not to replace Microsoft Office365 but to provide each school with open access to both services. The trust was looking to manage both Office365 and G Suite as a single tenancy/organisation with each school existing as independent policy unit (sub-organisation).
As a prime objective the trust intended to employ Azure AD as the main directory and authentication source across all the sites. User management would use on-site AD but the actions would drive the automatic creation and updating of accounts into both Azure AD and G Suite. The plan also included the adoption of Chromebooks as the preferred student device for both Office365 and G Suite, using Azure AD as the authentication source.
An earlier proposal involved synchronising data from each remote site. In this model each school would run Azure Active Directory (AD) Connect to provision user accounts into Office 365 (Azure AD) while the complementary service, Google Cloud Directory Sync (GCDS) maintained the accounts in G Suite. Each site would also run the Active Directory Federation service (ADFS) to authenticate users against the local AD database.
During the planning stage it was clear that this approach had a number of problems.
- The rollout involved over 40 locations some of which were small primary schools with limited space and resource. Some sites required additional investment on onsite hardware as well as software upgrades which only only added to the technical complexity and the ongoing support burden. The timescales for the deployment did not allow for an upgrade program.
- A Google Organisation can only direct SSO towards a single external source. Therefore the plan to have have a unified Google organisation talking directly to multiple on-site ADFS sources couldn’t be supported.
- Google Cloud Directory Sync (GCDS) was never designed to work in multi-site setup. Without a complex set of exclusion rules and there was a real risk that accounts from one school could be suspended by a second copy of GCDC running at another site. In a smaller deployment this might be manageable but the trust required a solution that could be scaled up without hitting a configuration bottleneck. Although running multiple G Suite organisations was one option this didn’t fit with the trusts overall strategy.
After a review period it was decided to trial a second approach that provisioned and authenticated users directly from Azure AD using the techniques described in an earlier post. Although this had proved successful for a single school there was no published documentation that described a more complex deployment involving multiple sites and domains. While this presented a significant risk the general approach had a number of benefits for the trust.
In order to support Office365 each school synchronised to the central Office365 tenancy using Azure Active Directory (AD) Connect. Therefore a centralised directory that Google could query was already in place - Azure AD. However some of the larger schools maintained a local ADFS service while others simply synchronised local passwords into Azure AD. It was hoped that by pointing the G Suite organisation at Azure AD as the single target it would acts as broker, authenticating against local cloud accounts, synchronised password accounts or deferring to on-site ADFS as required.
Since Azure AD acts as an integrated directory for the entire trust it made sense to try and provision accounts into G Suite directly from this source rather from each local AD. In this way configuration was centrally controlled and did not require onsite installations of GCDS. In fact the whole solution was zero-touch on the remote sites which enabled a much faster rollout schedule.
So can this approach be made to work in a MAT? Yes it can.
The trust now has G Suite authentication running centrally from the Azure AD database while maintaining day-to-day user administration through local AD at each site. Chromebooks present an Azure AD logon challenge on startup directed to the appropriate authentication source, either Azure or on-site ADFS. There’s no requirement for GCDS as user accounts are created and suspended in G Suite using the auto-provisioning objects provided by MS Azure.
Essentially the solution proved to be a scaled up version of the technique outlined in the earlier post with a few tweaks.
In a follow up post we'll take a closer look at the challenges provided by user provisioning.
If you’re interested in attempting a similar program in your organisation please drop me a line through the contact form and I’d be happy to link you up with the expertise.
