This post has been updated as of 4/04/2020 to include a link to part 2 where we discuss user provisioning into G Suite from AAD.
What’s the skinny?
As much as I think Office 365 offers a much better overall experience we tend to still see G Suite usage, for Google Classroom, in the K12 market. So I try to ask my customers “How do you make interoperability between these two platforms seamless for your students and faculty?” and typically the answer is “We don’t”. Well that isn’t good enough for me.
That answer is usually because most IT admins are unaware of the integration Microsoft Azure AD has with G Suite. INTEGRATION?? That’s right! A Microsoft product working nicely with a Google Product is a real thing! What a world we live in. But in all seriousness this is such a powerful feature that I hope more K12 and other institutions take advantage of as it truly makes for a better experience for the end users.
So what can be done?
We have two integration points we can make with G Suite from Azure AD:
- SSO – allowing users to use the same credentials as their on-premise AD/AAD accounts
- User Provisioning – allowing for Azure AD to handle provisioning and deprovisioning of users and groups into G Suite automatically
Today’s post is going to focus on SSO, To see how to use User Provisioning check out part 2.
When you configure SSO in Azure AD for G Suite you get the following benefits:
- Controlling access to G Suite from Azure AD
- Allows users to be automatically signed-in to G Suite with their Azure AD Account (and vice versa)
- Manage accounts in one central location – Azure AD. Single pane of glass!
Things to know and have done
To take advantage of this solution you need to have the following:
- An Azure AD subscription
- To take advantage of dynamic groups you need Azure AD Premium P1 or above
- A Google Apps / G Suite subscription
- Azure AD Connect setup with Password Hash Sync or Pass Through Auth if using this in a production environment that is configured with ADFS
- Please see the note in the Traditional Domain Joined Device section of this post for more information
Though not required, I am using and showcasing an Office 365 tenant during this post. Remember that Office 365 uses Azure AD as the foundation for identity in the cloud. When standing up an Office 365 tenant you automatically get an Azure AD subscription spun up along with it. If you wish to only use Azure AD you can still spin up an Azure subscription without the need of an O365 subscription. If you later decided to add an O365 subscription to your Azure only subscription you can do so by following this guide.
I highly recommend you use test tenants to do this first before doing anything in production. Everything you see in my post is done in a demo environment for both G Suite and Office 365.
Architecture overview of Demo
My demo environment wont be setup like your production and/or test tenants. So here is a summary of my two tenants:
- Office 365/Azure AD is cloud only with no identities sourced from an on premise AD. This means that I’m not using hybrid identity however the experience and configuration you see is still identical.
- G Suite is cloud only with no identities sourced from an on premise AD using Google Cloud Directory Sync (GCDS). This means that I’m not using hybrid identity however the experience and configuration you see is still identical.
Once we have followed all instructions in this post we will have simply moved authentication away from G Suite and into Azure AD.
Things I’ve already done
Prior to the steps I’ll be laying out here I’ve already done a few things to have my tenants ready to go which include:
Office 365 vanity domain configuration/setup
Office 365 comes with a pre-configured domain name based on your tenant name resembling tenantname.onmicrosoft.com. In the real world we will want our business domain name (vanity domain) to apply instead which I have configured in my tenant already.
This will require you to add various DNS entries to your external DNS provider to verify and configure services you want tied to these domain names.
You can see I have a primary root domain set to the default with two sub domains added. This is because some institutions like to separate out services, access, and policies based on if they are a student or faculty member. Using a sub domain helps to make that separation more clear and easy to identify. I don’t personally recommend this method, however, I will be using these two sub domains in our example configuration for SSO.
Resource: Configure Vanity Domain in O365
If you are not doing this in Office 365 but instead directly in Azure AD you can follow this guide to setup a Vanity Domain.
Office 365/Azure AD Demo Users
I have also created three users for students and three users for staff. They are properly licensed and ready to go.
Azure AD Security Groups (Dynamic)
Because I want Azure AD to automatically provide access to G Suite based on their UPN I have created a dynamic group to do this for me that I will then add to our G Suite application later on in this post. Note: this feature I’m about to show requires Azure AD Premium P1 however you can create a manual group if you wish to stick with Azure AD Basic.
I created one for students and one for staff:
In each is a simple query rule for membership:
All I’m looking for is that a users UPN contains my string and if it does; add them to the group. This is very simple and only to show how you can use dynamic groups to make assigning access to an enterprise application easy.
Resource: Dynamic Groups in Azure AD
G Suite vanity domain configuration/setup
A G Suite test tenant will require a vanity domain right off the bat. I have used the same root domain of contosoedu.com and added two domains (the sub domains) as well. This configuration matches O365.
Note: these might require external DNS entries as well. Be sure you do not duplicate services in both G Suite and O365. An example is your MX record can only point to one service so be sure where ever your want mail to flow your MX record reflects this. I’m not covering DNS here today but might do a follow up on just that. Remember for the sake of testing you only need to add your domain names to G Suite and do not need to make any additional DNS changes.
Make sure you complete the domain verification process otherwise SSO will fail until this action is complete in the G Suite tenant.
Resource: Configure G Suite Domain
G Suite Demo Users
Because we are not enabling automatic user provisioning in todays post we are going to need to manually create users in the G Suite tenant to match our users in Office 365. I have already created two demo users in G Suite that match their corresponding Staff or Student identity in Azure AD/Office 365. Again this is only because we are not setting up automatic provisioning today.
- First and Last Name match our user in O365
- The primary email matches the User Principle Name in O365
- This is extremely important as we base our SSO process on this
- We allow G Suite to generate a secure password as we won’t be using it to login after SSO is configured
Repeat this for as many demo users as you would like to make in your test G Suite tenant.
Now a quick note about the account you initially created in G Suite when first setting things up. This is your super admin account (owner). It is recommend that any cloud based service such as G Suite and O365 have a break glass account. This is an account that is purely cloud based and not tied to SSO or other services so that you always have access to the tenant. It should never be used for day to day operations, however I will be using mine in G Suite as the only admin for this demo. You can however configure it to use SSO with a matching account in O365 if you so choose by ensuring it matches the UPN of the user in O365 like our demo users above.
Let’s Get Started!
Configure Azure AD Company Branding
Before we can take advantage of SSO we should make sure we have our company branding for the login page setup.
1. Go to: https://aad.portal.azure.com/ and if prompted login with your demo Office 365 global admin account
2. Click on Azure Active Directory from the left nav bar
3. Select Company branding from the list under Manage
4. Click Configure as your status should currently be: Not configured
5. You will need some school marketing assistance here to make a background image, banner, and square logos. These will be used to brand your login page when users go directly to it or are redirected as part of the SSO configuration.
5.1 As you can see I have already created content and added it to the appropriate spot on the company branding blade.
5.2 Note: you can also add a custom username hint and page text
6. Click Save at the top to publish your changes
It can take a bit for these to appear on your login page. We will see my specific demo company branding later as we test SSO!
Resource: Configure Company Branding
Create an Enterprise Application in Azure AD
I will now create an application in Azure AD representing G Suite. Now because this is a gallery application we are able to hit the ground running pretty quickly with little configuration. This is the reason why I believe this should be heavily used in the real world as Microsoft has done a great job making this pretty straightforward.
1. While in Azure AD click on Enterprise applications and then select All Applications
if you closed your tab or left go back to: https://aad.portal.azure.com and click on Azure Active Directory from the left nav bar
2. To add our new G Suite application click on New application
3. In the Add from the gallery box search for G Suite and select the G Suite application listed
4. In the application blade that appears to the right you can choose to leave it all default or change the name if you wish. I will be leaving mine as all default and then clicking Add
Configure SSO for our new G Suite Enterprise App
Now that the application has been added we can now configure SSO. Since we are continuing on from our last step you should be at the G Suite application overview screen. If not simply go to Azure Active Director > Enterprise Applications > and select G Suite from the list of applications in your tenant.
1. Click on Single sign-on
2. Select SAML from the SSO methods
3. We are using the new experience for setting up SSO; this might look differently if you have previously configured SSO in Azure AD applications in the past. Click the Pencil icon to edit the first configuration block
4. Configure the Sign on URL and Identifier (Entity ID) as shown
- Sign on URL: https://www.google.com/a/<yourdomain.com>/ServiceLogin?continue=https://mail.google.com
- Identifier (Entity ID): google.com/a/<yourdomain.com>
Note the highlighted part is custom to your configuration. You only need to change that piece to match your root domain used in both tenants
5. You now need to download the SAML Signing Certificate that will be used in G Suite
6. On the Set up G Suite block, copy the required URLs that we will need to configure things on the G Suite side
At this moment we only need Login URL and Logout URL. You can ignore the Azure AD Identifier for now
We can leave the Azure AD portal open for now but we now need to switch over to G Suite.
Configure SSO in G Suite
If you are not already in your G Suite admin portal please navigate to https://admin.google.com and sign in with your G Suite tenant admin account you setup when making the test tenant. Once logged in you may continue.
1. While on the main admin console click Security
2. Under the Security panel scroll down and select Set up single sign-on (SSO)
3. Check the box next to Setup SSO with third party identity provider and setup the red circled parts first
- Sign-in page URL and Sign-out URL are the URLs you copied/noted from Azure AD before. Paste those into their corresponding field here
- Check the box next to Use a domain specific issuer
4. Click Save when red circled parts are complete
5. Lets now upload the certificate. You will notice in my screen shot above it already shows a cert having been uploaded; when you are setting yours up you will see:
- Click Choose File and select the G Suite.cer we downloaded before from Azure AD
- Click Upload
- Once the cert is uploaded and shows the status circled in orange above click Save again (if presented but it should auto save)
6. The Change password URL circled in green is optional. If you are going to allow self service password resets to your students/faculty you can configure the redirect by using this URL: https://account.activedirectory.windowsazure.com/changepassword
- If you are syncing identities with on premise AD self service password reset requires password writeback to be enabled and is an Azure AD Premium P1 feature
- Resource: Self Service Password Reset
We now have SSO configured on both platforms!
Allow access to our G Suite application in Azure AD
Now that SSO is configured we need to allow users to access the application. To do this let’s go back to our G Suite application tab we left open from before in Azure AD. Closed it? Simply go to Azure Active Director > Enterprise Applications > and select G Suite from the list of applications in your tenant.
1. Click on Users and groups in the G Suite application pane
2. Click Add user
3. Click on Users and groups to search for a test user or group you would like to provide access to the G Suite application. Now because I have already created two dynamic groups that include the users I wish to have access to G Suite; I have selected those two groups as shown:
4. Click Select and then Assign
5. We now see in our Users and groups pane that my two groups are shown
Going forward any user who is automatically added to these two dynamic groups will be able to use SSO to sign into G Suite without IT being involved. They will also lose access upon their departure (deprovisioning).
We are now ready to test!
With everything configured and permissions assigned to my two dynamic user groups we can now test SSO! I’m going to test three different methods of accessing Gmail.
In most cases students/faculty might go directly to: https://gmail.com to quickly get access to their email (assuming you are not using Exchange Online which makes me sad). Let’s see what the user experience will look like on a non managed device!
1. Go to https://gmail.com
2. Type one o fyour test users email addresses and then click Next or press enter
3. Now we see some magic happen. You’ll notice the user is redirected to our branded Azure AD login page where the user will need to enter their email address again
Notice our back ground image, page text, and before I typed in Adele’s email we could see the place holder text.
4. Once you have entered the email address click Next or press enter
5. Type the users password (remember this is their Azure AD / Office 365 credentials) then click Sign in!
6. Because this is the first time we have logged into G Suite as this user we are presented with Googles Welcome EULA. Click Accept if you so choose (need to in order to continue)
7. We are now in our Gmail inbox and G Suite using our Azure AD Creds!
8. Now that we are logged into Gmail we could also open a new tab in our browser and navigate to something like https://office.com which will then automatically sign us in using our same Azure AD credentials since we are using SSO!
Microsoft App Portal
To make things easier for our end users Microsoft provides an application portal where all applications that are integrated with Azure AD and presented to the user will appear. This allows for a single point of entry where the user can then jump around to the various applications while only signing in once. This also allows us to skip entering our email address twice as shown in the process above. We are still doing this on a non managed device.
1. In a fresh browser (Private session etc) go to https://myapps.microsoft.com/contosoedu.com (replace contosoedu.com with your tenant domain). By appending the vanity domain to the URL it will take the user directly to your branded login page. If a user goes to the normal url of https://myapps.microsoft.com the branding will not appear until after they enter their email address. Either method is fine; just depends on what you prefer.
2. Sign in with one of your test users as we did before
3. You will now be presented with the My Apps Portal
4. If you click on G Suite the user will be presented with a new tab and be automatically signed into their Gmail inbox!
Now the user can go back and forth without being prompted for credentials between the two environments until they sign out of either one or their session times out!
Azure AD Joined Device SSO
In your production environment you are going to have devices that are typically domain joined. This demo is showcasing the SSO experience on a device that is purely Azure AD Joined (managed in the cloud) however you can still take advantage of a similar experience with your traditional domain joined devices to mentioned later in this post.
1. I’m currently logged into a device that is Azure AD Joined as a faculty member named Arden. We can see the device is joined and managed here:
2. We will then head over to Edge and navigate to https://gmail.com and enter our users email address and click Next:
3. This time instead of having to enter our email address again in our branded login page you’ll notice Edge is pulling in our account connected to Windows. Arden will simply click his account as shown:
4. We are now in Gmail without being prompted for a password at all!
And since we are signed into our device with our Azure AD credentials I can now navigate to my other integrated applications such as https://office.com all without being prompted.
Tip: if you create a CNAME like mail.contosoedu.com (with your domain though) and have it redirect to https://mail.google.com/a/contosoedu.com (again replace my domain with yours) you can have the initial Google Sign in page skipped.
Or you can simply have your user start at https://myapps.microsoft.com which will auto sign in on our Azure AD Joined device and then the user can click on G Suite. Done and Done!
What about Chrome on an Azure AD Joined Device?
By default Chrome on an Azure AD only joined device we will not be able to take advantage of Seamless SSO out of the gate as Chrome and IE will require the Intranet Zone to be configured to honor that (let’s hope you are not using IE…). So Microsoft released an extension to help with this.
The extension can be deployed via your normal deployment/Chrome management methods adding it to the top nav bar as so (Windows flag icon):
Once added the user does not need to interact with the extension by any means as it will automatically use the logged in Windows users credentials to sign into services such as our Azure AD App portal and Office 365. Allowing for your seamless sign on experience without the need of traditional domain joining.
Traditional Domain Joined Device SSO
Above we saw an Azure AD only joined device and the experience Edge provides along with the extension available to use with Chrome to provide a similar experience. This time we will talk about how to take advantage of our new SSO capabilities while providing that seamless like experience on a device that is only joined to your on premise domain.
This requires following the amazing Microsoft doc on setting up Seamless Single Sign On which has some pre-reqs of it’s own such as setting up password hash sync, aka PHS, or pass through authentication, aka PTA, if Office 365 is currently configured to send requests to ADFS.
This is an authentication change for only Office 365 services (Microsoft) and shouldn’t have an affect on other applications in your ADFS configuration; but as always test in a dev environment first before making big changes like this! Once auth is configured to go against Azure AD directly (managed) instead of ADFS (federated) you can then follow along the Seamless Singles Sign On guide noted above. Why reinvent the wheel right?
Essentially you will deploy an Intranet Zone URL of: https://autologon.microsoftazuread-sso.com which will allow IE and Chrome to automatically sign in as expected. But what about Edge? Sorry no luck there… Edge currently does not adhere to the Intranet Zone list that IE and Chrome currently do. So in this configuration Edge will not function as expected. So how do we provide a better experience?
Hybrid Joined Device SSO
A hybrid joined device is just that, a device that is both joined to your on premise domain as well as joined to Azure AD. By doing this we can mix and match solutions to best fit our needs such as:
- Hybrid joined device that uses the Intranet Zone list to cover IE and Chrome while Edge will be using the Azure AD joined piece to allow seamless single sign on as noted before in our Azure AD Joined Device section
- Hybrid joined device that does not use the intranet zone list but instead uses the extension for Chrome to allow for seamless sign on while again Edge will function as expected since the device is also AAD Joined.
Either way we are covering the two primary browsers in this scenario which is Chrome and Edge. (IE requires the Intranet Zone configuration / Firefox requires added configuration)
With this SSO configuration your users will have a much more cohesive experience while flipping back and forth between platforms without having to think twice. This allows you to continue to use your investments in the Google platform while taking advantage of advanced security features Azure AD can bring to the table. Adding to the experience an Azure AD / AD Domain Joined device to enhance the sign in once mentality can set you apart from other institutions!