tag line

moving IT to the cloud with service not servers

Monday, 22 October 2018

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

Single Sign On (SSO).

In the last in a series of posts that outline a cloud based approach to managing Google G Suite and Microsoft Office365 in a multi-domain setup we take a closer look at single sign on (SSO).

Before we go into details it’s worth outlining the project objectives with respect to SSO.

The Trust uses Office365/Azure AD to deliver a unified user account database across forty schools. Each school has its own DNS domain namespace and local AD accounts are synced to Azure AD from each site using the Azure Active Directory Connect tool.
Some of the larger schools also operate Active Directory Federation Service (ADFS) onsite. This allows a user to authenticate directly with local AD and then access Office365 without being prompted for a second set of credentials.
The objective is to extend SSO from Google to Azure to support the adoption of Chromebooks and related G Suite services across all of the schools in the Trust without any reliance on local ADFS service.


Unlike user provisioning, implementing SSO in such a complex set-up can break things and make users very unhappy.

For this reason it’s important to run a small Proof-of-Concept (PoC) to test the configuration before going live on thousands of accounts.  The situation is further complicated by the fact that SSO can only be turned on or off for a single Google organisation which means that testing affects every account in that domain, not just a subset of users. This is bad for one school but seriously bad if your Google organisation holds forty schools.

Fortunately the Trust had access to a G Suite organisation that was marked for deletion so this provided an ideal environment to run a PoC.

Creating the SSO object in Azure proved fairly simple. Unlike user provisioning which requires an object for each domain, SSO is covered by a single item which takes about ten minutes to configure. Once it’s built you have an ADFS instance in the cloud that’s configured to handle Google authentication requests for all your Azure AD accounts. Fortunately there’s little risk at this stage because, until the Google domain is redirected to the new service everything works as normal.

This is where the spare domain comes in useful.  By setting up the G Suite PoC domain to point to the new Azure service you create a environment that can be used to prove the whole solution, including the Chromebooks if you have a few spare spare management licences.

Initially it’s worth testing using a standard Chrome browser session. Opening https://drive.google.com with a PoC organisation account should present an Azure logon page to complete the authentication. Similarly logging out and requesting a password change should direct to appropriate Azure web form.

Once you have this working you can update the Chrome device policy to pass-though the logon request to Azure. This is process is well documented by Google was well as the earlier post.

At this point the power of a cloud based federation service approach becomes apparent.  The endpoint will authenticate any G Suite account against Azure if there's an matching account in the tenancy.  Interestingly this even works if the school runs local ADFS.  The request is accepted by Azure and then passed through to the local ADFS with Azure acting a bit like  a request router.

During the PoC phase one unexpected problem emerged that's worth closer examination.

Chromebooks require Forms based Authentication (FBA) when they talk to a federation service, after all it’s the ‘form’ that provides the logon dialog box.

When connecting directly to Azure that’s not a problem but local ADFS instances can be configured to replace FBA with Windows Integrated Authentication (WIA).   WIA provides a much smoother experience for internal users moving between Office 365 and local resources.

A standard ADFS configuration does not list Chrome as one the the browsers that support WIA (even though it does) so it’s fairly common for ADFS administrators to add Chrome to the list of supported User Agents so that desktop Chrome users can have the same slick WIA experience. Unfortunately this action makes a Chromebook very unhappy. After failing to respond to the WIA request it throws up a default form in order to capture the user logon information which looks and behaves in a very ugly manner.

Fortunately the fix is fairly  simple. The User Agent that is added to ADFS has to be altered slightly from “Mozilla/5.0” to "Mozilla/5.0 (Windows NT”.

The second version only specifies Chrome running on Windows as having WIA support and therefore ADFS defaults to sending a form to the Chromebook and order is restored. The fix is documented in more detail in this excellent post

Conclusion.
The Trust has been running with this configuration from the beginning of the new school year in September 2018.

The Azure tenancy and Google organisation are linked using the SSO object with all G Suite logon requests handled by Azure or routed back to the local ADFS instance. Google accounts are auto-provisioned  by Azure without running Google Cloud Directory Sync on each site.  The Trust is slowly developing the capability of the provisioning script to to add more intelligence into account management. Students now use Chromebooks to access the Office 365 webapps along with a number of other SaaS services.

If you're interested in trying this out yourself, so long as you have access to a test Google Organisation to allow you to make mistakes without affecting production users you can’t go far wrong.  Contact me for any further information.

Lastly many thanks to Sumit Tank for handling this project with the Trust IT team and having the courage to believe that might even work.

Tuesday, 2 October 2018

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.

Tuesday, 18 September 2018

Managing G Suite & Office365 in a MAT (p1)

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 attempt 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.