Identity migration from Google to Azure AD / Office 365

There are times when as a consultant you’re challenged with very interesting tasks. My latest one was to migrate a client’s identity provider, from Google to Microsoft and, do that in such a seamless manner that nobody would notice the change.

Doing these types of migrations require a lot of planning, risk management and fall back scenarios. This is not an easy job to do and your mileage will vary depending on your use cases. 

I’m not going to cover every aspect in this blog post because there are too many variables that depend on the current environment.

First, you start off with the discovery phase, where you document all the applications that have SSO with the current identity provider. This is a very important step because if you miss this one, you will have major problems.

Then you have to assess which of those applications can be migrated to the new identity provider or need some type of code modification. In general, code modifications are required for custom apps but there are some 3rd party SaaS apps which might require a different monthly plan to get custom IDP support.

Second, the analysis phase, where you analyze each application and come up with migration paths. This process length depends on how many applications have SSO with the current identity provider and how many are custom applications which require code changes.

Third, planning the migration. This is the part where you REALLY take your time. Plan for disaster. Set up a stark mirror environment with some identities in Google and some in AAD and test everything out. Even with everything in the green, still, assume the worst because you never know what changes or what appears till you do the migration.

When I planned for the migration, I asked some simple questions:

• How do we migrate the user identities?
• How do we “migrate” the passwords to Azure Active Directory?
• How will we handle the custom apps?
• How will we handle third-party apps?
• Where do we draw a line and fallback?
• How do we fall back to the old provider?
• When is the point of no return?

These are some of the questions that you should think about and each of them should be tested properly in a “mirrored” environment because you cannot afford failure and fumble around when you’re doing the migration.

I will list some of the migration paths that you have available at hand which can be used or not, depending on your particular scenario. This is just a guideline and I won’t assume any responsibility for the environments your working on.

Let’s get started.

Migration paths: 

Solution 1 – Double hop SSO

This path works by setting up Azure Active Directory as the primary identity provider for Google. This solution allows you to perform a graceful transition of the SSO applications from Google identity to Azure Active Directory with minimal user impact and downtime if you have an on-premises environment with Active Directory.

If you have Active Directory then the solution requires you to install AADConnect, synchronize the identities to AAD and then perform the reverse SSO.

If you don’t have an on-premises footprint then you have the following solutions at hand:

• Set up Google for SSO with auto provisioning in AAD and set up Self Service Password Reset.
• Use a third party identity provider like OKTA to synchronize the identities and then use Self Service Password Reset.
• Export the accounts from Google with the GAM tool (https://github.com/jay0lee/GAM) and import them in AAD with PowerShell

The solution gets tricky if you’re cloud only and need to synchronize the passwords from one provider to another. As far as I know, there’s no solution to cover this problem and this is why you need to communicate very transparently with your users.

Let’s say you solved the user and password problem, how do you authenticate to Google and SSO apps configured with Google? Simple, just follow this tutorial (https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/google-apps-tutorial)
Basically you will sign-in to Google using AAD and the same will go for the third party apps. Third party apps will go to Google and Google will go to Microsoft. When the authentification is done everything will go back in reverse and you’re authenticated.

Pros
• Longer transition period.
• Lower downtime while re-configuring applications.
• One single password configured on-premises in Active Directory. (if applicable)
• No immediate reconfiguration for custom SSO applications.
• Lower impact on the IT Support team.

Cons
• Double-hop identity might cause lag in authentication and confusion.
• Redirect loops may happen under very slow or unstable internet connections.
• Users will forget to set their passwords and will generate a little back & forth.

Solution 2 – Two passwords for Google and Microsoft

This process involves having two sets of credentials for Google and Microsoft. In this solution, users will have a password for Google and SSO applications and one password for AAD (Azure, E-mail, SharePoint, Office Suite, etc.). The problem here appears when you ask your users to have two passwords for different services.

Pros
• Lower impact on users currently using SSO apps.
• No double hop identity jumps between Google and AAD.

Cons
• Users will have to use two sets of credentials (AAD, Google / SSO non-Microsoft apps)
• User disruption when moving SSO apps from one identity provider to another.

Solution 3 – Hard Cutover

The hard-cutover process involves reconfiguring all the SSO applications to use Azure Active Directory as their primary identity provider. This solution implies that all the SSO applications that are configured to use Google as their primary identity provider are accounted for and documented.

Pros
• One single identity provider between on-premises and cloud.
• Full control over all the SSO / SAML applications.

Cons
• Extremely high user impact.
• Custom SSO applications will require reconfiguration.
• High impact on the IT support team.

I highly recommend you take this approach as a last resort because you will face a lot of issues. This may work in small companies but when you have a lot of users then this becomes a huge issue.

Possible issues

Reverse Federation

Reverse federation might add a double hop authorization flow for applications that are configured to use Google as their primary identity provider. The flow requires an authentication/authorization from Microsoft that goes down to Google and the SSO application. In case of an unstable or very slow internet connection (<1mbps) authentication might fail.

Risks
• Authentication flow failure.
• Corrupted or half cooked cookies.
• SSO Application authorization errors.

Risk Mitigation
• Authentication flow failures occur only on unstable or slow internet connections and will require a retry via an F5 in the browser or retry of the authentication flow via logging again to the application
• Cookies that get corrupted during authentication flow will have to be cleared from the browser and the user will have to retry the authentication.
• SSO applications might throw authorization errors if the user doesn’t exist in the Google or Microsoft Identity system. Verification has to be done to check that the user exists in both Google and Microsoft for the authentication flow to work.

Two passwords for Google and Microsoft

Risks
• Users will not know exactly which service requires what password.

Risk Mitigation
• Applications will require a re-authentication with the new system once they are migrated and will require the user to provide the credentials for the Microsoft Idp
• Users will have to manage two sets of credentials: current set of Google credentials as before and a new set of credentials for AAD.

Hard Cutover

Risks
• SSO application authorization failure.
• SSO application configuration flow failures.
• Re-authentication of SSO and other applications.
• Custom applications failure.

Risk Mitigation
• SSO applications will require to have users propagated correctly via the auto / manual provisioning flow.
• SSO Applications will require to be properly configured for SSO with Azure Active Directory as per the documentation provided by Microsoft.
• Re-authentication using the Microsoft provided credentials.
• Custom applications will require a reconfiguration to be re-pointed to AAD.

I will stop this blog post here as I went on too far with it and it became a huge wall of text. I hope this blog post is useful for you and if you have any suggestions, please write down in the comments ?

As always, have a good one!