The biggest hurdle in most organizations comes down to managing the Identity Goverance aspect. Over my career, I have worked for many outfits that have multiple identities, when it was easily not needed. Fast forward to today, I am seeing multiple traditional Active Directory infrastructures, as well as, multiple cloud platforms. I.e., CompanyA has traditional Active Directory Domain Services in hybrid with Azure Active Directory but their AWS (Amazon Web Services) and GCP (Google Cloud Platform) cloud providers are separated and under an entirely different management realm outside of the identity teams purview and organizational life cycle. The scenario I just described can be spun a few ways but it all comes down to consolidating into one identity platform and creating the identity 'baseline' at the Azure AD control plane.
Executive Order M-22-09 has laid it out in a paragraph: "Using centrally managed systems to provide enterprise identity and access management services reduces the burden on agency staff to manage individual accounts and credentials. It also improves agencies’ knowledge of user activities, thereby enabling better detection of anomalous behavior, allowing agencies to more uniformly enforce security policies that limit access, as well as quickly detect and take action against anomalous behavior when needed.".
Let's Federate Google Cloud with Entra ID, see google doc. I recommend reading the entire document a few times to get a full grasp of each scenario. A key note with the entire setup is that, whatever custom domain name you end up using which is tied to the identity suffix, that is how your pass-through is going to work. I won't deep dive into it, just review the doc and follow the flow.
Disclaimer - My example will not only use Entra ID as the sole identity provider but to leverage 'cloud only accounts' from the Entra ID side. Why cloud only? In a lot of scenarios, the other endoint, GCP in this case is for administrative purposes only. So, I am keeping seperation of duties and least privilege in mind rather than syncing a tiered admin account from on prem and flowing through. In short, better security. See diagram below of the setup.
To accomplish this feat, we will be using SCIM (System for Cross-Domain Identity Management) and SSO (Single Sign-On). That means, SCIM = user/group provisioning to set the Authorization/Authentication and SSO with SAML = seamless flow to GCP to do their administrative work. The detailed flow will look like below.
Dislaimer & Pre-reqs - GCP does not allow .onmicrosoft.com accounts to provision to GCP. You MUST use a custom domain domain. It is recommend to use the SAME custom domain name that is being using in Entra ID but is not necessary nor may be possible by who owns the name. See here on GCP domain names. What does that mean? cyberlorians.com exists in both Entra ID and GCP. In fact, a customer is not able to setup a GCP environment without a custom domain name. Plan wisely.
Let's dig in! This setup is assumed you have Entra ID and Google already setup. The first we need to do is create the user provisioning piece from Entra ID>GCP. The official document is here on those steps.
This user will be the automated provisioning account that we set in the Entra ID application to SCIM the users/groups to GCP. Those steps are outlined here. Proceed to domain name setup if you want any subdomains. If not, leave the primary as is.
Steps are outlined here, however, name your Enterpise Application: 'GoogleCloudProvisioning.onmicrosoft'. Or something to distinguish it by. The real reason I state this is because if using Entra ID B2B you will need another provisioning enterprise application with its own attribute mappings. On the image below, make sure you have 'NO', set on all 3 properties as stated in the doc. Note - you may keep provisioning and SSO Enterprise Apps together but for security best practice, leave them seperated and locked down accordingly to whom can manage them.
Disclaimer - I am showcasing administrative work only using cloud only, .onmicrosoft.com accounts. I.e., cranesmeadows.com is a dns suffix on prem in my ADDS environment using ADFS. If I were to use the same suffix I would allow the same account which is on prem to be used (no least privilege) and going through ADFS as the token gets passed from the on prem ADDS servers first (this is messy, but 100% doable). So many scenarios can work here, so please understand them all from the documentation. I'm just focusing on admin accounts only to break all lateral movement and anti-phising campaigns from email. I have a block rule in my exchange admin center from any outside email to my primary (*.onmicrosoft.com), to help lock this effort down. You may use a custom domain name if you would like to keep in line with the Enterprise Access Model - Management Plan. Just keep least privilege in mind.
As stated, in this lab, I am doing a UPN: domain substitute but please chose accordingly here. It is straight forward but below are snippets for visualization (User & Group mappings). Remember, these users and groups will transform to GCP with the suffix of cranesmeadows.com (GCP Domain Name).
Leave this step as default and all is well, document is here.
Step5: Assign the users to the new provisioning enterprise app (seen below) to be provisioned. Confirm provisioning is working and check GCP to see the new users.
Follow the instructions here by creating a new Enterprise Application first then proceeding with configure user assignment (the same users/groups assigned to the provisioning).
Instructions are here, however, I want to show the settings by the snippets below.
SAML specific to your custom domain name is below.
Under the 'UPN: domain substitute steps'. Look at the snippet because the instructions on the doc can be bit janky. Under the join() for parameter2, just type the custom domain name in the field and hit enter. It will look like below. Do NOT put quotes because the parameter will then have double qoutes and NOT work.
These steps are laid out here and remember the certificate you are uploading is coming off the enterprise app, 'SAML Signing Certificate' (BASE64) you downloaded.
Log into myapps.microsoft.com and you should be able to SSO into GCP.
SSO>GCP Console confirmation
Note 1 - I stated to use multiple Enterprise Apps for provisioning and SSO. At first this may sound goofy but it is for least privilege of the application. One app is controlling provisioning into the other cloud provider, therefore we do not need any users to view this application or anyone outside of the owner or proper Entra ID privileged role to view and make a configuration to the privileged role and sync attributes.
Note 2 - If wanting to incorporate B2B from Azure Commercial or Government, stand up yet another provisioning Enterprise Application for this need and follow these steps. The reason for this and at this time of writing is simply because under the provisioning attribute mapping, it is difficult to add multiple 'Replacements' for the Entra ID attribute to the 'primaryEmail', GCP attribute. Once a way is found, this documentation will be updated.
Note 2.b - Configuring the SSO for B2B and everything else can be a little confusing, as shown here. In your journey, if you decide to go this route, please see the below snippets along with Googles documentation to see how the SSO claims can be combined into one.
Enterprise App = GCP-SSO. Head to Single sign-on>2(Attributes & Claims).
Claim Name = UUID (Name ID) - Edit this field in the below images.
Any claim condition - Just enter as seen below.
Back on the Attributes & Claims page - Additional Claims - Enter as seen below.
Note 3 - Always think of least privilege during this type of setup. Whether it be from on prem first, B2B or cloud. Don't mix the traditional Tiers from on prem OR control and data planes of the cloud or worse, give access to a B2B user from another tenant full admin rights to your Google platform. When talking administrative functions and least privilege, also chose passwordless scenarios, MFA, phish resistant and etc. A good example to where you this situation may not require a cloud only admin account, is perhaps a read only or billing account for the GCP side. In that case you may find it acceptable to use an on prem synced account to flow through the entire process. Albeit, you may inadverently change the identity lifecycle and management piece to all of this and introduce lax security.
Note 4 - Don't think using multiple apps for provisioning and SSO will a nightmare. I recommend using Entra ID Dymanic groups to populate your groups. This way you just assign the groups permissions to the apps and call it a day because you know the users with a certain, (another attribute) will be auto populated into these groups.