This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(124.80000000000001, 6%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ER%3C/text%3E%3C/svg%3E)
I am totally new to Azure. Zero experience. But I have experience with AWS and GCP. I need to get our Azure account setup so we can start trying some things out in there.
We use google gsuite for email and such.
We use terraform to manage the other cloud providers... and intend to do so for azure.
For AWS we use their SSO to give our developers the level of access they need for the different environments. For GCP it's of course tied to their gmail accounts.
So what is best practice for Azure? I would like some sort of SSO I think. But the structure in Azure seems to be different. I don't "think" I will have separate accounts like AWS that have separate user pools. Seems like I have would some hierarchy of management groups. Currently thinking a top level one for the project in general, then one per environment (dev/test/prod) under that and then a subscription under each of those. Seems like users are managed at the management group level, so SSO like AWS's might not be necessary. I might just need to create the users via terraform at the top level and configure them to authenticate with their google login or something. Then of course give them only the permissions they need to the project and environments below.
Searching for this kind of stuff commonly gets me information about handling access to an application that is hosted in azure. Which of course isn't what I am trying to do. I have turned up some info on Entra. But that looks more like okta, which is not what I am trying to do either.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(198.4, 26%, 29%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJK%3C/text%3E%3C/svg%3E)
Hello Randell,
Thank you for reaching out to Microsoft Q&A.
I understand that you are looking to create a hierarchy of management groups in Azure, with a top-level group for the project and separate sub-groups for each environment (Dev, Test, and Prod). Additionally, you want a solution where users are created at the top level and authenticated via their Google Workspace accounts, with the ability to manage roles and permissions in Microsoft Entra ID.
The solution you're considering can indeed be achieved by configuring federation between Google Workspace and Microsoft Entra ID. This setup allows Google Workspace to act as the Identity Provider (IdP), and Microsoft Entra ID to function as the Service Provider (SP). As a result, users will authenticate using their Google credentials when accessing resources protected by Entra ID.
Below are some prerequisites which needs to be met to configure Google Workspace as an IdP for Microsoft Entra ID:
Further, using Security Assertion Markup Language (SAML), your users can use their Google credentials to sign in to enterprise-cloud applications. Office 365 uses the ImmutableID attribute to uniquely identify users. For SSO between Google and Office 365 to work, each Office 365 user must have an ImmutableId, and the SAML Name ID attribute sent to Office 365 during SSO must be the same as the ImmutableId.
Sharing relevant documents to achieve the above requirement: https://learn.microsoft.com/en-us/education/windows/configure-aad-google-trust
Hope this helps. Do let us know if you any further queries.
Best Regards,
Janaki Kota
If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.
Hello Randell,
Following up to see if the below suggestion was helpful. And, if you have any further query do let us know.
Hello Randell,
Just checking in to see if the information I provided was helpful. If you have any further queries regarding this issue, please feel free to post them here.
@Janaki Kota Sorry for the delay... my notifications were going to an email to I don't think actually exists or something. lol.
For
Does that domain have to be the same as our google workspace domain or just any domain? And if the later, what is it for?
For ImmutableID, I assume google as some default for the "the SAML Name ID attribute" it sends?
@Janaki Kota Also, that link results in "bad request".
Hello @Randell,
Thanks for the response.
The domain in your Microsoft Entra tenant doesn't have to be the same as the domain you use for Google Workspace but if it is the same domain, it will simplify the integration. The purpose of adding a custom domain to Microsoft Entra ID is to verify that you own the domain and to enable users in your organization to sign in to Microsoft Entra ID using their email addresses in that domain. This allows you to use your own domain name for user sign-in instead of the default.onmicrosoft.com domain. When setting up SSO (Single Sign-On) or federation between Google Workspace and Microsoft Entra, Google typically sends the SAML NameID attribute as part of the authentication request.
Sharing relevant documents for reference: https://learn.microsoft.com/en-us/education/windows/configure-aad-google-trust
https://cloud.google.com/architecture/identity/federating-gcp-with-azure-active-directory
Please don't hesitate to reach out to us if you have any questions further.
Best Regards,
Janaki Kota
If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.
Hello Randell,
Following up to see if the above suggestion was helpful. And, if you have any further query do let us know.
Hello Randell,
Following up to see if the below suggestion was helpful. And, if you have any further query do let us know.
@Janaki Kota I got a chance to try all the steps in the doc. And got them all to work except the last one. When I tried to login with the username from our google domain it just tells me it is incorrect. I think I know why though. We didn't enable autoprovisioning because don't want to give everyone access to Azure. So I assume I have to make the user manually and such. Do you have any doc links on how to do that? Eventually we will do this in terraform, but manually for now will get us moving forward. Thanks.
Hello Randell,
To test federation, the following prerequisites must be met:
Sharing relevant documents for more information: https://learn.microsoft.com/en-us/education/windows/configure-aad-google-trust
https://support.google.com/a/answer/7365072#zippy=
Hope this helps. Do let us know if you any further queries.
Thanks & Best Regards,
Janaki Kota
@Janaki Kota The end plan is to create the users via terraform. But before that I want to manually create a user and test it out. So I went to Entra ID -> users -> add new user.
I was able to choose my custom domain from the list, enter basic info, add a role... I got this error
SourceAnchor is a required property for creation of a federated user
There wasn't anything in the UI that let me set a source anchor. So I can't create the user.
Hello @Randell,
Thanks for the update.
Federated accounts can only be created in the system of origin. The error you're seeing, "SourceAnchor is a required property for creation of a federated user," suggests that you're attempting to create a federated user in Azure AD (Entra ID), and federated users require a SourceAnchor property to be specified. The SourceAnchor is typically used to uniquely identify the user in a federated identity system. It's commonly used for scenarios where users are synchronized from an external identity provider. Users require an email address defined in Google Workspace, which is used to match the users in Microsoft Entra ID. When a Microsoft Entra user is federated, the user's identity from the IdP must match an existing user object in Microsoft Entra ID. After the token sent by the IdP is validated, Microsoft Entra ID searches for a matching user object in the tenant by using an attribute called ImmutableId.
https://learn.microsoft.com/en-us/education/windows/configure-aad-google-trust
Thanks & Best Regards,
Janaki Kota
@Janaki Kota I'm a little fuzzy on what you are saying there. My overall goal is that we have say 50 users in google workspace. But only 20 are engineers. I want those engineers to be able to use their google workspace account to login to azure. But I don't really want to give all the non-engineers access. So I didn't enable auto-provisioning when I setup the federation. And the document implies I don't have to. But now I need to create those matching users in azure.
I was trying to create them in entra ID because I don't know where else I should be doing that. And I did expect to have to set something to connect the user to their google workspace account. But I don't see anything I can set. So how can I create the users I want on the Azure side to match the google workspace users?
My previous comment isn't showing up, so I am going to try and replicate it. Might end up with two saying the same basic thing.
At the high level, we have like 50 people in google workspace. Only 25 are engineers. So I only want to give azure accounts to those 25. When setting up the federation I didn't turn on auto-provisioning because that would give all 50 azure accounts. So now I am trying to create the 25 users that should have access to azure and tie them to the federation. For that I tried Entra ID because I don't know another place to do it. Is there a better place?
Entra won't let me set the SourceAnchor. But obviously if other automation from the system of origin can create the users, there must be a way for me to do the same. And it sounds like also need to be able to set the ImmutableId as well. Which Entra didn't let me do either.
Hello @Randell,
We understand that you would like to give azure accounts to only 25 engineers out of 50 in google workspace. As discussed earlier by using School Data Sync (SDS), Microsoft Entra Connect Sync for environment with on-premises AD DS, PowerShell scripts that call the Microsoft Graph API, Provisioning tools offered by the IdP - Google Workspace offers auto provisioning only you can create those accounts in Entra Id.
Since you would like to exclude a few users from getting azure accounts, you can follow the below steps while setting up auto provising aswell.
Sign in to your Google Admin console.
Open the Microsoft Office 365 application.
In the Auto-provisioning section, click Configure auto-provisioning and click Authorize.
Here, you can see an option to Restrict provisioning to specific groups:
Enter all or part of a group name in the Search groups field. A list of available groups appears. Select a group to add it and open a new search field.
If necessary, add more groups and choose a scope.
To remove any group you added, click next to it.
Kindly refer the document for more information: https://support.google.com/a/answer/7365072#zippy=%2Cset-up-auto-provisioning-for-the-microsoft-office-application
Best Regards,
Janaki Kota
The issue we have is that google workspace doesn't have the groups or scopes to identify the right set of users. That information is in a code repo. And we use terraform to apply it to other cloud providers. So we want to use terraform to provision the users in azure as well, but link them to google workspace. Is that not possible?
You can integrate your Microsoft Entra to GCP too
https://learn.microsoft.com/en-us/entra/identity/saas-apps/google-apps-tutorial
In total this guide can help you for first steps to setup
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-setup-guide/
Thank you for the response... but the first link is the exact opposite of what I was talking about. That is about using a microsoft login to login to google. I need to go the other way. Everyone in the company has a google account, but not all will have access to azure.
The second link had some helpful stuff. But it didn't seem to say much about where the users are created. It just talked about giving them permissions. Maybe there is only one place they can be created? Or is a user even specific to a tenant? Nothing I find seems to talk about that.