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.