This post is the second a two part series that examines the user provisioning capabilities of Microsoft Office 365 and Google G Suite in a serverless world.
Part 2 : Azure Active Directory (Microsoft Office 365) into Google.
In the last post we saw how it was possible to configure automatic user provisioning from Google G Suite into Microsoft Azure AD (Office 365) in a situation where Microsoft defers to the Google user directory for SSO.
This configuration would be normally supported by Google Cloud Directory Sync (GCDS) except that GCDS takes data from a local domain controller not Azure AD.
The future lies with cloud based directory services but without local AD and tools like Google Cloud Directory Sync how do you keep everything in step? Like Google G Suite, Microsoft Azure AD has a built-in service to help out with this - Azure User Provisioning.
Setting up Azure User Provisioning to Google G Suite.
The configuration setting for auto provisioning into G Suite can be found in the Azure Portal under Enterprise Apps.
Note: If you are not familiar with the navigation in the Azure UI he easiest way of finding the settings is to simply search for “enterprise apps”.
Clicking in the New Application icon presents you with comprehensive list of SaaS applications that come with pre-built templates that allow them to integrate with Azure directory services. Again the best way of finding the right option is to simply search for “google apps”.
Choosing this option opens up a blade on the right that allows you to enter the config details. There’s not much of interest here except the ability to change the name of the service which might seem unnecessary but, as we’ll see later, this marks a fundamental difference in how the Google and Azure services operate. For this demonstration I renamed the service Google Apps - XMAAcademy.org.
After selecting ADD you are placed into a Quick Start wizard that we wish to avoid so just search for ‘enterprise apps’ to get back to the main menu. Alternatively you can select All Services and find Enterprise Applications in the Security and Identity section. It might be a good idea to take this opportunity set it as a favourite by highlighting the star. It saves all the searching.
Once back in the main dialog you now have a new application listed which can be selected for more options.
The main menu allows you to configure single sign on (SSO) with Google Suite but it’s the Provisioning option we're interested in. Like G Suite you can setup provisioning without having SSO in place but in Azure you can to straight to the option without having to step through a wizard which is a bonus.
Opening the provisioning dialog gives you the option for manual or automatic. Once automatic is selected you get access to all the configuration options.
The process requires an Google account with admin rights so it’s best to create a user specifically for the role before you get to this point. Once the account details have been entered you can check authentication with Test Connection button.
Note: For whatever reason my setup lost connection status on a number of occasions and I was required to re-enter the account details and re-test the connection. So if your synchronisation stops for any reason this might be the first thing to check.
The mappings section controls the relationship between the object attributes in Azure and Google. From the dialog below it’s clear that the provisioning service is capable of synchronizing both users and groups with separate controls for each.
In most cases the default mappings do not need to be adjusted but the dialog has a few interesting features that are worth examination.
First is that each update action can be set independently, For instance you can allow the process to update records but not create them. I’m not sure why this might be useful but the option is available.
The settings section allows you turn provisioning on and off as well as restarting the process which forces a resync of all the objects in scope. The scope defines which user and group objects to synchronize to Google. Google Suite uses the position of the user account in the OU tree and group membership to determine the provisioning scope while Azure has a slightly different approach.
The scope can be set to All users or All Assigned Users as shown in the dialog above. An assigned user is an account that has the Google SaaS app granted to it. Allocation is controlled from the root dialog adding either groups or user accounts to the app.
Any group that is selected automatically places the group and the group members into scope.
The option All Users and Groups has the potential of placing every account in the Azure tenancy in scope without assigning the Google app. At this point a second factor can be used to control the account set.
Back in the attributes mapping section you'll find an option to control the scope of both user and group accounts based on the object attributes (above). These are termed Scoping filters. In this way it’s possible to create a rule that just specifies user accounts with ‘Google’ in extensionAttribute1 for example.
Scoping filtering can be used with both assigned and non-assigned users and although they don't reference the full set of object attributes they include a comprehensive set of logic functions that includes REGEX operators. If multiple scoping clauses are present, they are evaluated using AND logic. Between app assignments, groups and scoping filters, you a fair amount of control over the provisioning process.
Going live with User Provisioning.
Starting provisioning is as simple as changing the status in the master dialog from OFF to ON. The dialog also gives you the ability to force a resync as well as a summary section.
The full log can be found back in the main app menu under the Audit logs icon.
The audit log lists all events for the preceding seven days with a search option which is extremely useful when troubleshooting missing G Suite accounts or incomplete group memberships.
So what does this look like from the Google GSuite viewpoint?
All user accounts are created in the root of the G Suite organisation. There's currently no way to provision an account directly into a sub-OU in order to apply a specific policy. At the moment I can’t see any additional controls for deprovisioning users. By default if a user moves out of scope in Azure the Google account is automatically suspended which is probably the required action anyway.
As you might expect the Google audit logs show user events being actioned by the G Suite provisioning account from a remote IP.
Deploying and Using Azure Provisioning.
Closer inspection reveals a subtle difference in the way G Suite and Azure provisioning works.
The Azure sync references local state to determine which accounts to provision or suspend. This means if you decide to assign four accounts in the Azure domain xmaacademy.org into a Google domain that already contains 200 active accounts in the same domain, it will just create those four accounts - without suspending the original 200 because they are out of scope. Azure only manages Azure accounts that have been placed into or out of scope.
Google works the other way round. It assumes that since you are managing xmaacademy.org then all the Azure accounts in the same domain will be managed. In this respect it makes no distinction between an account that was in scope but was subsequently removed (and therefore should be suspended) and an account that was never in scope. Both accounts types get suspended.
Unlike GCDS the Google sync process doesn’t support exclusion rules for the target domain. For new implementations this is not really an issue but you have to be a careful joining two directories that already populated. It’s probably a good idea to make sure Google accounts already exist and are in scope for all Azure users unless you want to handle a mass suspension when you hit the button for the first time.
Controlling Multiple Google Organisations for a Single Azure Tenancy.
Another interesting feature of Azure sync is that you can create more than one instance of the provisioning process.
The Google process is strictly one-to-one in that one Google Organisation can only sync to one Azure tenancy. You could separately manage sub-domains within this tenancy but each Google organisation can only push data into one Azure AD.
In contrast Azure AD allows you to create multiple instance of the Google provisioning process, each with its own scoping rules and authentication details that could reference different Google organizations. This feature could prove useful for district and educational trust that need to maintain multiple Google organizations from a single cloud directory. It’s technically possible to do this with Google Cloud Directory sync but it’s a risky business and doesn’t really scale.
Acknowledgements
Thanks to Tom Cox at St Illtyd's Catholic High School in Cardiff, Wales for taking the plunge into Azure User Provisioning and helping me work though some the examples described above.
Other Posts.
Auto-provisioning is normally the partner to SSO between Microsoft Azure and Google G Suite. If you are planning to use Chromebooks as a super-simple platform for Microsoft Office 365 and would like your devices to authenticate against your Azure accounts the setup is described here.
No comments:
Post a Comment