Integrating Azure AD and G-Suite – Single Sign-On

Posted on by
Integrating Azure AD and G-Suite – Single Sign-On

Hi everyone,

After working through the Azure Active Directory (AD) and Amazon Web Services (AWS) integration I thought it’d be fun to do the same thing with Google Apps.  Google provides a generic tutorial for single sign-on that is severely lacking in details.  Microsoft again provides a reasonable tutorial for integrating Azure AD and Google Apps for single sign-on.  Neither gives much detail about what goes on behind the scenes or provides the geeky details us technology folk love.  Where there is a lack of detail there is a blogging opportunity for Journey Of The Geek.

In my previous post I covered the benefits of introducing Azure AD as an Identity-as-a-Service (IDaaS) component to Software-as-a-Service (SaaS) integrations.  Read the post for full details but the short of it is the integration gives you value-added features such as multifactor authentication with Azure Multifactor Authentication (MFA), adaptive authentication with Azure AD Identity Protection, contextual authorization with Azure AD Conditional Access, and cloud access security broker (CASB) functionality through Cloud App Security.  Supplementing Google Apps with these additional capabilities improves visibility, security, and user experience.  Wins across the board, right?

I’m going to break the integration into a series of posts with the first focusing on single sign-on (SSO).  I’ll follow up with a post exploring the provisioning capabilities Azure AD introduces as well as playing around with Google’s API.  In a future post I’ll demonstrate what Cloud App Security can bring to the picture.

Let’s move ahead with the post, shall we?

The first thing I did was to add the Google Apps application to Azure AD through the Azure AD blade in the Azure Portal. Once the application was added successfully I navigated to the Single sign-on section of the configuration. Navigate to the SAML Signing Certification section and click the link to download the certificate. This is the certificate Azure AD will be using to sign the SAML assertions it generates for the SAML trust. Save this file because we’ll need it for the next step.

I next signed up for trial subscription of Google’s G Suite Business. This plan comes with a identity store, email, cloud storage, the Google productivity suite, and a variety of other tools and features. Sign up is straightforward so I won’t be covering it. After logging into the Google Admin Console as my newly minted administrator the main menu is displayed. From here I select the Security option.googlesso1

Once the Security page loads, I select the Set up single sign-on (SSO) menu to expand the option.  Google will be playing the role of the service provider, so I’ll be configuring the second section.  Check the box to choose to Setup SSO with third party identity provider.  Next up you’ll need to identify what your specific SAML2 endpoint is for your tenant.  The Microsoft article still references the endpoint used with the old login experience that was recently replaced.  You’ll instead want to use the endpoint https://login.microsoftonline.com/<tenantID>/saml2.  You’ll populate that endpoint for both the Sign-In and Sign-Out URLs.  I opted to choose the domain specific issuer option which sets the identifier Google identifies itself as in the SAML authentication request to include the domain name associated with the Google Apps account.  You would typically use this if you had multiple subscriptions of Google Apps using the same identity provider.  The final step is upload the certificate you downloaded from Azure AD.  At this point Google configured to redirect users accessing Google Apps (exempting the Admin Console) to Azure AD to authenticate.

googlesso2

Now that Google is configured, we need to finish the configuration on Azure AD’s end.  If you follow the Microsoft tutorial at this point you’re going to run into some issues.  In the previous step I opted to use a domain specific issuer, so I’ll need to set the identifier to google.com/a/geekintheweeds.com.  For the user identifier I’ll leave the default as the user’s user principal name since it will match the user’s identifier in Google.  I also remove the additional attributes Azure AD sends by default since Google will discard them anyway.  Once the settings are configured hit the Save button.

googlesso3

Now that both the IdP and SP have been created, it’s time to create a user in Google App to represent my user that will be coming from Azure AD.  I refer to this as a “stub user” as it is a record that represents my user who lives authoritatively in Azure Active Directory.    For that I switch back to the Google Admin console, click the User’s button, and click the button to create a new user.

googlesso4

Earlier I created a new user in Azure AD named Michael Walsh that has a login ID of michael.walsh@geekintheweeds.com. Since I’ll be passing the user’s user principal name (UPN) from Azure AD, I’ll need to set the user’s Google login name to match the user’s UPN.

googlesso5

I then hit the Create button and my new user is created.  You’ll need that Google assigns the user a temporary password.  Like many SaaS solutions Google maintains a credential associated with the user even when the user is configured to use SSO via SAML.  Our SP and IdP are configured and the stub user is created in Google, so we’re good to test it out.

