Using Google to authenticate Microsoft (p2).

This is the second part of an extended post that describes how to use Google as an identity source for Microsoft Azure Active Directory (Office 365).

---

The next stage involves configuring Azure to pass authentication requests through to Google rather than handling them locally. Using technical terms we are creating a federation between the two platforms with Google acting as the identity provider (idP) and Azure the service provider. As before we’ll work through this example using theserverlessschool.net which is a custom domain in a Azure AD  tenancy.

Note: Each federation object acts on a single domain so it’s possible to have many custom domains within an Azure AD  tenancy, some federated to Google (or some other idP) and some locally authenticated.

All of the work is done from the powershell console so the first job is to install the modules listed below within a session running with local admin permission. You’ll also need details of an admin account for Azure AD.

Microsoft Online Services Sign-In Assistant for IT Professionals RTW
Microsoft Azure Active Directory Module for Windows Powershell.

The first module is a simple download. Once installed it’s loaded with the command.

PS C\:> Import-Module MSOnline

Then login to Azure AD using an admin account using the commands.

PS C\:> $Msolcred = Get-credential
PS C\:> Connect-MsolService -Credential $MsolCred

Creating the federation is a one line powershell command Set-MsolDomainAuthentication Unfortunately the number and complexity of the arguments turns it into a bit of a monster.

To get round this problem the input variables are read from an xml file and since most of the values are standardised you only need to update two elements before running the command.

The template xml file (dfs-pf-samlp.xml) can be downloaded from the original GitHub repository or from here.

Before using the file you need to replace the string GOOGLESAMLID with your domains unique idpid recorded when setting up SSO in G Suite. The input  line should be similar to this:

https://accounts.google.com/o/saml2/idp?idpid=C03idbhgle

Note that GOOGLESAMLID occurs three times in the file and needs to be replaced in each location.

Lastly you need to carefully copy the certificate string from the IDP metadata file saved from the SSO setup process and paste it into the location below.

<S N="SigningCertificate"> YOUR CERTIFICATE GOES HERE </S>

A shortened version will look like this.

<S N="SigningCertificate">MIIDdHCCAly…...BAkTD0dv</S>

Make sure you paste as a single line and do not introduce any line breaks or extra characters.

Once that’s done we can create the federation using the command below, substituting theserverlessschool.net for your domain. The command is shown with line breaks but needs to be issued as a single line command.


Set-MsolDomainAuthentication -DomainName "theserverlessschool.net"
 -FederationBrandName $wsfed.FederationBrandName
-Authentication Federated
-PassiveLogOnUri $wsfed.PassiveLogOnUri
-ActiveLogOnUri $wsfed.ActiveLogonUri
-SigningCertificate $wsfed.SigningCertificate
-IssuerUri $wsfed.IssuerUri
-LogOffUri $wsfed.LogOffUri
-PreferredAuthenticationProtocol "SAMLP"


A couple of other useful commands:

---

Get-MsolDomainFederationSettings -DomainName "theserverlessschool.net" | Format-List

    Shows the federation settings for the domain in the  console.

---

Get-MsolDomainFederationSettings -DomainName "theserverlessschool.net" | Export-Clixml dfs-pf-samlp.xml
   Dumps the settings back into the config file.

---

Set-MsolDomainAuthentication -DomainName "theserverlessschool.net"  -Authentication Managed

   This command switches the authentication back to locally managed and effectively turns federation off. This is particularly useful as a fall back option but it also allows you to update the settings as the values cannot be changed while the federation is active.

Azure will now pass all authentication requests to Google for any non-admin account in the domain “theserverlessschool.net”.  So what does that look like ?

Open up a Chrome session in incognito mode, navigate to https://office.com and select Sign In. When asked for a user account enter an Azure username from your federated domain. After a short pause you’ll be directed to the standard Google dialog which will grant access to office.com.

So what happens if you try and login to an Azure joined Windows 10 device with the same Google user account. You might expect the same behaviour but that’s not what you see. The Windows logon box remains and the Google password is refused. Nothing has changed. So why is that ?

By default the conversation between the Windows 10 device and Azure doesn’t use SAML but WS-Fed (WS-Federation), a protocol supported by IBM and Microsoft but not Google, therefore the hand-off falls at first hurdle.

What you need is a Windows logon process that understands SAML not WS-Fed and with Windows 10 1809 edition you have exactly that.

The feature is off by default but can be turned on using a custom policy in InTune.


OMA-URl
 ./Device/Vendor/MSFT/Policy/Config/Authentication/EnableWebSignIn    


After deployment you are offered an additional option on a globe icon - Web Sign-In.



Select this option and sign in using your federated account. This time you will see the redirection and you’ll be presented with the familiar  Google login dialog which will grant access to the Windows desktop.

You have to enter the logon account name twice because Azure needs to know the username before it can offer the redirection. In the future it will be slicker and remember this is still a preview feature.


Summary.
In an earlier blog post I predicted it would be a while before we saw a Windows device using a Google account to authenticate.

A year later, here we are.
This could be used as an example of how wrong I can be but I’d prefer to think it reflects the pace of change and the general move towards open standards.


The new framework is becoming clearer by the day.

Cloud based user directories controlling MDM managed devices that host SaaS applications delivered through a store model backed by subscription licencing.

Google, Microsoft take your pick - they both offer the same vision. You can even mix and match.

The only thing you can be sure of is the fact that not a single element will require a local server.