This post is the first of a two part series that examines the user provisioning capabilities of Microsoft Office 365 and Google G Suite in a serverless world.
In the UK the majority of schools and colleges rely on a local installation of Microsoft Active Directory (AD) for directory services. For schools that choose to implement Google G Suite, which has its own user directory the choice is either to manually update both user databases or use a tool such as Google Cloud Directory Sync (GCDS) to keep the two account sets in step.
But the future doesn’t lie with on-premise directory services. Microsoft’s intention is to move towards a cloud based resource, namely Azure Active Directory (AAD), the user database that underpins the Office 365 productivity suite.
So without local AD and GCDS how do you keep two cloud based directories in sync?
This post describes how you can configure Google G Suite to synchronize user account data with Azure Active Directory (MS Office 365) without GCDS. In a follow up post we’ll look at how you can drive data in the opposite direction, Azure Active Directory into Google G Suite.
Requirements.
Both techniques assume that the two cloud databases are setup for Single Sign-On (SSO). In this example the Google database is the master, a user logs onto Office 365 and the request is passed to Google for verification. For this to occur an account for the Google user must exist in Azure Active Directory, which is why Single-Sign-On and automatic user provisioning are processes that are closely linked.
However, both Microsoft and Google allow you to deploy user provisioning without having SSO in place so it can be used in situations where users manage their own passwords. Also while the procedures for setting up SSO are generally well documented, the user provisioning aspect remains a well kept secret so it’s worth a closer look.
In this example we have an Office 365 tenancy and Google G Suite organization that both host the xmaacademy.org domain. The objective will be to create a user called bill.gates@xmaacademy.org in Google G Suite and automatically provision the same account in Office 365. All subsequent updates and changes to the Google account will also be replicated.
The Office 365 auto provisioning feature can be found in the SAML Apps icon in the G Suite admin console. Clicking on the yellow + button allows you to select from a number of SaaS platforms. The majority are business related and currently only a few support user provisioning as indicated by the tick symbol. Fortunately Microsoft Office 365 is one of these.
Clicking on Microsoft Office 365 launches a wizard which collects information relating to SSO. Unless you actually intend to setup SSO none of this is relevant to user provisioning but you have to complete the wizard to get to relevant section as shown below.
As this dialog explains, nothing is actioned regarding SSO until you actually upload the IDP data to the SaaS provider but you need to complete the wizard to expose user provisioning as an additional function. Selecting the SETUP NOW button drops you into a configuration dialog with the option to SET UP USER PROVISIONING.
The first step is to authorize the action with Office 365 and for this you’ll need an Azure AD account with admin rights for the tenancy. This is a one off operation with the option to update the account information at a later stage through a general config dialog.
The next set of dialogs configures the attribute mappings, provisioning scopes and the de-provisioning actions in a similar manner to Google Cloud Directory Sync. We'll look at these one by one.
Attribute Mapping.
This section controls how the user values in Google relate to data fields in Azure AD.
To make things easier, three of the mandatory mappings are filled with default values. The exception is onPremisedImmutuanbleID which is blank.
Unfortunately Google doesn’t really give you any clue as to what this value should be. For this example I used Basic Information > Username which allowed me to save the dialog and operate successfully when I tested the system.
This dialog is actually has a filter which can be expanded by clicking on the Show All option. The additional options are also set with expected values with the exception of department and job title which are blank by default.
Provisioning Scope
This simple dialog allows you to enter one or more Google group names.
If you define a group (or a number of groups), only the members of the group will be subject to the provisioning rules for this SaaS app. This an important feature because it overcomes one of the major limitations of the Google organizational structure - namely a user can only be a member of one sub-organisation.
As a result you cannot control curriculum based SaaS apps through sub-organisations alone because a deployment of the type below is impossible.
Sara History sub-organisation - controls deployment of History SaaS app.
Philip History sub-organisation - controls deployment of History SaaS app.
Philip French sub-organisation - controls deployment of French SaaS app.
Jill French sub-organisation - controls deployment of French SaaS app.
Jill Maths sub-organisation - controls deployment of Maths SaaS app.
Sara Maths sub-organisation - controls deployment of Maths SaaS app.
Sara need the History apps and the Maths app but can't be a member of both sub-organisations.
However by using groups you can allocate the SaaS app at the highest level in the sub-org tree and control access using groups. Because a user can be a member of many groups the problem is solved.
To gain access to the SaaS app the user must be a member of a sub-organisation that has the apps turned on AND be a member of a provisioning scope group, if one is defined.
Deprovisioning Scope
The first action in this dialog controls what happens if the app is turned OFF for the user. This occurs when the user is moved into an sub-org that has the SaaS app turned off or the user account is removed from the provisioning group.
The default action is to suspend the user account in Office 365 within 24 hours with the option to delete the account after a fixed period of time. This period can be set to within 24 hours, after 1 day, after 7 days, or after 30 days. In testing the suspend action always occurs within 60 mins and was sometimes almost immediate.
Separate rules control the action on user suspension and deletion but with the same set of options. A suspend action in G Suite translates into a blocked login setting in Office 365. A hard deleted account can only be restored without data loss using Office 365 Admin Center up to 30 days after deletion.
Going live with User Provisioning.
Once all the dialogs have been completed you are passed back to the main page which give you the option to reselect any the dialogs and update the data.
The last step is to turn provisioning ON but as the dialog above informs you can’t do that while the SaaS app is turned OFF for all users, that wouldn’t make a lot of sense.
Some careful thought needs to go into turning on user provisioning. Allocating Office 365 to the root of your Google organization without a group filter has the capability to create a large number of user accounts in Office 365, some of which may not be needed. To provide a finer level of control you should allocate the Office 365 SaaS app to the highest point in the org tree and then control access through a Google Group.
Therefore the first task is to create a Google group to hold a number of test user accounts (in this case bill.gates@xmaacademy.org) and apply this group to the Provisioning Scope dialog shown in the previous section. This is your failsafe mechanism.
After the provisioning group is created and populated you can turn on the Office 365 SaaS app for an appropriate level on your org tree using the standard dialog shown below.
Once completed you have the ability to ACTIVATE PROVISIONING as shown below. You can turn provisioning ON and OFF at any time without deallocating the Office 365 app. However you need to be very careful not to deallocate the app while user provisioning is left on as this takes all your users out of scope and starts the deprovisioning process on Office 365.
Selecting the ACTIVATE PROVISIONING button shows the warning below, allowing you to back out before starting the process with the ACTIVATE button.
The top level dialog now shows the option to DEACTIVATE PROVISIONING and the summary section will display user data after a short delay (refresh the panel).
Although not immediately obvious the summary data value is actually a link to a filtered view on the admin report log which is a nice feature.
By examining the filter list on the Admin Audit report log you can see the extensive list of events related to auto-provisioning. Clearly this is the first stop for troubleshooting any issues.
So what does this look like from the Office 365 viewpoint?
You have a choice of Microsoft admin portals to view the user data but the account will look like this in the Azure portal
or like this in the Office 365 portal
The newly created Microsoft account is unlicensed and therefore will not have an Exchange mailbox, InTune management or any other resource. Unlike G Suite for Business there’s no default licence policy, the complexity and range of Microsoft licensing would make that a little difficult. Microsoft’s long term strategy is to assign licensing through group membership but this is still in a beta phase. Also, as you may have noticed, there’s no facility to sync group membership from Google to Office 365 so manual licensing and group allocation is going to be the way forward, at least for now.
User Updates.
Updating Google user accounts works as expected. Changes to first name, family name and the logon address all pass through to Azure AD and are recorded in the audit log.
Removing a user from the Google provisioning group blocks the login in Office 365 while the reverse action restores the logon rights.
Copying user metadata was a bit more hit and miss. The Telephone field was replicated into the Azure AM Mobile field but not Department, Manager or Title for some reason.
One negative is the fact that there doesn't seem to be any way to gracefully force a sync. It seems to work on a schedule of about an hour but sometimes goes through much quicker, it’s hard to perceive a pattern. Also there’s no simulation mode which is such a useful feature in GCDS.
Other Considerations.
If you’re provisioning into an empty Office 365 tenancy there's little opportunity to mess up but if you have existing AAD accounts you have to be more careful. For instance if you have the following accounts set up in Azure AD as well as Google G Suite.
student1@xmaacademy.org
student2@xmaacademy.org
and then test auto-provision using a new Google account
student3@xmaacademy.org
which is the only member of the Office365 group and in a subOU for which Office365 is turned on, the effect might not be what you expect. The student3@xmaacademy.org account will be created but the same sync will suspend student1@xmaacademy.org and student2@xmaacademy.org because, as far as the sync process is concerned, they are not in scope for the SaaS application. The only exception to this rule are admin accounts in Azure AD which are never suspended. Make sure all your existing AAD accounts are in scope before turning on provisioning otherwise logon rights will be removed.
Use Cases.
The most obvious role for automatic user provisioning is create user accounts in Office 365 when deferring authentication to Google for single sign on. Unfortunately Microsoft doesn't support that configuration.
Although Azure Active Directory can be configured to work with just about every identity provider in the market, Google isn’t on the list.
You might think this is a bit strange since Google allows Microsoft 365 as a SSO partner in the SAML apps section but there’s a catch. If you read the small print in the Google help pages there’s a phrase that gives the game away
Step five states “Set up a federation of your On-Premises Active Directory and Azure Active Directory.” Cough, cough did I really read that!
So to allow Google to authenticate AAD accounts you must have a federation between AAD and a local Active Directory and since AD probably hosted on a dusty old domain controller sitting in a server room the whole the cloud based vision goes out the window. After all if you have an on-premise AD you might as well use GCDS and Microsoft's Azure AD Connect to keep everything in step.
So why doesn’t Microsoft allow it’s Azure accounts to be authenticated by Google as a fully supported partner? There could be a technical reason but the simple fact is that platform that owns the directory also owns the user and both Google and Microsoft want to be the cloud directory of choice for the future.
So has this whole exercise been a waste of time - well not quite
Even without SSO, user provisioning into Azure from Google can play a useful role.
Consider a small school that plans to standardize on Google G Suite but also has a requirement to operate a suite of Window 10 laptops in a secure way. They have little intention (and even less cash) to operate and maintain a highly available, fault tolerant on-premises data-center to manage sixty laptops. It’s a school after all, not a merchant bank,
In this situation, adopting Microsoft’s new cloud based model you could enroll devices into AAD and manage them with InTune, which is fine but when the user logs on they still need to reference an Azure user account. In this situation automatic user-provisioning from Google would fit the bill.
Users would need to maintain their own passwords but user administration could be managed through the G Suite console. Simple, cheap and even more important - serverless.
In the next post we’ll take a look running automatic user provisioning in the other direction, Microsoft Azure to Google G Suite.
Part 2 : Azure Active Directory (Microsoft Office 365) into Google.
Part 1 : Google into Azure Active Directory (Microsoft Office 365).
In the UK the majority of schools and colleges rely on a local installation of Microsoft Active Directory (AD) for directory services. For schools that choose to implement Google G Suite, which has its own user directory the choice is either to manually update both user databases or use a tool such as Google Cloud Directory Sync (GCDS) to keep the two account sets in step.
But the future doesn’t lie with on-premise directory services. Microsoft’s intention is to move towards a cloud based resource, namely Azure Active Directory (AAD), the user database that underpins the Office 365 productivity suite.
So without local AD and GCDS how do you keep two cloud based directories in sync?
This post describes how you can configure Google G Suite to synchronize user account data with Azure Active Directory (MS Office 365) without GCDS. In a follow up post we’ll look at how you can drive data in the opposite direction, Azure Active Directory into Google G Suite.
Requirements.
Both techniques assume that the two cloud databases are setup for Single Sign-On (SSO). In this example the Google database is the master, a user logs onto Office 365 and the request is passed to Google for verification. For this to occur an account for the Google user must exist in Azure Active Directory, which is why Single-Sign-On and automatic user provisioning are processes that are closely linked.
However, both Microsoft and Google allow you to deploy user provisioning without having SSO in place so it can be used in situations where users manage their own passwords. Also while the procedures for setting up SSO are generally well documented, the user provisioning aspect remains a well kept secret so it’s worth a closer look.
In this example we have an Office 365 tenancy and Google G Suite organization that both host the xmaacademy.org domain. The objective will be to create a user called bill.gates@xmaacademy.org in Google G Suite and automatically provision the same account in Office 365. All subsequent updates and changes to the Google account will also be replicated.
The Office 365 auto provisioning feature can be found in the SAML Apps icon in the G Suite admin console. Clicking on the yellow + button allows you to select from a number of SaaS platforms. The majority are business related and currently only a few support user provisioning as indicated by the tick symbol. Fortunately Microsoft Office 365 is one of these.
Clicking on Microsoft Office 365 launches a wizard which collects information relating to SSO. Unless you actually intend to setup SSO none of this is relevant to user provisioning but you have to complete the wizard to get to relevant section as shown below.
As this dialog explains, nothing is actioned regarding SSO until you actually upload the IDP data to the SaaS provider but you need to complete the wizard to expose user provisioning as an additional function. Selecting the SETUP NOW button drops you into a configuration dialog with the option to SET UP USER PROVISIONING.
The first step is to authorize the action with Office 365 and for this you’ll need an Azure AD account with admin rights for the tenancy. This is a one off operation with the option to update the account information at a later stage through a general config dialog.
The next set of dialogs configures the attribute mappings, provisioning scopes and the de-provisioning actions in a similar manner to Google Cloud Directory Sync. We'll look at these one by one.
Attribute Mapping.
This section controls how the user values in Google relate to data fields in Azure AD.
To make things easier, three of the mandatory mappings are filled with default values. The exception is onPremisedImmutuanbleID which is blank.
Unfortunately Google doesn’t really give you any clue as to what this value should be. For this example I used Basic Information > Username which allowed me to save the dialog and operate successfully when I tested the system.
This dialog is actually has a filter which can be expanded by clicking on the Show All option. The additional options are also set with expected values with the exception of department and job title which are blank by default.
Provisioning Scope
This simple dialog allows you to enter one or more Google group names.
If you define a group (or a number of groups), only the members of the group will be subject to the provisioning rules for this SaaS app. This an important feature because it overcomes one of the major limitations of the Google organizational structure - namely a user can only be a member of one sub-organisation.
As a result you cannot control curriculum based SaaS apps through sub-organisations alone because a deployment of the type below is impossible.
Sara History sub-organisation - controls deployment of History SaaS app.
Philip History sub-organisation - controls deployment of History SaaS app.
Philip French sub-organisation - controls deployment of French SaaS app.
Jill French sub-organisation - controls deployment of French SaaS app.
Jill Maths sub-organisation - controls deployment of Maths SaaS app.
Sara Maths sub-organisation - controls deployment of Maths SaaS app.
Sara need the History apps and the Maths app but can't be a member of both sub-organisations.
However by using groups you can allocate the SaaS app at the highest level in the sub-org tree and control access using groups. Because a user can be a member of many groups the problem is solved.
To gain access to the SaaS app the user must be a member of a sub-organisation that has the apps turned on AND be a member of a provisioning scope group, if one is defined.
Deprovisioning Scope
The first action in this dialog controls what happens if the app is turned OFF for the user. This occurs when the user is moved into an sub-org that has the SaaS app turned off or the user account is removed from the provisioning group.
The default action is to suspend the user account in Office 365 within 24 hours with the option to delete the account after a fixed period of time. This period can be set to within 24 hours, after 1 day, after 7 days, or after 30 days. In testing the suspend action always occurs within 60 mins and was sometimes almost immediate.
Separate rules control the action on user suspension and deletion but with the same set of options. A suspend action in G Suite translates into a blocked login setting in Office 365. A hard deleted account can only be restored without data loss using Office 365 Admin Center up to 30 days after deletion.
Going live with User Provisioning.
Once all the dialogs have been completed you are passed back to the main page which give you the option to reselect any the dialogs and update the data.
The last step is to turn provisioning ON but as the dialog above informs you can’t do that while the SaaS app is turned OFF for all users, that wouldn’t make a lot of sense.
Some careful thought needs to go into turning on user provisioning. Allocating Office 365 to the root of your Google organization without a group filter has the capability to create a large number of user accounts in Office 365, some of which may not be needed. To provide a finer level of control you should allocate the Office 365 SaaS app to the highest point in the org tree and then control access through a Google Group.
Therefore the first task is to create a Google group to hold a number of test user accounts (in this case bill.gates@xmaacademy.org) and apply this group to the Provisioning Scope dialog shown in the previous section. This is your failsafe mechanism.
After the provisioning group is created and populated you can turn on the Office 365 SaaS app for an appropriate level on your org tree using the standard dialog shown below.
Once completed you have the ability to ACTIVATE PROVISIONING as shown below. You can turn provisioning ON and OFF at any time without deallocating the Office 365 app. However you need to be very careful not to deallocate the app while user provisioning is left on as this takes all your users out of scope and starts the deprovisioning process on Office 365.
Selecting the ACTIVATE PROVISIONING button shows the warning below, allowing you to back out before starting the process with the ACTIVATE button.
The top level dialog now shows the option to DEACTIVATE PROVISIONING and the summary section will display user data after a short delay (refresh the panel).
Although not immediately obvious the summary data value is actually a link to a filtered view on the admin report log which is a nice feature.
By examining the filter list on the Admin Audit report log you can see the extensive list of events related to auto-provisioning. Clearly this is the first stop for troubleshooting any issues.
So what does this look like from the Office 365 viewpoint?
You have a choice of Microsoft admin portals to view the user data but the account will look like this in the Azure portal
or like this in the Office 365 portal
The newly created Microsoft account is unlicensed and therefore will not have an Exchange mailbox, InTune management or any other resource. Unlike G Suite for Business there’s no default licence policy, the complexity and range of Microsoft licensing would make that a little difficult. Microsoft’s long term strategy is to assign licensing through group membership but this is still in a beta phase. Also, as you may have noticed, there’s no facility to sync group membership from Google to Office 365 so manual licensing and group allocation is going to be the way forward, at least for now.
User Updates.
Updating Google user accounts works as expected. Changes to first name, family name and the logon address all pass through to Azure AD and are recorded in the audit log.
Removing a user from the Google provisioning group blocks the login in Office 365 while the reverse action restores the logon rights.
Copying user metadata was a bit more hit and miss. The Telephone field was replicated into the Azure AM Mobile field but not Department, Manager or Title for some reason.
One negative is the fact that there doesn't seem to be any way to gracefully force a sync. It seems to work on a schedule of about an hour but sometimes goes through much quicker, it’s hard to perceive a pattern. Also there’s no simulation mode which is such a useful feature in GCDS.
Other Considerations.
If you’re provisioning into an empty Office 365 tenancy there's little opportunity to mess up but if you have existing AAD accounts you have to be more careful. For instance if you have the following accounts set up in Azure AD as well as Google G Suite.
student1@xmaacademy.org
student2@xmaacademy.org
and then test auto-provision using a new Google account
student3@xmaacademy.org
which is the only member of the Office365 group and in a subOU for which Office365 is turned on, the effect might not be what you expect. The student3@xmaacademy.org account will be created but the same sync will suspend student1@xmaacademy.org and student2@xmaacademy.org because, as far as the sync process is concerned, they are not in scope for the SaaS application. The only exception to this rule are admin accounts in Azure AD which are never suspended. Make sure all your existing AAD accounts are in scope before turning on provisioning otherwise logon rights will be removed.
Use Cases.
The most obvious role for automatic user provisioning is create user accounts in Office 365 when deferring authentication to Google for single sign on. Unfortunately Microsoft doesn't support that configuration.
Although Azure Active Directory can be configured to work with just about every identity provider in the market, Google isn’t on the list.
You might think this is a bit strange since Google allows Microsoft 365 as a SSO partner in the SAML apps section but there’s a catch. If you read the small print in the Google help pages there’s a phrase that gives the game away
Step five states “Set up a federation of your On-Premises Active Directory and Azure Active Directory.” Cough, cough did I really read that!
So to allow Google to authenticate AAD accounts you must have a federation between AAD and a local Active Directory and since AD probably hosted on a dusty old domain controller sitting in a server room the whole the cloud based vision goes out the window. After all if you have an on-premise AD you might as well use GCDS and Microsoft's Azure AD Connect to keep everything in step.
So why doesn’t Microsoft allow it’s Azure accounts to be authenticated by Google as a fully supported partner? There could be a technical reason but the simple fact is that platform that owns the directory also owns the user and both Google and Microsoft want to be the cloud directory of choice for the future.
So has this whole exercise been a waste of time - well not quite
Even without SSO, user provisioning into Azure from Google can play a useful role.
Consider a small school that plans to standardize on Google G Suite but also has a requirement to operate a suite of Window 10 laptops in a secure way. They have little intention (and even less cash) to operate and maintain a highly available, fault tolerant on-premises data-center to manage sixty laptops. It’s a school after all, not a merchant bank,
In this situation, adopting Microsoft’s new cloud based model you could enroll devices into AAD and manage them with InTune, which is fine but when the user logs on they still need to reference an Azure user account. In this situation automatic user-provisioning from Google would fit the bill.
Users would need to maintain their own passwords but user administration could be managed through the G Suite console. Simple, cheap and even more important - serverless.
In the next post we’ll take a look running automatic user provisioning in the other direction, Microsoft Azure to Google G Suite.
Part 2 : Azure Active Directory (Microsoft Office 365) into Google.
No comments:
Post a Comment