tag line

moving IT to the cloud with service not servers

Tuesday, 8 May 2018

Why app licencing is a dead dog for Chromebooks.

Managing Android apps on Chromebooks creates a number of challenges for schools, one of which is licencing.

Software licencing is not really a Chromebook, or even an app issue but a general problem that’s been around for as long as IT admins have been installing packages onto local devices.

Over the years there have been numerous attempts to manage the process including dongles (remember DESkey), key servers, USB devices, block and site codes, up to and including a trust relationship with the customer backed up with the threat of a visit from FAST.

While you have a limited number of machines that can be matched with an equally limited number of software titles the situation can be managed without too much stress. The problems start to emerge when you scale up to hundreds of devices and spirals out of control when you introduce customised application sets and shared device deployments. Unfortunately the majority of Chromebook/Android deployments fall squarely onto the last category - many users, on shared devices, all requiring a custom app set that's linked to the curriculum.

The current model for software deployment onto mobile devices uses the store concept  (Google PlayStore, Apple App Store and Microsoft Store) and while this is well suited to individual with a couple of devices, a personal credit card and a desperate need to play Candy Crush, it quickly falls apart when you apply it to large deployments of shared devices

Apple have gone through a number of iterations to solve the bulk licencing problem while Google tried to adapt the store model with Google Play for Education, only to run into the same predictable set of issues - it was inflexible and it didn’t scale.

To make things worse Google have another problem before they can make Android app licensing workable. The current deployment framework is based on an simple organisational tree which is ideal for general policy control but is entirely unsuitable for paid applications.  For this to work you need to deploy apps against user groups and currently that’s not possible.

So where does that leave us.



I think we have to accept that licencing at the point of install is a dead dog for app deployments onto shared Chromebooks (or any device).  We’ve tried it and it doesn't work - give it up.

I don't understand why local licencing is a problem that we are still trying to fix. It’s like an emotional attachment that we can’t quite shake off, the notion that value of the app lies space it consumes on local storage rather than the service it provides. Perhaps it’s something deeply embedded in the IT psyche from installing applications on Microsoft Windows for the last 20 years. 
It’s not 1998 anymore. The real value of the local app has migrated to backend services such as cloud based directories, remote storage, analytical dashboards and advanced API’s that expose a whole new range of functions that leave local computing in the Dark Ages. Surely a modern app is just gateway onto these processes, a convenient way to consume service through the native UI rather than the core proposition.

So why not make the installation free and charge for the value item - the backend service.

For example;
  • You can install the graphics app but to save the output to cloud storage and to gain access to the teacher dashboard you need to licence the Google account. 
  • You can install the language app for free but integration with Classroom and the features set that provides student metrics needs a subscription.
  • The science app needs a user licence to enable results to be shared with your project team and to work collaboratively.
All the licencing is handled by a supporting SaaS platform, hooking directly into the cloud directory. Providing a backend service adds an overhead but this shouldn’t be too much of an obstacle for a business that plans to sell tens of thousands of units into education. Doesn't everyone want to build a ‘platform’ rather than just an app ?

What are the advantages.
  • Deploy the app using a simple whitelist. Users can install and uninstall as required. 
  • You don’t need groups and the Google OU model works just fine. A quick check against the directory will confirm user access. If not, you just get the try-before-you-buy option.
  • Licences are based on active user accounts rather than device installs and can be automated against the directory service.
  • Schools gain analytical data from the app instead of a simple desktop process. Surely this is where the true value lies for education.
  • The model works fine in a BYOD rollout while local licencing just creates a heap of issues.

Local licensing for shared devices forces the store model to support a scenario for which it’s completely unsuited. The result makes deployment far more complicated than it needs to be and only succeeds in placing a barrier between the app and the educational consumer.  SaaS  has been using the “freemium” model for years and it’s been very successful, why should local apps be any different ?

I’m concerned that a lot of time and effort is going to be spent trying to make Play for Education V2 work for schools, only to see fail for the same reasons as the initial attempt or simply becoming irrelevant. Without having any data on this I suspect the most popular Android apps installed on Chromebooks are the productivity tools from both Google and Microsoft Office 365 - which use exactly this model.

With everybody on the information super-highway speeding towards on-demand access and subscription billing I have a feeling that the pay-to-install model might just end up as roadkill.

Friday, 27 April 2018

SSO from Chromebooks to Azure AD.

