Federating Google Cloud with EntraID (Azure Active Directory)
A practical guide to ensuring a single source of truth for identity.
Introduction
I am a big advocate for ensuring a single source of truth for identity. At a previous employer, I even spearheaded work to consolidate three different sources of identity across different systems down to a single source. The main reasons for this were threefold:
- Security — Having one potential identity attack surface is easier to manage than several, especially with powerful tools like context-aware access
- Maintenance Overhead — Keeping the identities in sync was a complete pain
- User Convenience — Telling users they only have to remember one password and have single sign-on to various systems can make their day, trust me I know this first hand
I think it is fair to say in the world of Cloud Identity most organisations have settled on either Google’s Cloud Identity or Microsoft’s Azure Active Directory (AAD). The use of one or the other normally comes down simply to their choice of productivity suite with Google Workspace and Microsoft 365 or frankly the logical progression from ‘conventional’ Active Directory. I am not going to talk about the pros and cons of either of these solutions, partly because it isn’t my area of expertise, and also my opinion is likely to be biased working for a Google Workspace partner, though in fairness I have previously carried out 365 migrations.
The end result of this is a lot of companies use Azure AD but may have the desire to run their cloud infrastructure outside of Azure itself on the wonderful platform that is GCP (not that I am biased at all!)
Getting Started
First things first, I am not going to reinvent the wheel, I am following the documentation Google produced and all I hope to do is bring this to life a bit more. In true Blue Peter style, I have already created a new AAD ‘Tenant’ and added some users to it.
Please note this all assumes you have a domain name that you own and can verify with both Microsoft and Google.
The next step is to create a Cloud Identity Domain, which is a subsection of the workspace setup but don’t worry Cloud Identity like Azure AD is free up to a certain point.
I then verify my domain before selecting the option to setup the GCP console:
I have to log in with my Cloud Identity Tenant Admin then it created the Google Cloud organisation for me before finishing up on this page:
Setting up the Sync
So one of the things Google stresses is that you need to think about how you map identities across, I am going to do this off User Principal Name (UPN) (which often matches the user’s email address) which is pretty standard and should be globally unique.
The first step is to create a user within Cloud Identity which will be used as part of the sync from Azure AD. First, Google suggests creating an Automation OU:
And a new user:
Once created, I then copied the password to another window for later. After this the next stage is to give the user privileges, with two choices:
- Super Admin — ‘God mode’ over everything Workspace, Cloud Identity, and GCP
- Delegated Administrator — A more restricted mode that can’t manage other administrators or Super Admin users
As a firm believer in the principle of least privilege, I opted for the latter option and therefore had to create a new role and assign it to the user I created previously.
I get to skip the next section about verifying domains as it is a new organisation so I have already done it but you can verify multiple domains if required.
So after this, the next stage is to jump back into AAD and search for the Google Cloud Connector enterprise application which was pretty straightforward.
Once the connector has been created it is the case of altering a couple of settings manage properties section:
Then we launch into provisioning with ‘get started’ before changing the mode to automatic and authorising with the cloud identity created earlier.
Once authorised and the connection is tested we need to check the mapping settings. As I am doing this using UPN all I need to do is set default values for the surname and given name if they don’t otherwise exist.
As Google states in its documentation, you must set mappings for primaryEmail, name.familyName, name.givenName, and suspendedbut you can configure others depending on what attributes are imported to you, for example, the department.
The next step is to check group provisioning which I haven’t setup but follows similar logic for mail-enabled AAD groups.
The final step to kick off sync is to determine if specifically selected or all users are in scope and to simply turn it on. It is also possible on this screen to configure an email address in case there are any sync issues.
I then check the status which was pretty instantaneous for my small number of users.
After a short while (I left it about an hour) I came back to find identities synced across into Cloud Identity nicely. As you can see the default substitution values have also been set as I never defined the attributes on the AAD side.
Single-Sign-On (SSO)
Configuring SSO is also pretty straightforward, jumping back into the Google Cloud Enterprise Application we just need to alter a few settings. Firstly we need to enable sign on and set the requirement for users to be assigned:
Requiring assignment then requires assigning users or groups to the application:
The next and probably most technical step is configuring Session Assertion Markup Language (SAML) which, at its most simple, establishes the trust relationship and the redirection of Cloud Identity authentication requests to AAD. First, we need to configure the identifier, reply URL, and Sign-on URL.
Next, we need to download the base64 certificate for later.
Then, grab a copy of the login URL which we will need later.
The next step is to configure the attribute claims, as I will just be using UPN all I needed to do was delete all other addition claims to be left with the below:
Jumping back into the cloud identity console we now need to add Microsoft as a 3rd party identity provider (IdP):
Adding the profile we need the sign-in URL we copied earlier from the Azure side, the certificate we downloaded, and the sign-out and password reset URLs:
The next thing we want to do is a block inheritance of the default SSO sign-in of Microsoft for the automation user and I would also highly suggest any super admins. To do this we create SSO profile assignments for specific OUs, one of the automation OU we created earlier and in my case another for a Super Admin OU I created to put my Super Admin account in.
The final step is then to test that SSO works for one of our synced users. I did this simply by browsing to the GCP console (in an incognito window) and signing in with a synced user which redirected me to Microsoft to complete the authorisation before launching me into the console.
Conclusion
In conclusion, what we have done here is establish identity synchronisation between AAD and Cloud Identity to ensure a single identity. We then configured SSO so that users using wanting to use Google Cloud could use their existing AAD Accounts.
For me, the purpose of this post was as much to run through the process myself as this is something we are increasingly getting requested from our customers. But hopefully demystifying it for the community is of wider benefit too. Until next time, keep it Googley :)
CTS is the largest dedicated Google Cloud practice in Europe and one of the world’s leading Google Cloud experts, winning 2020 Google Partner of the Year Awards for both Workspace and GCP.
We offer a unique full stack Google Cloud solution for businesses, encompassing cloud migration and infrastructure modernisation. Our data practice focuses on analysis and visualisation, providing industry specific solutions for; Retail, Financial Services, Media and Entertainment.
We’re building talented teams ready to change the world using Google technologies. So if you’re passionate, curious and keen to get stuck in — take a look at our Careers Page and join us for the ride!
