What’s the skinny?
Hello ContosoEDU world! In a previous post, back when our blog basically first launched , we discussed how to integrate G Suite with Azure Active Directory (AAD) for Single Sign On. We briefly touched on the fact you can also leverage user provisioning so that you could simplify your environment and remove the need for Google’s sync tool. Well this post is going to touch on that very topic! Yay!
So what can be done?
Azure AD includes a connector for user provisioning as part of the ongoing objective to make being productive much easier and safer for everyone. This user provisioning service enables an organization to leverage Azure AD to not only be their source of authentication and SSO but also manage the life cycle of users who are allowed access to an application like G Suite. More specifically with this you can provision users and groups of your choosing from Azure AD to G Suite without the need for the Google Cloud Directory Sync tool.
But why do that if you already have Google Cloud Directory Sync (GCDS) in place? Well to be honest it’s completely up to you. There are limitations to what Azure AD is able to do today with provisioning into G Suite which you will need to evaluate prior to making the cut over in production. For example Azure AD cannot delete a user it’s provisioned into G Suite it can only disable said user which for some institutions may be a deal breaker.
Things to know and have done
To take advantage of Azure AD’s provisioning integration with G Suite you will need the following:
- An Azure AD tenant (which you have with your Office 365 subscription)
- A G Suite tenant (which is why I’m assuming you are here)
- A user account with admin permissions in both environments
Note: Single Sign On is not a requirement here but truly does add numerous benefits to both the end user and your security team. I highly recommend you integrate SSO first before continuing.
Architecture overview of demo
My demo environment won’t be exactly like your production and/or test tenants; so let’s talk about it for a second.
- I have an Office 365/Azure AD tenant that is cloud only with no identities sourced from an on-premises Active Directory. This means that I’m not using hybrid identity, however, the experience and configuration you see is still nearly the same.
- My G Suite tenant is also cloud only with no identities sourced from on-premises Active Directory using GCDS. Just as my O365 tenant.
Once this post is finished I will have removed my need to manually create users in my G Suite tenant and instead can rely on Azure AD doing this for me. In your scenario you will have removed the core need of GCDS to create user accounts for you.
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. These steps include the following items:
- Vanity domains are registered in both G Suite and Azure AD
- Test users are in Azure AD with two being in G Suite already (more on this in a bit)
- G Suite has been added to Azure AD as an enterprise application
- Security groups have been added to G Suite app in Azure AD allowing them access to the application
- SSO has been configured between Azure AD and G Suite (making Azure AD the authentication source)
If you need a refresher on how to get the steps above completed you can check out the original post regarding integrating G Suite with Azure AD which will cover a majority of what you need to know. You can learn more about adding vanity domains in Office 365 Azure AD in the resource links below.
G Suite users
Since we are wanting to enable user provisioning I have purposefully left my G Suite tenant nearly empty this time around. I did however create two user accounts intentionally so we can see if the user experience is changed at all for users already in G Suite like when making the cut over from GCDS to Azure AD.
As you can see above I have a student account, Al Fredrickson, and a staff member, Alfonso Camara, who were manually created in G Suite. They both show as active and are configured with SSO so they have recently been inside their G Suite accounts already.
User access to G Suite application
As mentioned in my list above I’ve already created two security groups that are assigned to my G Suite application in Azure AD (AAD).
As you can see above my two security groups are assigned to the application. If we look at one of our groups we can see a list of the test users who then are allowed to access and use G Suite. Currently we only technically have Al from our example above in G Suite so he is good to go. However, if Alex or Adele tried to go to GMail or G Suite in general it would fail since they don’t have an account even though we have the app projected into their Microsoft My Apps portal. We would have to manually create them or leverage GCDS in the past.
Keep some stuff in mind before moving on
- Always test things out in a dev instance of any of your environments and do not rely purely on this post (you are moving on at your own risk)
- Microsoft recommends that you test user provisioning with a single Azure AD user before leveraging larger groups of users. You may assign additional users/groups as you complete your testing.
- When assigning a user to G Suite, you will need to select any valid application-specific role, if available. Any users with just the defaults will be excluded from user provisioning.
- Google recommends to use a special “sync” account that you create and use only for user provisioning. This is not a bad idea in production environments as admins can come and go. In my example I will be using my own super admin account; I would suggest your create a sync account that is also a super admin account so it does not get caught by SSO and is not tied to a specific person.
Warning: You are going to begin making changes to your environment that may cause users to be removed/modified use caution and test thoroughly.
Getting G Suite ready for the big day
Before AAD can start doing it’s awesome thing we need to get G Suite ready for prime time. This requires us to enable SCIM provisioning in our G Suite tenant. Not familiar with SCIM? System for Cross-Domain Identity management (SCIM) is a user management API that allows for automatic provisioning of user and groups between applications and your identity store such as Azure AD (AAD). This is handy for applications beyond just G Suite as well.
Resource: Build a SCIM endpoint with Azure AD
First we need to sign in to our G Suite Admin console with an administrator account.
We will then select Security either from the links on the dashboard or under the hamburger navigation menu in the upper left hand corner.
Next we will scroll to the bottom or until you see API Permissions and click on that option. Enable each service for API access.
We now need to ensure our chosen admin sync account (in my case my normal admin account) is able to leverage the Admin API’s available in G Suite. To do this go to your admin dashboard and select Admin Roles > Super Admin > Privileges.
Then ensure all Admin API permissions are checked.
Configure automatic provisioning for G Suite in AAD
We are now ready to enable the feature we’ve been waiting for. So head over to your Azure AD portal then select Enterprise Applications, then select All Applications.
Now select your G Suite application that you’ve already integrated previously or recently from your application list. Once in the overview pane for your G Suite application select Provisioning.
Now click the drop down and change it from Manual to Automatic. Then expand the section for Admin Credentials.
Note: if you see an error like the one shown below it means you are using the direct Azure AD link/portal (https://aad.portal.azure.com) which in this case does not support the needed access to authorize the Graph API to reach out to Google. Because of this you will need to make sure you are in the normal Azure AD blade (https://portal.azure.com).
To authorize Azure AD click on Authorize. This will prompt you to sign in to your G Suite tenant using the admin credentials you wish to be tied to the provisioning service. You will allow the application Azure Active Directory access to the requested services.
Click on Test connection to ensure we have properly configured everything so far. We should see a toast notification in the upper right hand corner with our results.
It’s also suggested to provide a DL, Shared Mailbox, O365 Group, or admin email address for notifications when failures occur. Before we can continue click Save so that our credentials for the admin account stick. Don’t worry this does not turn things on just yet but allows us to continue configuring the provisioning service.
We are now ready to set up our mappings. A “mapping” is common in the world of provisioning where we tell the service how to take the meta data of a user from Azure AD, in our example, and apply that data to the target which is G Suite. This is needed as not all services use the same terminology or attribute names. For example G Suite really don’t know what a userPrincipalName is which is extremely important in the world of Microsoft.
By default Azure AD has provided two mapping groups for us out of the box using the standard schema (objects and their perspective attributes) that we have available to us in both Azure AD and G Suite. We can see that we are going to synchronize Azure AD users and groups to G Suite! Awesome! We can dig a bit deeper if we wanted to customize things a bit further too; just click on the mapping group for example users to G Suite.
I’m not going into too much detail here as there is a lot to grasp but let’s at least cover some basics of what you can do (this will also be the same for the “Groups to G Suite” mapping).
- First we can see that the attribute mapping is enabled
- Source Object Scope is where we could create scoping filters to only provision users/groups based on specific attributes. I.E. only users with a job title of Manager or only those in the Sales Department etc.
- Since we are only allowing those in our application security group we don’t need to create customer scoping filters.
- Target Object Actions are the actions we are allowing this service to use which are to create, update, and delete.
- We then get to the meat of things which is our Attribute Mappings
Attribute Mappings is the list of attributes from AAD that we are then flowing over into G Suite. The first line shows that we are “translating” userPrincipalName into primaryEmail which is the name of the attribute in G Suite.
You can see all the attributes AAD decided to flow over by default whch you can delete if you wish to not bring that value over. Ones that have the Delete button disabled are considered required.
We can also edit the attribute mappings by clicking any one of them and viewing the Edit Attribute pane.
We can changes like the mapping type. Looking at employeeID we could set the mapping to Direct which means it pulls the value used in Azure AD or we could change it to something like an expression if we wanted to modify the current value and add a prefix/suffix etc. There is much more you can do as will. For now we will continue with everything as is.
Resources: Scoping filter tutorial
We are now ready to enable automatic provisioning. Remember this will begin to make changes to your G Suite tenant once we save the rest of our configuration!
Click on next to Provisioning Status. Then select Sync only assigned users and groups from the drop down scope.
We will now click on Save from the menu along the top. This will enable and begin the synchronization process of the users we scoped to. Since we are using a small scope of users this shouldn’t take long; remember you should be testing with one to start with anyways.
The initial sync will always take longer to perform than subsequent syncs. The sync services will run approximately every 40 minutes so long as the provisioning service is enabled and able to talk to G Suite. Let’s look at our results!
We can see that in our provisioning settings window we have the ability to quickly see the status and quick statistics of our most recent sync. Ours here shows that we had 6 users flow on over to G Suite which is what I expected and wanted! Great start.
Resource: Learn more about reporting on automatic user provisioning
Now if we flip over to our G Suite admin center and look at our user directory we can see our two previously created users (manual) along side our new additions that were created by Azure AD!
Previously created users experience
Now that auto provisioning is enabled and working let’s login as a user that was already in G Suite before. If you remember correctly we had two users that existed prior to us making this change: Al Fredrickson and Alfonso Camara. Let’s login as Alfonso and see if anything changed for him.
Alfonso went over to https://myapplications.microsoft.com and click on the G Suite application as he always has in the past (yes he could also just go straight to https://gmail.com too).
Clicking on the application brings him to his G Suite account as expected and we can see his previously created items in Google Drive are still there!
Newly created users
Also remember we had other students/users in our security groups in Azure AD that had a previous experience of not being able to login to G Suite at all. This was because they had access to the app in Azure AD however Contoso EDU IT never got around to manually creating their accounts in G Suite. Now let’s see what Adele’s experience looks like.
Adele, like Al, goes to https://myapplications.microsoft.com to click on her G Suite application as before. This time instead of an error she is welcomed by Google!
Once she accepts Googles EULA she is then greeted with her brand new account and we can see her user info is as expected!
Group syncing to G Suite
You may have noticed that my two security groups didn’t show up in the sync summary and they both eventually showed an error. This is because they are standard security groups without an email address (aka they weren’t a mail enabled security group). G Suite requires the group have an email address even if we never plan to use it as anything more than permission based. So again because of this my G Suite – Staff and G Suite – Student groups did not flow over to G Suite.
Now I could just go back and create new mail-enabled security groups and replace my existing ones and call it a day but that’s not good enough for me. Specially since we can’t fully manage mail-enabled security groups in Azure AD; so our best and fun option is to adjust our attribute mapping!
So head back to your provisioning settings for your G Suite application > expand mappings > and click on Synchronize Azure Active Directory Groups to G Suite. We are now presented with our attribute mappings as before but not as much as our user group. The attribute we are having an issue with is our first line of mail sourced from Azure Active Directory to email in G Suite. Let’s click on that guy to edit it.
I’m going to change our mapping type from Direct to Expression and use a custom expression to: Join our display name (after removing spaces) with a constant “@contosoedu.com” domain. Save this attribute mapping and return to your provisioning settings window. You will need to wait for the next sync cycle or you can force a sync by using the check box Clear current state and restart synchronization.
So using one of our groups as an example this will take the display name of: G Suite – Staff and remove the spaces giving us: GSuite-Staff then joining it with “@contosoedu.com“. In G Suite we will see the group with an email address of “email@example.com“! yay!
Now with our groups syncing we can use them to add Google specific policies such as access to only certain apps etc. within the Google Admin Center.
We now have Azure AD set up to provision users and groups that are scoped to our application, G Suite, without the need to manually do this or use Google’s own sync tool! This allows us to automatically give users are who are authorized to use G Suite an account without IT intervention thus allowing for a more seamless on-boarding experience for students and staff/faculty alike.
With this we now have a far more unified provisioning and reporting tool (Azure AD) to give us greater insights into our environment and connected applications. Now you could even take this to another level and use Microsoft Forms and Power Automate as a request tool to send approval workflows and then add the requester to a group that is then allowed to use XYZ app and get’s provisioned auto-magically! Sweet!