Following on from a recent post showing how to auto-provision users from Azure to Google G Suite it seems like a good idea to complete the picture by describing Single Sign-On (SSO) from Google to Azure AD. The idea is you can pick up a Chromebook and be presented with a Microsoft dialog rather than the standard Google login challenge.

Like the user provisioning example this procedure does not require local federation (ADFS) but relies on the equivalent cloud based service bundled with the Azure AD Free and Basic tiers. Under this arrangement users can get SSO access for up to ten apps which is pretty generous as the whole of Google G Suite is considered to be a single app.

For this example we’ll use the xmastaff@xmaacademy.org, account that the Azure provisioning service created for us in the earlier blog. It follows that the xmaacademy.org domain must be configured in both Azure and Google and the user account logon name is the same on both systems.

The configuration setting for both auto provisioning and SSO can be found in the Azure Portal under 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 some basic config  details and name the service. Once you are back at the main menu you can configure SSO which turns out to be quite straightforward compared with working with ADFS.


From the drop menu select SAML-based Sign-on. This creates a whole range of input boxes.

The key fields are Sign on URL and Identifier which can be customized to suit your setup. The data below worked for me.

Sign on URL: 
https://apps.google.com/user/hub

Identifier:         
http://google.com/a/.*


From here the default settings should suffice. Make sure that the User Identifier is set to user.userprincipalname.



In the SAML Signing Certificate section check the box Make certificate active and save the config. Download and store the certificate (*.crt) that’s created for you.




All that’s left to do is to collect some information and transfer this to Google, luckily Microsoft makes this pretty easy.  Clicking on the section below provides a simple tutorial on how to update Google G Suite.



The key information you need is conveniently listed in the Quick Reference section towards the bottom of the help dialog.



The values will be different for your Azure tenancy but you will need both URL’s and the certificate you downloaded earlier before heading off to the Google Admin console.


Configuring G Suite and Chromebooks for SSO.
Single Sign On  is managed under the Security icon within the Set up single sign-on (SSO) section.
One note of warning, currently its not possible to turn on SSO for a subset of Google users. Continuing down this route will  require all your non-admin G Suite users to authenticate with their Azure AD credentials


In the dialog shown above paste in the URL’s into the relevant fields  and upload the certificate. The Change password URL is standard for all configs:

https://account.activedirectory.windowsazure.com/changepassword.aspx

If you encounter errors, try saving each entry in turn. In particular the certificate upload seems to work better as a single load and save action.

When you are ready, check-in the Setup SSO option but be aware this action will affect every account in your organisation. Unchecking the option turns off SSO without the removing all the data.

As a simple test, logging into the Chrome browser will now pass the request to Azure for authentication. Once you have that working you can prepare the Chromebooks to accept third party authentication by setting some some additional device and user policies.

In Chrome Management  - User settings search for "SAML". Enable SAML-based SSO and set the logon frequency.



In Chrome Management  - Device settings search for "SAML" again and allow users to go directly to the SAML SSO page.



So long as the user and device are within the scope of the new policies the chromebook will now present the Microsoft Azure login page instead of the standard Google dialog, which I must admit looks a little weird when you first see it.



Remember, authentication takes place against the Azure directory - so the user account needs to be in Azure with a matching account in Google to provide the user policies. Typing in a valid Google account without an Azure account won’t pass the test. In the same way trying to gain access using a valid Azure account that does not match an active G Suite account gives a Google error.



Conclusion.
The whole process is pretty simple and allows Chromebook to authenticate against Azure AD (MS Office 365) without requiring local servers and the complexity of ADFS.

However the big advantage of running  federation services in the cloud is fault tolerance.  Creating a highly available cluster to support a tier one component like authentication is not something schools should be doing anymore.  Federation is just a cloud service like everything else, you might as well make use of it.

So can you do it the other way round, use the Google SAML federation services to answer for Azure logins?   Unfortunately the answer is "not really" and certainly not in a supported manner.

Although Microsoft Azure can quite happily defer to any number of third party identity providers, Google isn’t on the list so there’s little chance of seeing a Windows 10 device sporting a funky Google logon in the short term. Pity!


Thursday, 5 April 2018

How to drop Windows apps on a Chromebook.

Here’s something to consider over a coffee: What does a Microsoft Windows computer actually do?

Since the majority of school computers in the UK run Windows and a lot of time and money is spent keeping those devices working you would hope it’s something pretty important.

Perhaps it’s keeping all of your files and data safe ?