googlesso6

I open up Edge and navigate to the Google Apps login page, type in my username, and click the Next button.

googlesso7

I’m then redirect to the Microsoft login page where I authenticate using my Azure AD credentials and hit the sign in button.

googlesso8

After successfully authenticating to Azure AD, I’m redirected back to Google and logged in to my newly created account.

googlesso9

So what happened in the background to make the magic happen?  Let’s take a look at a diagram and break down the Fiddler conversation.

googlesso10

The diagram above outlines the simple steps used to achieve the user experience.  First the user navigates to the Google login page (remember SP-initiated SSO), enters his or her username, and is sent back an authentication request seen below extracted from Fiddler with instructs to deliver it back to the Azure AD endpoint for our tenant.

googlesso11

googlesso12.png

The user then authenticates to Azure AD and receives back a SAML response with instructions to deliver it back to Google. The user’s browser posts the SAML assertion to the Google endpoint and the user is successfully authenticated to Google.

googlesso13.png

googlesso14.png

Simple right?  In comparison to the AWS integration from an SSO-perspective, this was much more straightforward.  Unlike the AWS integration, it is required to have a stub user for the user in Google Apps prior to using SSO.  This means there is some provisioning work to perform… or does it?  Azure AD’s integration again offers some degree of “provisioning”.  In my next post I’ll explore those capabilities and perform some simple actions inside Google’s API.

See you next post!

