Saturday, 23 March 2019

Using cloud identities to access local resources

When considering the move towards a cloud (SaaS) based solution one irritating problem always remains - local file shares.

The concept of data sharing from a local server has been around for so long it’s hard to recall a time when it wasn’t possible and for organisations attempting to shift resources to the cloud it creates a real challenge.

Anybody following Microsoft roadmap towards a modern subscription service will have noted some limitations when dealing with local resources  If I take a Windows 10 laptop and place it under management with Azure Domain join and InTune I have a fully functioning device that works brilliantly within the context of modern web based services using authentication mechanisms like SAML but when I ask my cloud based Office 365 account to access a local file share or send to a printer that is protected by a local AD account and a Kerberos token things don’t work so well.

However a recent announcement on the Microsoft forums may have made things a little easier.

Any Windows 10 device that is Azure Active Directory joined can now access local resources so long as they are running Azure AD Connect to provide the link between the two account systems. No other software (ADFS) or configuration is required as the magic is baked directly into Windows 10. Although the post references Office 365 for Business I’m assured that the feature does extend into the education offerings.

The requirement to run Azure AD Connect is unlikely to be much of a barrier. Most schools using Office 365 already use Azure AD Connect to push account information out from Active Directory. This means schools can start to adopt modern management practices and transition data into OneDrive and Teams while continuing to use SMB shares until the day when last server is turned off. Hopefully that day will come very soon.

Of course clients need to be running Windows 10 and the latest version of Azure AD Connect but with the end-of-support date for Windows 7 under a year away this is an issue schools are facing anyway. This welcome feature just gives them one more reason to make the move.

Monday, 18 February 2019

Application access using groups in G Suite

Managing application access through the organisational tree in G Suite is both a blessing and a curse.

On the plus side it’s a simple, easy to use framework which has proven extremely effective in deploying dozens of applications across thousands of user accounts with minimal management overhead.

On the minus side it has one major weakness that has been detailed in a number of posts. The organisational tree cannot support a situation in which a user is a member of many different sets. For this reason it’s not possible to deploy an app to just the students in the History Class in Year 10. To deploy an app to a subject set you need a one-to-many relationship and that can only be done through groups.

Other platforms such as InTune for Education use this approach as do many other MDM platforms including Google's  Mobile Manager. That’s not to say groups don't create their own unique management issues but the point remains that to deploy subject based apps you need groups.

Fortunately allowing groups to control app deployment is a feature that has recently made an appearance in the G Suite Management console. So are the problems solved ?

The first thing to know is that the type of group used to control app deployment cannot be defined using Google Groups for Business (GG4B) but must be created using either the Groups icon within the admin console or through the Directory API. For this reason groups maintained using Google Cloud Directory Sync and most other third party products will work fine. Once created they can be managed through GG4B. Nested groups are supported.

The second thing is that groups can only be used to turn apps ON. This means that groups only have an effect if the sub-OU holding the user account sets the app to OFF. In this case the group setting (ON) overrides the sub-OU setting (OFF).

This might sound a bit limiting but that's not really the case.

Let's take a few examples.

Task 1: You need to turn on Blogger/Sites/Hangouts for a 6th form Media Class that contains user accounts held in a number of different sub-OU’s. The default action is set lower down the tree and turns these items OFF for all students. Prior to groups this was a big problem. You could either turn it ON for students or tie yourself in knots creating sub-OU’s. Now you can just create a new access group called app_Media_Group drop and turn on whatever apps you need for that group.

Task 2: You’ve been asked to trial Classroom in your school. You need to grant access to two teachers who’ll be taking the English class and a member of the SLT team. The problem here is the teachers reside in an sub-OU with all the other teachers, the SLT team are in the parent OU and the students in a complete different part of the tree with 60 other accounts. You consider the OU approach before realising that one of the students is already residing a sub-OU Penalty Box and can’t be be moved. Groups to the rescue again.

While we are on the subject of a Penalty Box it might seem like a good idea to allow groups to  turn apps OFF as well as ON to cover exactly this scenario but when you consider ease of use that may not be the case.  Flexibility often brings more complexity and in this case I believe Google got it exactly right because even with the added group filter it’s still pretty to work out what policy applies to which app.

In this example we have turned Jamboard OFF for all users at the root but then enabled it for the group called groupwithbusinessoff.

The console immediately shows it as ON for some with the View Details link to break out the information you need.

To examine the apps from the user perspective you can use the Apps card on the user account dialog.

Dropping the user account into the groupwithbusinessoff group shows the app being applied for that single user.

Like most of what Google does, application control through groups is a simple idea that’s been well implemented, but could it be better?

At the moment groups can only be applied for G Suite and Additional Google Services but not Marketplace apps which are more likely to be subject based. Also there's no sign yet of group based deployment from the Chrome Store which would be a real breakthrough.

