© 2021 All rights reserved
Made with love for Google Workspace:)
Hello There, thank you for joining in, this is Goldy again. Welcome to definitive guide to Google Conflicting accounts. In the past, we have discussed a lot about what are Google Conflicting accounts and how do you fix them in regular scenarios.
But in today’s video, I wanted to talk about a very specific use case, which is Google conflicting accounts and a third party identity provider that you might be using in your Google workspace or Google cloud identity.
So how do we handle Google conflicting or consumer accounts in that specific case?
And for that, let’s understand the way IDPs are configured to provision users into your Google Cloud Identity or Google Workspace directory.
So one side you have your identity provider that maybe organizations like Okta, Ping, Azure AD, etc. and then on the other side, you have your Google Cloud directory (You can call it Google Cloud Identity or Workspace, but essentially it is Google directory).
Then within your IDP, you might have configured some rules and scope to tell which users should be provisioned in Google Cloud directory.
And all of these identity providers, including the prominent ones that are listed here, they use Google’s Directory API to provision the users, groups and members.
Now the point to note here is that Google’s Directory API does not detect whether an account is a consumer account already or not. It will just go ahead and provision that user.
So in case, if you leverage any of these identity providers or maybe you have created your own provisioning utility leveraging Google’s Directory API just like them, please do not use it right away, because if you do, all your users will be created at once, which means you will lose an opportunity to send a data transfer request to those consumer accounts.
You should rather take the following path:
You should find consumer accounts that are created with your corporate email address, and you can easily do that by leveraging transfer tool utility (covered in a different post / video), Now, once you have the list of these consumer accounts, preferably CSV downloaded list.
Then you should do your outreach, which means you will reach out to all these users with your internal survey tool or whatever mechanism you have internally to outreach these users asking in case if any of them have corporate data inside those consumer accounts.
Then once you have that information, you should be in a position to make the decision.
(i) For users who come back to you saying we do not have any corporate data in our accounts, then you can either consider to create them via IdP, which means you will claim their work account and their existing account will be renamed.
(ii) However, if some of those consumer accounts owners come to you saying, yes, we do have the data in these consumer accounts that belong to the company and we would prefer to migrate that data to the work account, then you should exclude these users in your identity provider provisioning rule.
Note -: Most of the prominent identity providers give you an option to do rule based provisioning, So, for example, you can say only provision users in Google if these users are part of this xyz group, but not if they are part of my “consumer exclusion group”.
Then you should follow a different approach for those users, which is to send them account transfer request rather.
This was about handling conflicting accounts when you are leveraging third party identity provider, but what about authentication for users that already have consumer account, and you are turning on SSO with third party IdP?
Lets cover it now.
For authentication, Google’s system is intelligent enough to differentiate between consumer accounts and your corporate accounts, even if both of them belong to a same domain.
So as you see here, when the user goes and enter his or her email address to log in to Google services, Google will do the identity provider lookup behind the scene based on whether the user is coming with a consumer or a personal account or whether it’s corporate or managed our work account.
and based on that, if you have configured a third party single sign on and your user is logging in with their work account, then user will be redirected to the configured 3rd party identity provider (assuming they are not super admins because super admins are by design configured to by pass single sign on).
However, in case, if those users are logging with their personal or unmanaged accounts, then they will go to Google as their identity provider.
I hope it was helpful, especially in case if you’re dealing with conflicting accounts and have third party identity provider configured with your Google Cloud identity or Google workspace.
If you have any questions, comments or feedback, do not hesitate to put that under this video and I will be happy to collaborate.
Thank you so much.