30 thoughts on “Integrating Azure AD and G-Suite – Single Sign-On”

    • Hi Han. Are you talking about setting up an email alias for the account in Google apps? I haven’t done that yet, but I can give it a try this weekend.

      Microsoft has some type of “provisioning” functionality which may provide some degree of synchronization. I haven’t tested it yet but plan to in my next post. Keep an eye out for it.

      Thanks for your feedback and I’ll let you know what I find out about the alias component.

      Like

      Reply

  3. Pingback: Integrating Azure AD and G-Suite – Google API Integration Part 1 | Journey Of The Geek

  4. Thank you so much for putting this tutorial. I am still a new explorer around azure and was tearing my hair out with sso and google. Went through your article and suddenly had that moment where things just worked its like finding a ray of sunshine after staying in darkness for so long. Really appreciate your efforts and please carry on with the good work.

    Thank you

    Liked by 1 person

    Reply

  5. Hi,

    I need to allow my users access to Azure AD services using G Suite ID’s. Will the same setup work for this or I need to configure things a bit differently.

    Thanks in advance

    Like

    Reply

    • Hi Ravi,

      If I’m understanding right, your primary requirement is your users use a single identity to access both G-Suite and Azure AD. If that’s correct, you could leverage the SSO pattern, but you probably wouldn’t need the provisioning pattern unless you want to make Azure AD your authoritative source for identity data. You may want to think about that due to the extensive integration Azure AD has with third party apps. Microsoft if ahead of google right now in that space.

      I’m assuming you use a unique domain for your users in G-Suite and that you can prove ownership of that domain. If that’s the case you could register your domain in Azure AD and provision matching identities in the Azure AD tenant. From that point forward the pattern of access would mimic the SSO flow documented in my blog and Azure AD would be your authoritative source for user credentials (passwords).

      I believe Google can act as an IdP so you could theoretically do the reverse where Google is the IdP and Azure AD is the SP. You would lose out on some features of Azure AD such as it’s self
      Service password reset portal, identity protection, and some of the controls and intelligence it has around enforcing good password hygiene.

      Hope that helps!

      Like

      Reply

  6. Can this be enhanced to use AD device certificates (or some other device attribute) to ensure that approved users can only access G Suite from approved devices?

    Like

    Reply

    • Hi Njoy. You could incorporate the use of Azure AD Conditional Access to create a rule that allows only managed devices access to G-Suite. By using Azure AD as your IdP, you can take advantages of the other IDaaS features to enforce additional controls around the the context of the user’s authentication, such as the user’s device.

      Like

      Reply

  7. Thank you for the article Matt and it has helped me get a step closer to where I need to be. My scenario is the my organization has a fully populated list of O365 accounts (manually created not synced with on prem AD). I have begun a pilot of Azure by adding a dozen P1 licenses (syncing with AD via security group). We also have a fully populated list of Google Apps/GMail users as we use gmail for domain email (again, manually created, not sync’d).
    My task is trying to get everything to play nice without breaking anything. I’d like to implement SSO for our pilot Azure P1 users without breaking the reset of the organizations sign on to Google using their independent usernames/passwords. Do you have any advice?
    Thank you,

    Like

    Reply

    • Hi Jon,

      Some vendors that provide for integration with an Identity Provider via SAML will offer a separate URL for SSO and another for non-SSO. For others the decision is much more binary where it’s SSO for the entirety of the account (typically exempting a built in root/admin user).

      I’m not sure where Google falls, but it’s worth exploring that option.

      Like

      Reply

  8. Hi Matt,
    Great tutorial! The only problem I have is that once a user enters their email address into the initial Google login page, it is then redirected to the MS login page fine, BUT it does not pass the username/email address, so the user has to re-enter it. What am I missing?!
    Thanks

    Like

    Reply

    • Hi Stuart,

      I’d suggest doing a Fiddler capture of the redirect from Google to Azure AD. Dig into the session and see if Google is passing the username along in a query string or something similar. That will be a good first step.

      Let me know what you find!

      Like

      Reply

    • I have this same problem. Did you ever find a solution? Ultimately, the SSO works, but the user has to enter their e-mail address twice, which is undoubtedly annoying.

      Like

      Reply

      • Jason, use Fiddler and capture what Azure AD is passing as the unique identifier. More than likely the attribute Azure AD is passing in the claim within the SAML assertion to G-Suite isn’t the same as the unique ID G-Suite is using to map the users their accounts.

        Once you figure out the disconnect, you can modify the claim rules in Azure AD to pull from the right attribute (assuming you have it populated in Azure AD).

        Hope that helps!

        Like

  9. Hi, thanks for the article. About how much time this take to get set up and tested, seems like maybe 20-40 hours. did you run into a lot of issue that required troubleshooting?

    Like

    Reply

    • Hi Brent,

      Thanks!

      I do all my blog work in my spare time at night after the wife and kid go to bed. This means I typically get about 2-4 hours a night to work on any given entry. Most individual posts take anywhere from 3-5 nights depending on the complexity and how deep I dig.

      The technical execution of the solution took maybe 30 minutes. This was a while back but if I recall the series took many hours, primarily due to reading documentation, examining Fiddler captures, and playing with the Google API which wasn’t well documented at the time.

      The only problem I ran into was with the “provisioning” portion of solution. It was throwing a cryptic error that seemed to work itself out after I gave up late in the night and tried the next night.

      Thanks for reading!

      Like

      Reply

  11. Great article! How about the other way. If I wanted to have the GSuite tile on office365 portal, and have a 1click login via there?

    Like

    Reply

  12. Question; what will happen to GSUITE MFA (users are using MFA), and then you integrate this SP to AAD with an existing MFA too?..

    Like

    Reply

    • I’m not 100% sure if the integration has changed since I wrote up that initial blog, so buyer beware. The MFA experience would depend on how the identity provider and service provider have configured their services. The identity provider would have the option of passing a claim in the assertion/token indicating the user had authenticated with MFA and the service provider would have the option to trust that claim or require another MFA challenge using it’s own MFA system.

      So in short, the answer is it depends. 🙂

      Like

      Reply

  13. I have a situation where my AAD upn is one domain me@company.com, but my Google identity is another me@company.org. me.company.org is also an alternative email address associates with my AAD account. This value is stored in AAD along with several other email addresses as a multi value array, so I’m guessing it cant be used to uniquely identify the user by matching the email addresses.

    Id like to use a unique identifier such as StaffNo or if an email address must be used I would like to store me@company.org as the value of one of the CustomAttributes and use that.

    Can this be done.

    Like

    Reply

    • Hi there. It’s been a long time since I did this integration, but assuming you can store that value in another attribute you shouldn’t have a problem passing it as the unique identifier Google is expecting.

      Like

      Reply

      • Yes thats exactly what I did. Used ADD connect to add a value to extensionAtribut10 using the expression Word([userPrincipalName],1,”@”) & “@company.org” That then synced across to AAD and could be used to replace values in the User Attributes and Claims section. The only other problem I had was an error when logging out that was resolved by replacing the logout url in the Google config with https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0

        Like

  14. Pingback: Google Cloud Platform federation options in Azure Active Directory

  15. Pingback: Opcions de federació de Google Cloud Platform a l'Azure Active Directory - Octazenta

Leave a comment