Friday, 13 December 2019

Cloud and multimedia - another hurdle falls.

For those schools considering a move to cloud storage there’s always been one hurdle that's been difficult to overcome - multimedia.

Whether it’s graphics, music, art or material design the nemesis of the serverless school has always been the manipulation of very large files by high end software packages normally running on Apple Mac’s or Windows workstations,

As previous posts have pointed out, using local storage is hardly an ideal solution. The ever increasing demand for storage has an impact on backup and disaster recovery plans and multimedia can prove a challenge to a mobile first, anywhere learning approach. Moving very large files across a network also requires a resilient high speed backbone but so long as you have the budget for fast switches, resilient storage, backup software and box full of data tapes, it’s a proven strategy.

One approach that can work well is to keep both the data and the processing in the cloud. The next generation of SaaS platforms may not match the advanced functionality of locally installed applications but they are ideally suited to the anywhere learning model and have proved very successful when matched with devices such as Chromebooks.

However, if the lesson plan requires branded specialist software which only runs on a high end workstation and generates files that are gigabytes in size, does that rule out cloud storage all together?

Well maybe not.



The technology behind synchronising cloud storage to local drives has come a long way in the last few years and has now reached a point where it can take on the challenge of large multimedia files. This objective was made clear at the recent Microsoft recent Ignite conference where some key updates to OneDrive were announced.

The popular cloud storage service is gaining support for larger file sizes, differential sync and new preview features.

Starting with the most obvious requirement, users can now upload files up to 100GB across a range of formats and are no longer limited to the MS Office standards.

Differential sync is one of the most user-requested capabilities for OneDrive and has been on the roadmap since 2017. This feature only transfers parts of files that have been changed which is clearly a huge advantage when working with large datasets. Currently OneDrive supports differential sync for the all the modern Office file formats but from December 2019 it will support all files stored in Microsoft 365.

Microsoft has written custom handlers for common image formats such as GIFs, JPEG and TIFF, audio/video media files such as MP4 as well as AutoCAD DWG which will substantially reduce the upload times as well as the consumed bandwidth. Now that differential sync can be linked to local caching this makes large files and cloud storage a practical combination for the first time.

One of the biggest advantages of cloud storage is the ability to share files between co-workers and external partners but this can be hindered by processes such as CAD/CAM  and image editors requiring their own viewing software. Fortunately the OneDrive web interface now comes with built-in preview tools which includes AutoCAD and support for 360-degree images. Microsoft will be releasing new viewers at regular intervals to further extend the current range of graphics handlers which includes  GIF, JPEG, JPG. JPE, MEF, MRW, NEF, NRW, ORF, PANO, PEF, PNG, SPM, TIF, TIFF, XBM, and XCF files.

Lastly, OneDrive's preview tools also offers basic editing features including the ability to add comments and annotate PDF files which is a useful plus for education.



Checking back on the blog history it’s been over five years since the first post appeared promoting the use of SaaS in education.

In 2014 a serverless deployment was possible but with certain technical challenges such as  the management of Microsoft desktops, print handling and third party integration with cloud directory services. Over the intervening period each one of these restrictions has been removed.  Now another hurdle falls with workable solution for manipulating large files directly from cloud storage.

It’s still not perfect but neither was placing a mini-datacenter in every school.

Saturday, 30 November 2019

Working with simple passwords in Azure AD.


Microsoft Office 365 (Azure AD) has a default configuration that requires complex passwords that are updated on a regular basis. Complex passwords are 8 to 256 characters that combine at least three of the following: uppercase letters, lowercase letters, numbers and symbols. This level of security is standard practice in a world where everybody has a responsibility to protect their digital identify.

However managing this type of policy in schools can be difficult, especially for early year groups. Complex passwords and enforced password changes are not something a teacher wants to face first thing on a Monday morning.

A policy that uses simple passwords progressing to more complex passcodes for older pupils often works better. Ever since it’s launch Google G Suite for Education has been using eight character simple passwords with a non-expiry policy to protect over 70 million education users, so it's hardly an unproven approach.

Microsoft's support for simple passwords normally involves syncing or deferring to local Active Directory using mechanisms such as Azure AD Connect or Active Directory Federation Server (ADFS) but in a serverless world you don’t have these options, Azure AD is the only directory you have.

One approach is to turn off password complexity for all Azure accounts but that seems a bit drastic. So how do you work with simple passwords in this situation?


Schools that have adopted Microsoft's Modern Management framework can manage Azure user accounts through at least four different web interfaces:

