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 tier. 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:         
google.com


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.

Optionally, check the Use a domain-specific issuer box to enable a domain-specific issuer. If you enable this feature, Google sends an issuer specific to your domain, google.com/a/your_domain.com, where your_domain.com is replaced with your actual domain name.

If you don't check the box to enable a domain-specific issuer when you set up SSO, Google sends the standard issuer, google.com as recorded in the Identifier field in the Azure section above.

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 and use the Google SAML federation services to answer for Azure logins?   Surprisingly yes.

It's now possible, under specific circumstances to logon to Windows using a G Suite account.

https://blog.theserverlessschool.net/2019/07/using-google-to-authenticate-microsoft.html




7 comments:

  1. Thanks for this guide, works like a charm.

    However I would like to see SSO to Office 365 native apps (Play Store apps) as well. It only works for the web apps.

    Any idea how to accomplish that?

    ReplyDelete
  2. The first paragraph seems, to me, to be pointing in the wrong direction. This part "Single Sign-On (SSO) from Google to Azure AD" must be the reverse, right?

    You're using AAD credentials to sign into Google, so to my ears/eyes it should say "Single Sign-On (SSO) from Azure AD to Google".

    I know you explain it in the next sentence, but am I really wrong?

    ReplyDelete
  3. Kim, your point is valid I could make it clearer.

    ReplyDelete
  4. If you setup the SSO to be handled by Azure how does it handle third party apps that you have already linked to Google sign on. Apps that users have said just "sign in with google" Like lucidchart.com, asana.com as examples. Do those continue to work by passing through to azure automatically when users click sign in with google?

    ReplyDelete
  5. The market outline area of the report features the market's elements and patterns, for example, the drivers, limitations, and openings that impact the ebb and flow nature and future status of this market. ai courses

    ReplyDelete
  6. Hi,
    I have followed the instructions and it works perfectly. But after the first login. In chrome it shows the users that have logged on before. When i log in again. The SSO cookies are not transfered and SSO doesnt work.

    How can i fix this? (The option to transfer cookies after first login is already enabled but doesnt seem te work).

    ReplyDelete
  7. I'm not sure I quite understand the issue. Are you referring to the Chrome browser or Chromebooks. Chromebook device policy is normally set to "Never show names and photographs" which removes the record of previous logons.

    ReplyDelete