G Suite SSO Provisioning accounts with Azure AD and manually deleted accounts in Azure AD

We had a customer who uses G Suite as primary Identity Provider. So user accounts are created at the Google site. We have added the SSO Office 365 connection and enabled user provisioning towards the Azure AD environment.

Now one of the administrators has deleted some user accounts within Azure AD.

The issue

The issue the customer is facing is that the removed users in Azure AD could not access the company Sharepoint website anymore. Pretty much a logical case, but a simple solution does not really exist…

When checking the logs within the G Suite SSO application we see an error log of the Provisioned users. I saw the following error:

d.test@customer.nl,45003,"StatusCode: 404 : Not Found : {
    error : {
      code :  Request_ResourceNotFound  
      message :  Resource '215ed45c-0012-4d87-b86a-14ebcae41e44' does not exist or one of its queried reference-property objects are not present.  
      innerError : {
        request-id :  9a00c647-2217-4046-9ff6-ed3583034810  
        date :  2019-07-10T15:31:39 
     }
   }
 }",

Ok, this looks like a Microsoft Graph API error, where the Google Provisioning process is trying to find a resource based on the Id (within Azure AD the ObjectId field – basically the primary Id of a specific user). This Id is of type GUID and when a user is removed and recreated the ObjectId will be recreated again, and this ObjectId can’t be changed manually on the Azure AD site.

Because of this missing account, SSO with G Suite doesn’t work either. So a user wants to login into a Microsoft resource and Microsoft claims, the user does not exist. Again this is a logical result.

The solution

So recreating the user within Azure AD will not necessarily work directly. You can’t create a user within a federated domain, if you try to create the user from the Azure Portal site you will receive the following error:

You can’t add users to a federated domain. Select a different domain and try again.

You have to add the users via a PowerShell command:

Connect-MsolService
New-MsolUser -UserPrincipalName "d.test@customer.nl" -DisplayName "Daniel Test" -FirstName "Daniel" -LastName "Test" -UsageLocation "NL" -ImmutableId "d.test@customer.nl"

Now the user will be created in the federated domain without any issues. Very important is to add the ImmutableId. This ImmutableId is the link to connect the Azure AD federated domain with the G Suite IdP.

If we now go to the https://myapps.microsoft.com and logon with our account you see you will be redirected to Google to authenticate with your G Suite username and password. The user can logon to the Azure and Office environment with his or her Google identity. So the SSO link is restored.

There is a but…

Unfortunately, there is: when you update the user settings in G Suite these settings are not propagated to Azure AD anymore. After investigating and contacting Google support they confirmed the following process takes place:

1. The user is (manually) created in G Suite
2. G Suite SSO Provision process event is triggered and creates the user with the MS Graph API in Azure AD
3. The ObjectId of the created Azure AD user ID (Objectid) is returned by the MS Graph API (https://docs.microsoft.com/en-us/graph/api/user-post-users?view=graph-rest-1.0&tabs=http#response) is stored somewhere within the G Suite. I assume this because of the error in the Gsuite SSO Provionsing logs
4. As the resource GUID is the ObjectId of the removed user. In a provisioning cycle, you see the above error with a 404. Where I only can imagine that the G Suite SSO provision process is calling the MSGraph API – PATCH with the (Object)Id instead of the UPN (email address in this case): https://docs.microsoft.com/en-us/graph/api/user-update?view=graph-rest-1.0&tabs=http

Googles support response is that unfortunately there is no way to change the Id within the Google G Suite or via an API (at this moment). Another option is to remove the original user from G Suite and recreate the user. I’m not a Google G Suite specialist but I think this last one will bring a lot of extra work and risk in transferring settings and data.