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 The Azure directory must also hold 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.<your primary domain>


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.<your primary domain>/ServiURLceLogin?continue=

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



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.

Sunday, 22 September 2019

Is the File Server EOL ?

Previous posts have examined the problem of incorporating traditional file shares into a serverless solution, exploring such issues as;

  • How do you share files when you don’t have a local server ?
  • How do you apply a cloud based security model to a platform that only understands local Active Directory?

Although several solutions have been proposed it turns out there’s a simple answer - don’t use network file shares.

Before we examine the alternative it’s important to appreciate how long the F: drive has been with us and how deeply ingrained it is into the IT psyche. For most users file sharing is what a network does. This may be the reason why we have failed to appreciate how completely unsuited it has become to modern work practices.

The standard Windows file share has a list of limitations that is both long and varied.

  • No easy offline sync or mobile access.
  • No file versioning.
  • No recycle bin
  • No retention policies
  • No event logging
  • Poor search functions.
  • Poor integration with cloud based user directories.
  • Primitive document sharing using simple file locking.
  • Requires a high availability, backup and disaster recovery plan.

And of course file sharing depends on a server that requires patching, licencing, upgrading and monitoring.

Most, if not all of these limitations can be eliminated by employing more software or additional hardware (which also requires patching, licencing, upgrading and monitoring) but in the end you’ll still be left with a complex second rate solution that’s not flexible enough to meet the needs of a mobile workforce. Let’s face it, the F: drive has had a good run but it’s time to search for an alternative. So how do you replace the file server in a modern workplace that has no servers.

The first clue was when Dropbox started to appear on work PC’s synchronizing cloud storage to the local drive. Since then this model has been refined and extended by both Microsoft and Google and now it’s ready for prime time.

In the future, Microsoft expects you to access files through Team channels which act as a front-end to Sharepoint document libraries. The Sharepoint engine provides all the elements missing from files shares including content search, a recycle bin and a comprehensive versioning journal. Event logging and retention policies are other quick win. The close integration with the Windows10 OneDrive client allows the user to control synchronisation to the local device.

Clearly the sharing capability, collaborative workflow and mobile integration is light years ahead of a simple file share but perhaps the breakthrough feature is the ability of the OneDrive client to expose the Team channel within File explorer.  In many ways the user experience is identical to using file shares and therefore it can provide a clear migration path for organizations that want to move to a severless solution without significant retraining around new applications and the use of a web interface.

Because Microsoft are using this framework as the foundation of M365 these capabilities are baked directly into Windows10. So why not take the opportunity to trial these features as part of your Windows10 migration and ditch those servers.

Coming from the Google world this will be very familiar - being completely cloud based G Suite users have been working this way from day one. Versioning, collaborative working, extended search and mobile integration have always been part of the package. Google Vault provides the retention, legal hold and e-safety features while the G Suite admin consoles gives you the capability to report on file access.

In addition Google File Stream mirrors the features of the OneDrive client exposing Google Drive in File Explorer as a mounted drive and allowing direct access from native applications like MS Word and Photoshop.

The obvious conclusion is that both the major payers are offering the same solution. You can have the Microsoft version or the Google version but it’s essentially the same vision.

You still have local files, they are just delivered in a different way.

Instead of one central device that needs managing, protecting and opening out to external access you have a central cloud store backed by elastic storage that replicates data down to each personal device regardless of the location and platform using intelligent algorithms that determine the precise requirements of the user.   Data can be protected, ring-fenced and be subject to centralised retention policies.

Contents of the files can now form a valuable data resource that can be subject to big data analysis rather than offering up a simple list of file names. Onsite backup and disaster recovery plans are a thing of the past. It’s a modern data management strategy.

It’s unlikely that file servers are going to disappear overnight. They’ll hang around in the same way that one-task physical servers persisted in the face the face of virtualization but in the end they’ll go because, like virtualization, the alternative is better.

Saturday, 3 August 2019

Using Azure AD credentials with RDP.

As schools start to deploy InTune managed Windows10 desktop with an Azure based user directory a few interesting challenges emerge.

One of these is remote support of Azure joined Windows10 desktops using the RDP client. Using the default settings, the Azure AD (AAD) account credentials are rejected by the client dialog which stops the process in its tracks.

So how can you RDP into an Azure joined Windows10 device using your AAD user permissions?

The first job is to disable Network Level Authentication (NLA) for Remote Desktop Connection on the target Windows 10 computer.

Open System Properties and navigate to the Remote tab. Under Remote Desktop make sure Allow remote connections to this computer is enabled, and that Allow connections only from computers running Remote Desktop with Network Level Authentication is unchecked.

The second task is to edit the .rdp file you are using for the connection so it looks like this

full address:s:<ip address>:3389
authentication level:i:2

These settings disable any credentials being sent to the host computer.  As a result the host will be forced to present the logon screen rather trying to create the session prior to connection. This way you have the opportunity to present your AAD account details.

Now you will find that entering the AAD details in the logon box will open up a desktop.  This works fine with all accounts that have local admin rights but what if you try with a standard user account. You’ll find you get a rejection notice informing you that the user does not have the rights to a remote session which is expected as they are not a member of the Remote Desktop Users local group.

Opening up Local Users and Group MMC console on the console doesn't help you as there’s no way of selecting Azure AD as a source. Fortunately you can add users from Powershell.

Open up a powershell session with admin privileges and type.

net localgroup “Remote Desktop Users” /add "AZUREAD\"

You should get a “Command successful” and the user account will be listed as a member in the Local Users and Group MMC console. The next RDP session will work as expected. The same technique works for any local group that needs to transfer Azure AD account rights.