Each platform has a different user interface, navigation model, supports a different sub-set of functions and works in subtly different ways. So the first task is to choose the right portal for the job.

If you plan to do a bulk upload of a new user group using a formatted CSV file then this feature is available in the Azure Portal and the Office 365 Admin portal but not InTune for Education. To add a little more complexity, the format of the import csv file is different and the options vary between the two portals.


Office 365 Admin - Users


As well as creating a user account, the wizard provided by Office 365 Admin gives you the option to specify a licence such as Office 365 A1 but neither the file format or the wizard provides any control over the password format.  All accounts are created with complex passwords. You are also limited to 200 accounts in each import run.

After the import you have an option to download a spreadsheet that lists the accounts created and the passwords supplied so you can inform the users. Don’t miss this step as there’s no way of regenerating the sheet.



If you are in this unfortunate position you can select multiple users in the Office 365 Admin - Users panel and then choose Reset Password which gives you the option of emailing a new password list to an admin account but the result is not a neatly structured spreadsheet that you can use in deployment.


Azure Portal - Azure Azure Directory.



An extended format of the import file includes an option for the initial password but sadly not a licence allocation. Even though you can specify the password it still has to be in a complex format otherwise the import fails with the error.

“The password in the uploaded file does not meet password complexity requirements.”

In summary neither option gives you the chance to bulk create accounts with simple passwords.

Removing password complexity for an account can be achieved using the powershell command listed below. Unfortunately none of the web interfaces gives you this option as a simple checkbox.

Set-MsolUser –UserPrincipalName <UPN of user account>  –StrongPasswordRequired $false

However even after removing the strong password requirement updating the password using the web GUI’s still fails. The Office 365 Admin - Users portal checks for a complex password on data entry and won’t let you move through the wizard and the Azure Portal - Azure Azure Directory forces a temporary password that you can’t control, which of course is complex.

Back to square one - well not quite.

Although the InTune for Education (IT4E) portal provides a limited set of update features one of these is Reset password and this does allow you to set a simple password if the complexity rules allow.



However this option is only available for schools using IT4E and even then it’s hardly practical for a bulk update. Ideally IT4E would provide a simple import feature offering specialised options such as licence allocation, simple passwords, control expiry and a switch to choose whether “change at first logon” is applied.

However until that time, powershell is the answer.

The commands below will update a user account to remove password complexity, set a simple password and ensure the user is not prompted to change at first logon.

Set-MsolUser –UserPrincipalName user@myschool.com –StrongPasswordRequired $false
Set-MsolUserPassword -ForceChangePassword $false -UserPrincipalName user@myschool.com -NewPassword "ABC123abc​"

Probably the best approach is to create the accounts using the Office 365 Admin - Users portal, which gives you the option to select a licence level and then run the commands above on each account to prepare for student use. If you are working with a whole year group is easier to create a CSV file with the user UPN and the password as a data pair and then run the commands as a batch job.


Install-Module MSOnline
Set-executionpolicy RemoteSigned
$credential = get-credential
Import-Module MSOnline
Connect-MsolService -Credential $credential

Import-Csv students.csv | ForEach-Object { 
Set-MsolUser –UserPrincipalName $_.UserPrincipalName –StrongPasswordRequired $false -PasswordNeverExpires $true
Set-MsolUserPassword -ForceChangePassword $false -UserPrincipalName $_.UserPrincipalName 
-NewPassword $_.Passcode
}

Example CSV File (students.csv)

UserPrincipalName, Passcode
user@myschool.com,ABC123abc​
user2@myschoolcom,123aaa321

The script also sets the password to never expire. Generally you don’t want students changing passwords 'en masse' during term time.



Any IT admin with experience of the simple yet powerful G Suite user import feature will probably find the multiple Microsoft options a bit confusing at first.  It would certainly make things a lot easier if the InTune for Education interface could offer some of the password management features mentioned above.

However the important point is you can get a simple password policy to work, it's just a shame it's so complex.

Sunday, 27 October 2019

Chromebooks and Azure SSO revisited.


The post describing how to integrate Chromebook Single-Sign-On (SSO) with Microsoft Azure AD (Office 365) remains a popular topic . It's been a permanent fixture at the top of the "You liked these" list for quite a while now.

Unfortunately, although the process is essentially the same, the Azure interface has received a complete overhaul during this period. As a result, anybody trying to follow the post as a step by step guide to setting up SSO for Chromebook is likely to be a little confused.