Lastly since membership of a group can now enable an app, why not a Google Classroom.

Now there’s an idea, over to you Google.

Friday, 18 January 2019

InTune for Chromebook Admins (p3).

Application Deployment.

In the last of three posts we take a look at application deployment using InTune for Education in a SaaS based school

Intune for Education (IT4E) can be used to deploy three types of application.

Web Apps. These are no more than shortcuts to web sites. If you have an externally hosted learning platform or any application that has a web front end you’ll use the web apps option to deploy the link.

Microsoft Store Apps. This feature allows you to install apps from the Microsoft Store for Education. All store apps use the Universal Windows Platform (UWP) which is a unified format for Windows 10, Windows 10 Mobile, Xbox One and HoloLens but not Windows 7. Therefore the school needs to be running Windows 10 to pull apps from the store. However since you also need Windows 10 for IT4E the two requirements go together.

Desktop Apps. Also known as Line of Business apps in the InTune console and probably Legacy Apps in the not too distant future.  These are the standard .msi deployment packages that have been around since Windows 95. Note that IT4E does not support .exe install packages, it’s the .msi format or nothing.

Deploying Apps.
Applications are allocated in the same the way as policy, through a hierarchy of groups. This strategy is a little more flexible than the Google approach which has only just started to adopt group based application deployment.  Another area where the Microsoft approach differs from Google is the ability to assign applications to devices. This has no counterpart in the Google world where user and device policies are strictly divided.

The application set that’s delivered to the user session is a combination of all the groups that reference both the user and device. If an installed application falls out out scope when a user or device is removed from a group the application will uninstall on the next policy refresh.

The end result is much the same as general policy management, you have great flexibility but this power comes with the ability to tie yourself into knots if you don't have a plan to start with.

First impressions working with app deployment in IT4E is that some tasks are really easy and other tasks are impossibly hard.

On the easy side, deploying a Desktop App (.msi) is a very slick process.  Fill in a simple dialog in IT4E and select the .msi file. The file itself is uploaded to a central data store within Azure which is provided as part of the platform and then pushed down to the user/device groups on a policy refresh. This works surprisingly well allowing for the time to reset the policy and to transfer the .msi data package. Web Apps behave in the same way except that everything works a little quicker as there’s no install package to move about.

Although the process allows you to select an icon for the application this only shows up on console itself and doesn’t get pushed down to the device as you might expect. This irritation will probably get fixed at some stage.

Deploying apps from the Microsoft Web Store requires an initial effort to set up the Store account for the school. Currently this can only be achieved using the Intune Azure interface rather than through IT4E. Until the store account is linked back to Azure the option remains greyed out in IT4E.

Once the account is activated the process involves selecting the app from the store interface and then synchronizing it with the InTune database so the application displays on the IT4E console. Once that’s done you are presented with the same group allocation model you have with Web Apps and Desktop Apps.

The synchronization between the Store and InTune runs as a background process so it’s unlikely that the app will immediately display in the IT4E console, just give it a little time. The full Intune Azure interface has an option to force a sync which is a benefit for impatient admins and it would be nice to see this feature in IT4E as well (above).

If these are the easy bits - what are the difficult bits?
  • You can’t install from a .exe file, a common format for legacy software and drivers.
  • You can’t place a link onto the desktop to create a customised user experience or do anything in the way of file management.
  • You can’t map Windows file shares.
  • Print support is underdeveloped at the moment.

Currently the solution is to create a Powershell package deployed through InTune or create an .msi wrapper. In fact just about anything is possible if you are willing to spend some time scripting but why make it so difficult ?

The answer lies with Microsoft's cloud focused vision. In the future you’ll be unlikely to map Windows file shares - you’ll use OneDrive. You won’t sideload local apps, you’ll download them from the Microsoft store or consume SaaS.  You won’t disseminate information by printing, you’ll share, publish and collaborate using Teams and you won’t be able to use the desktop as a filestore because the vision is cross platform.

These things are hard because by adopting the easier options you’ll be nudged towards Microsoft's cloud wonderland.

In conclusion let’s return to our Google administrator living in an alternative reality who has the job of integrating Microsoft's emerging technology into a serverless SaaS based school.

What are the principal features of Microsoft modern management platform that a Chromebook admin will have to come to terms with ?

  • A cloud based platform managed through a web interface without any dependency on local infrastructure.
  • Locally installed applications delivered using a store model.
  • Simple “lifetime” device level licencing as an option.
  • Close integration with a cloud based productivity platform to deliver LOB applications.
  • Strict application control limited to web links and store apps with restricted support for side loading.
  • A updated security model based on web open standards with backend integration into common SaaS platforms.
  • Reliance on a cloud based user directory that all also supports groups and devices.
  • Security patches and updates delivered centrally on a predictable release schedule.
  • Management controlled through a hierarchical policy set.

Does any of this sound familiar?  I suspect it won’t be too hard.