tag line

moving IT to the cloud with service not servers

Monday, 7 January 2019

InTune for Chromebook Admins (p2).

Understanding user policy management.

The key to mastering Intune for Education is understanding that policy is filtered through a hierarchy of groups. This is a fundamental difference between MS InTune and Google G Suite.

In G Suite, policy is applied using a simple parent-child folder tree that’s constructed by the admin user. A user or a device (chromebook) can only exist at a single point in the the tree. Policies flow up from the root to the branch of the tree where the object resides. If the user or chromebook is moved from one sub-OU (branch) to another the policies are updated in a consistent and predictable manner.

With InTune you still have a hierarchy but it’s a hierarchy of groups and since an object can exist in many groups it’s possible to create a structure that places an object at multiple points in the tree. While this model provides a level of flexibility that can’t be matched by the Google system it can create extra complexity if you have many groups and many branches in your tree.

For both platforms it’s best to keep it simple but that's particularly true for InTune so let’s see how this might work with out new InTune user Joe Schmoe.

Each InTune group has a built-in tab that lists it’s configuration settings in the same way that the User Chrome Management in the G Suite console presents a list of options.

The major difference between the two approaches is that with Google you navigate to the object you wish to manage (G Mail, Chromebook Devices, Calendar), open the settings tab and then select the point in the OU policy tree you wish the setting to apply..

With InTune the settings are embedded into the group itself and not the service and this creates a number of challenges for the administrator.

The most obvious one is that settings tab must contain a link to every possible value you can set in a policy.  At the moment this is fairly manageable but if the list ever expands to anything close to the number of options available to the G Suite admin it could get quite ugly. Fortunately Microsoft has provided a search facility that works in the same way as some of the larger G Suite config lists. I can see this becoming essential.

The situation is compounded by the fact that a group can contain both users and devices and therefore the policy list must contain the settings for both. The settings tab has a pulldown section labelled Windows Device Settings (above) but this also contains user profile settings as well.

For the full confusion effect if you open the settings tab for the built in All Users groups you are still only presented with the Windows Device Settings pull down. Renaming it to Windows Settings would help as would breaking the policies into two discrete sets in the same way that G Suite works.
Which brings me to the next point. Because the policies are mixed it’s difficult to know which are controlled by the user object and which by the device object. If Cortana is turned ON by group user policy but then turned OFF by a Device group policy in a higher level group, which takes precedence? Where this gets really hard to comprehend is when both the user and device are members of two entirely different policy trees and so you’re unable to use the position in the tree to work it out. Let’s see how this could happen and what you can do to avoid it..

First we need to understand the role of the two built-in groups All Devices and All Users which sound like they would sit at the root of your policy tree but of course being Microsoft, they don’t.

Both groups are system defined which means the membership cannot be edited and user defined groups can’t sit above them to inherit policy. So both groups exist in quiet isolation. The main use is to act as the default policy set for any user or device not immediately assigned to a group, a sort of catch-all template policy. If you have a simple setup you can use these groups to push configurations out to your entire estate of users and devices in one easy step which is a great alternative if you wish to avoid the complexities of a group hierarchy.

Nested group policy only applies to user defined groups, so let's create a group called All Students and turn Cortana ON for that user group. You can now create another group called Year 10 as a child of All Students and you’ll see this automatically inherits all the settings of the All Students group with Cortana turned ON. However you can edit the settings for Year 10 to turn Cortana OFF overriding the inherited settings from All Students .

So Joe Schmoe could be in three groups.

  • All Users  - Cortana turned OFF.
  • All Students  - Cortana turned ON.
  • Year 10  - Cortana turned OFF.

To find out whether Joe has access to Cortana you need to know which groups Joe is a member of and how those groups interact. Simply checking that Joe is a member of All Students where Cortana turned is ON tells you nothing because he could be a member of another group higher up the tree where Cortana is turned OFF.

And then it gets really complicated because you also have to consider that the device that Joe is using also has it’s own policy tree which could be completely independent of Joes groups and even fixed to a completely separate group at the root.

So when you turn on the computer is Cortana going to turned ON or OFF?

There’s no way of viewing  the resultant set of policy (RSOP) from the console so it’s quite easy for incompatible settings to be applied to the same group. These inconsistencies result in errors when a user or device is being set up with different settings in multiple places.

For example let’s assume Joe is a member of the Year11 group and is also a member of the Geography group. If you configure a homepage setting and assign to Year11, and you configure a different homepage setting and assign it to Geography, Joe has two conflicting homepage settings which leads to an error. Microsoft have thoughtfully provided a report that lists those errors - the group settings errors report.

I suspect any admin trying to implement a fairly complex group hierarchy is going to spend quite a while going through those reports.

Alternatively it might be a better idea to adopt a system that avoids the problem in the first place, so how do you do that?

First understand that although the All Users and All Devices groups are useful tools if you need to differentiate policy between sets of users and devices they are of no real use.

So as a first step create a new root group that represent your school and call it ITE-MySchool for example. Two important things about this group. Preface it with something like ITE so it can be easily identified as a policy group and then invest some time transferring the settings from the All Users group into it as nothing is set by default. Don’t put any users or devices in this group.

Create other groups such as ITE-All Students and ITE-All Staff in the same way.

Organise these groups into a structure that makes applying policy easy to manage using inheritance to do most of the work. Try and set the majority of settings close to the root group.

When you have finished you have created a policy tree but without any objects.

Now drop your production user and device groups (Year 11) at the point of the tree where you want policy to be applied. Unlike the ITE groups you never set policy on these groups that hold users or devices, they are just containers into which the policy flows.

As users are added or removed from the production group the policy will change without any intervention on your part. At the end of year simply move production groups to a new point in the policy tree to allow the inherited policies take effect.