Therefore it’s probably a good time to revisit the procedure and take the opportunity to list some tips and tricks. To Microsoft's credit the new interface is far slicker and easier to navigate so there really no excuse in delaying getting your Chromebooks working Azure AD directory.

Note: At the point of writing Microsoft are in the process of rolling out another update which is currently in preview.

In this example we’ll set up SSO for a fictitious school (MA Academy) that has a Google organisation on the primary domain maacademy.org. The Azure directory must also hold maacademy.org as a registered subdomain.

Setting up SSO requires access to the Azure portal for your Office 365 tenancy but once logged in there are no additional licensing requirements. In the Azure portal search for  "Enterprise” to bring up the Enterprise Applications blade and select + New Application.

This will take you to the Application Gallery where you have access to over 1000 templates for ready-to-use SaaS solutions. Google can be found by searching for “G Suite” and finding the application shown below.



Selecting the icon allows you to name your new application and then select Create. It can take a few minutes to build but once complete it will be displayed in the main list of all Enterprise Applications.

Note: If your organisation employs a large number of SaaS apps you may have to use the search option as the app list only displays the first 50.

Selecting the new app opens the Properties blade. Although there’s a lot of information here, most of the fields default to the correct values so there’s not much work left to be done. We’ll come back to this section later.

Next, select the option for Set up single Sign on and select the SAML card.


As you will notice only a few fields are marked as required,  in most cases the default values will suffice.

Two items that are required are Identifier (Entity ID) and Sign on URL.

The Entity ID is a URL passed by Google that identifies it to Azure. It’s possible to have many Google organisations linked to a single Azure tenancy. In this case each would have their own application with a unique Entity ID.

In most cases the format below works well for this purpose.

google.com/<your primary domain>

Example:   google.com/maacademy.org

It’s important to note that the domain MUST be the primary domain for the Google organisation even if you only plan to authenticate accounts in a secondary domain.

The other defaults can be accepted except for the Sign on URL which must be updated to include the G Suite primary domain and perhaps be pointed away from mail or drive as the signin target. In schools that are adopting Chromebooks as platforms for Office 365 is likely the Google Gmail and drive services will be disabled. In this case it makes sense to use the account info site as the sign on URL as this will be available for all active Google accounts.


https://www.google.com/a/<your primary domain>/ServiURLceLogin?continue=https://apps.google.com/user/hub




The default settings in the user Attributes and Claims section are suitable for most installations. One exception is for schools that don’t use the user MAIL attribute to store the G Suite logon identifier. Where user principal name attribute is used or some other custom field is employed  the emailaddress claim name will need updating otherwise you will face an “email invalid’ error on logon.


After this has been done you may need need to review the value of User assignment at the base of the Properties dialog.


If you select ‘Yes’ users must have the app explicitly allocated to them otherwise authentication will fail with the error “User is not allocated to this application".

The relationship can be made through group membership or by applying the app to individual accounts.  It’s sometimes useful to apply the app to a user account when you are in a testing phase however it’s likely a school will want all Chromebook users to be authenticated with Azure so this property is more commonly set to No.

That's pretty much it. All that remains is to pick up some information from the Set up G Suite Chromebook SSO card and head on over to the Google admin console.




You will need the data from the Login URL and Logout URL and the Certificate (base64) from the card above.

Fortunately the Google dialog for setting up SSO in the Security section of the admin console remains unchanged.





Paste the Login URL into Sign-in page URL,  Logout URL into Sign-out page URL and copy the data below into Change Password URL.

https://account.activedirectory.windowsazure.com/changepassword.aspx
`
As a final step upload the certificate file downloaded from the Azure portal, check the option for Use a domain specific issuer and save the dialog.

A word of warning here. The option to turn on SSO (Setup SSO with a third party identity provider) will apply to all accounts so it’s best to test it out first. The easiest way to do this is to limit the action of SSO to the IP address of your test Chromebook.  You will need to add the IP address into the Network masks field using the format below and substituting in your local value.

XXX.XXX.XXX.XXX/32

Example:   10.4.34.123/32

The device and user policies to enable the Chromebooks for SSO are well documented by Google and the previous blog but before you update these settings it’s a good idea to check the config by logging in through a Chrome browser session. Once you have that working you can setup your Chromebook.

One last tip. Don’t test this with a G Suite user that has admin rights as these do not respect any of the SSO settings by design.

Good luck with your Chromebook SSO project. Although keeping up to date with the user interface updates can be a bit of a chore the changes have resulted in an environment which is a lot easier to manage and configure.



Other Information:
Microsoft have a useful how-to document you can reference which goes into more detail and also covers user auto-provisioning.