My company’s a little unusual in that it’s a Microsoft and .NET development shop, but our main identity provider and document collaboration suite is Google Gsuite rather than Office365 with Azure. It’s also my personal opinion that Google is currently the superior web IDP use to wider adoption in web applications compared to Azure login.

That said, our use of Outlook with Exchange online is firmly entrenched and our dependence on Microsoft CRM Online and PowerBI means we require both corporate clouds indefinately.

AD and multi cloud architecture

An almost 20 year old AD infrastructure meant that we’re having to sync users and passwords into both clouds — yet it’d be an incovenience to implement MFA two seperate times. We ended up with MFA on Gsuite long before getting it in place in Office365 and so there was limited appetite to reverse this, with MFA primarily in Office365. If you are a heavy Azure house with limited use of Gsuite, I do not recommend my direction of implementation.

This pre-implementation architecture diagram shows how:

AADC works in one way, writing a sync attribute back to your AD

GCDS works in a rather different way, performing only reads

My goal was to get my Office365 users logging in with their more secure Google accounts, but doing so was surprisingly unituative.

Prepare for 2FA incompatible accounts

Before I could even start, I had to shut down all MFA incompatible access into my Office365 account, because there’s no point implementing MFA if legacy protocols can bypass it. This involved setting default Exchange policies to disable these protocols:

This caught a handful of unsupported IMAP users and people on old clients which needed immediate updating to Office365 auth.

I also had to update or remove various terrible service accounts using basic authentication but that’s a story for another day. When I was sufficiently convinced that all my user access would work under modern authentication, I was ready to move to forcing login from Google.

IDP Sync Complexities

Google has a preconfigured SAML Office365 app, which tells you ‘oh by the way, make you manage your ImmutableID for systems sync’ before kicking you to the generic Microsoft guide on modifing your Office365 IDP. This proved a pain in the arse. Oh sure, there are guides already out there, but they appear to be for greenfield Google to Office365 configurations without an AD sync behind them.

It seemed just a single person /u/HBUHSD_Analyst on Reddit had worked out the mysteries of multi cloud identity sync, pointing out that you needed to Base64 encode the value of AADC’s mS-DS-ConsistencyGuid to use as your immutable user identifier for systems sync.

Fortunately due to previous group-based limitations of GCDS, I had developed a pre-sync enricher powershell script, which would allow me to add the encoded attribute into my AD then GADS sync it up:

This involved a minor edit of the AD schema and delegating granular permissions to the GCDS service user so not for the faint of heart.

After telling GCDS to copying up my new ‘encodedMSDSConsistencyGuid’ user attribute to Google, I could finish configuring the SAML mappings:

( I copied the encodedMSDSConsistencyGuid AD attribute to Google attribute ‘mS-DS-ConsistencyGuid’ when I should have copied it to Google attribute ‘ImmutableID’, oh well )

I was finally ready to switch my Office365 IDP to Google with the help of some useful guides:

And thus my users logging on to Office365 get redirected to Google for login, and thus are protected by MFA!

Conclusion

During this process, I was surprised to find how Google hadn’t made it easier to use them as an IDP, e.g. by supporting greater LDAP wrangling functionality into GCDS. I was also surprised to find so little information about performing this integration with a traditional active directory infrastructure behind both cloud providers.

I hope this helps people better work with their Google Cloud and Gsuite accounts who are still reliant on active directory and/or Azure elsewhere!