Google admins will recognise this pattern from the G Suite org tree. Working with InTune we are simply replacing sub-organisations for groups and then making sure that a device or user only ever exists within one group in the tree. That way you can ensure consistent results and you have a system that’s far easier to troubleshoot... and it works just like Google.

Saturday, 1 December 2018

InTune for Chromebook Admins (p1).

Enrolling Devices.

One of the advantages of deploying Chromebooks into schools is the ease of management. With no dependency on local infrastructure and a simple to use web management console, installing and configuring Chromebooks couldn’t be more straightforward.

Wouldn’t it be great if your Windows devices worked in the same way? Well with Microsoft’s new SaaS based framework maybe they can.

In this series of posts I take a look at Windows Modern Management from the point of view of the Chromebook administrator and just to make it interesting lets jumble things up a bit and assume Chromebooks are the established technology.

In this alternative reality Microsoft Windows is the new kid on the block and you have the job of incorporating this feisty newcomer into your serverless SaaS based school?  So let's take the red pill and wander around this particular wonderland just to see how far we can go.

Windows Version.
Fortunately our imaginary school has invested in a batch of Windows 10 laptops all running the 1809 feature update. You can try this trick on your IT suite running Windows 8 but I suspect you won’t get very far. After all you wouldn’t expect a set of Chromebooks running version 55 to support all the functions of admin console and Windows is no different.  So the first step is to make sure you have the latest Windows 10 release.

User Accounts.
Currently Windows devices only authenticate through a Microsoft user directory. So as much as the Chromebook admin would like to see a Google dialog logon on boot that’s not going to happen soon. For this reason all your users will need a Windows Azure account to control the access rights and licensing. This really shouldn’t be a surprise because all SaaS services work by referencing some form of local account even it authentication is managed by another party. Although you can force Chromebooks to use Azure AD as an authentication source you still have to maintain a separate Google user account to apply policy.

Web Management.
Google provides a web based management console that controls all aspects of the User and Device policy for Chromebooks. Microsoft's counterpart is the InTune for Education portal.  The first thing any G Suite administrator will notice moving into Microsoft’s wonderland is the fact that many of the  management functions are split between various web portals, all having different navigation styles and UI layouts.

The InTune for Education portal is itself a simplified ‘skin’ that rest on top of the InTune blade in the Azure console.  In this walkthrough we’ll stick with InTune for Education unless we’re forced out for some function. Right on cue the first one of these is user and licence assignment which is not managed by InTune for Education but the Office365 portal.

For the records the Windows Administrator will be spending most of the time moving between the following portals.

Office 365 - User management and Licencing
InTune for Education - General Device Management
Azure Portal - Advanced Device Management
Microsoft Store for Education - Application selection and authorization.

Licencing Chromebooks is easy. It’s a one-off device licence that’s valid for the life of the Chromebook. This simple relationship has not been lost on Microsoft and they have a direct equivalent, an InTune device licence that lasts for five years. The cost  is roughly equivalent and it gives you the ability to apply policy to the device and any organisational user account logging onto the same PC/laptop. It’s a very good deal and highly recommended.

Unfortunately that’s the end of the good news because although the device licence exists and can be purchased there’s no way of applying it to a device. It’s almost like the licence has been released to meet a marketing need before the software exists to support it. No doubt this will be fixed in time but currently the failback is to apply inTune license to individual user accounts and that’s done though the Office365 portal.

Enrolment and DEM accounts..
We now have user accounts set up in Azure and InTune licences applied to those accounts so lets start enrolling some devices. Google admins will be familiar with the fact that enrolling Chromebook out of the box is pretty easy and an small cottage industry has grown up to support the mass deployment of Chromebooks. In comparison the InTune enrolment experience takes a bit longer but on the whole is pretty slick and surprisingly straightforward.

Microsoft have a new facility called AutoPilot which we don’t cover here. It’s the equivalent of a Chromebook white-glove service working through the partner channels.

The first thing you will need is a device enrolment manager (DEM) account. Unlike G Suite where any user account can enroll a Chromebook, you need a user account with a special deployment flag set to enroll devices in bulk. Once created and with an InTune user licence applied you can enroll up to one thousand mobile devices using a single DEM account. The InTune for Education portal provides simple dialog to create and manage Azure enrolment accounts.

Once we have our DEM account created we are ready to enroll.

Power on your new Windows 10 device and move through the OOBE inputs. Set any dialogs regarding language and network access and select Set up for an organisation which is the the Windows equivalent of Ctrl -Alt-E.

Signing in using the DEM account adds the device to the Azure directory and places it under InTune management. Once rebooted you can logon using any organisational account with both device and user policies applied. Pretty simple.

Opening the InTune for Education portal you’ll see the appliance listed in the All Devices section along with some basic system information. The managed by field should read MDM.

The check in time records the last time the device took policy from Azure. A sync can be forced at any time and is a useful way of getting changes out to the devices on a short schedule. The time taken to apply a policy update can vary from seconds to a long coffee break so the ability to force a sync is a useful tool.

Opening the device record displays further information and options that would be familiar  to the the Chromebook manager.  The Retire action is the equivalent of deprovisioning in Chrome with one major difference, the licence is returned to the pool.  The admin also has the option to force a restart of the device, wipe the PC of personal data and return to factory default settings - a sort of remote Esc-Refresh-Power.

Hidden under the More button are actions to force a virus scan of the device and update Windows defender, duties that the Chromebook admin doesn't have worry about but essential tasks for the Windows admin.

The device action panel records the status and result of all active tasks.

Now we have the device enrolled we can take a look at policy management in the next post.

Next: InTune for Chromebook Admins (p2).

Also: Mapping Local Drives with InTune

Thursday, 1 November 2018

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

Single Sign On (SSO).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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