Sunday 7 July 2019

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.


4 comments:

  1. Hi there, thanks for the great write-up! I set this up using a free Azure AD tenant with Security Defaults enabled, and ran into a few roadblocks I thought were worth mentioning.

    First, I had to make sure my domain was verified but not marked as primary. Wasn't sure if this was mentioned somewhere, but if I didn't leave my domain.onmicrosoft.com marked as primary, I ran into sign in issues after authentication.

    Second, the script to import the xml with parameters was missing from the walkthrough, though I got it from the IAmFrench github: $wsfed = Import-Clixml dfs-pf-samlp.xml


    Third, since I had Security Defaults enabled in Azure MFA in addition to enforcing 2FA in G Suite, I'd be prompted for Google 2FA and then asked to setup Microsoft's MFA. By adding the flag -SupportsMfa 1 to the end of the Set-MsolDomainAuthentication script, I was able to bypass MFA registration for Google SSO logins while not compromising other accounts.

    Thanks again for this! I had been looking into this for a while but no one really seemed that interested in documenting this like you have.

    ReplyDelete
  2. Hi to author and TeconMoon. Both the OP and the comment helped me immensely on my project in terms of setting up SSO.

    Trialing this out with a small school, I noticed that with SSO enabled, I cannot sign in to the computer offline. I haven't seen the option to allow offline sign in when you've already done so previously online.

    Unless I'm missing something, would really love to know if there's a workaround.

    ReplyDelete
  3. I'm interested in an answer to the offline question. because the system login double 2-factor is pretty ugly, I push our users to Windows Hello enrollment on first login. Once that is set up, the user simply logs into the device with Hello credentials -which are inherently local.

    Additional question -do we know if/when Google Cloud Identity will add STS functionality to be able to attest to 2fa on their side so we can set the SupportsMFA setting to true and be properly secured without having to set up MS Authenticator for the redundant 2nd factor?

    ReplyDelete
  4. Hi there, This document helped me to enable SSO and Web Login to AAD Windows devices. Thanks a lot !

    ReplyDelete