That’s true but security and file storage is actually managed by the backroom server while file management is a standard feature of every mainstream operating system, just like printing and browsing the web. These are important functions but any desktop (or mobile) operating system could fulfil those roles. So what’s the answer ?

The fact is, you need a Windows computer to run Windows programs.

All the other stuff like virus protection, security patching, backup and all the fancy user interface features and dialogs just allow the operating system to run Windows programs in a secure and predictable manner.

It’s been a long time since the Windows operating system  itself added anything useful to the user experience (Minesweeper?). In fact the main challenge for the school administrator is to lock-down the desktop to ensure users have as little contact as possible with the underlying feature set.

I suspect the ideal configuration for a Windows desktop in schools would be a template of shortcuts linked to the main productivity apps with some additional icons for logging off and rebooting.

Even with this minimalist approach the network admin still has to deploy and update each application while making sure an installation of one application doesn't break all the others as well patching the underlying OS.

Over the last decade there have been multiple attempts to fix this problem including terminal services and VDI but in many respects they only make the problem worse. You have to add additional server hardware, manage even more instances of the operating system and, after all that effort, the local desktop doesn't even get the chance to do the one thing it's good at - which is running Windows programs.

Let’s be honest if you were starting from scratch you’d think of a better way of doing this.

So lets kick the bucket and think about what that alternative might look like might look like.


The local device would be lightweight, easily managed, simple to licence, fundamentally secure, self maintaining and provide the base functions of file management, print and web browsing.   The system should start quickly, present a security challenge and then simply act as a platform to launch the apps that you need to do your work done. In many respects you are describing Google’s Chrome OS, the operating system that runs on a Chromebook.

Alternatively this imaginary device could be running Windows 10 S mode which is basically a Windows 10 Pro with a simplified, locked-down configuration which also meets some of the criteria listed above,

Unfortunately the one feature that both operating systems lack is the ability to run the type of legacy Windows program that education uses on a day to day basis. Chrome OS is a non-starter for this purpose and in order to run a local copy of SmartNotebook or a specialised STEM program on Windows 10 S you have to upgrade to the Windows 10 Pro edition which takes us back to where we started.

On the face of it the problem seems unsolvable but there may be a solution on the horizon.

Purchase a Chromebook today and it can run any Android app from the Google Play Store. The Android Skype app knows nothing about Chrome OS and believes it’s running on fully featured Android stack (V6.0 Marshmallow).  In fact it’s a clever trick that makes use of technology commonly described as containers.

Containers allow the underlying OS to present itself in different ways to processes that it’s hosting. The idea is similar to machine virtualization but in this case it not the hardware that virtualized but the operating system kernel and for this reason is very lightweight and carries few additional overheads. This is how a Chromebook with only 4GB of memory can appear to run two operating systems at the same time. Another important feature of a container is that it ensures the isolation of the running processes which means it’s very secure.

So if containers can represent an Android run-time environment what else can they do?

Recent articles suggest that Chromebooks will soon have the ability to present Linux as a container which means that schools could safely access a range of open-source software rich in code development and media editing titles.

Which leads to the final point - could Chromebooks run a Windows application in a container?

The answer appears to be a qualified yes.
Recently Droplet technology announced a deployment package that can do just this. The hosted applications behaves exactly as it would if it were running in on a Windows operating system  - because it is.

All the technology runs locally and works without an active internet connection.  It’s not an emulation or a graphical offload, the application runs natively and is responsive and fully featured.

But let’s bring the conversation back to reality. If you have a school whose curriculum is based heavily on MS Office and locally installed Windows applications then your future is best served by the toolset provided by Microsoft.

But for schools moving towards SaaS the technical direction is often blocked by a dozen or so Windows programs that are central  to the curriculum. This is a problem that a container technology like Droplet could easily solve.

Eventually containers could be used to deploy applications across a range of OS types (including Windows) creating a true ‘run anywhere’ solution that doesn’t require a mass of backend server hardware.

There are still a number of problems to overcome, mainly around managing resources on a shared deployment but the future of local applications lies with containers. It’s a proven technology that underpins most cloud services and its about to make a splash in the mainstream market.

Tuesday, 27 March 2018

Synchronizing cloud directories - Part 2



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.

What are the options if you want to use Microsoft as the master directory and automatically create users in Google G Suite?
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 sync?  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. I haven’t tested this but I see no reason why you couldn't connect a single Azure domain to many Google organisations, each controlling a separate custom domain.

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.



Sunday, 18 March 2018

Synchronizing cloud directories - Part 1

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.

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