When configuring provisioning between Azure and Google federated domains, you will likely reference Microsoft’s documentation on configuring their canned provisioning Enterprise Application at https://learn.microsoft.com/en-us/entra/identity/saas-apps/g-suite-provisioning-tutorial. There is more information here as well: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/configure-automatic-user-provisioning-portal. The procedure outlined here will get you started- however, you will quickly realize that disablements are not synchronizing between the two platforms. I have gone through the trouble of figuring this out, and I’m publishing this article to save you the headache!
Scope – the first trouble with synchronizing user disablements is that, by default, Azure considers disabled users out-of-scope. You do not want your provisioning app to have delete permissions and view your users as out-of-scope! First things first, I would strongly recommend withdrawing delete permissions from your provisioning app. Secondly, we can make Azure consider disabled users in-scope. To do so, you can add two scoping filters. Please note- multiple scoping filters are handled as AND statements; multiple scoping rules within a single filter are handled as OR statements. For this, we want two filters, each with one rule- one stating ‘accountEnabled’ ‘IS TRUE’ and one stating ‘accountEnabled’ ‘IS FALSE’. This way, users with either state are included in the provisioning app scope.
SkipOutOfScopeDeletions – another default behavior in Azure that makes synchronizing user disablements difficult is that by default, a provisioning Enterprise Application will delete users that are out of scope. You should have already withdrawn delete permissions as mentioned previously. But, as an added measure, you can configure your provisioning app to skip out-of-scope deletions. This is not a setting that you can interact with through the GUI. However, Microsoft has an excellent write-up on doing so, and it is quite straightforward. Here is the link: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/skip-out-of-scope-deletions. I would recommend you perform these steps.
Accidental Deletion Protection – There are a few important notes that need to be understood about the default behavior of Accidental Deletion Protection. By default, the ‘IsSoftDeleted’ property in Azure is set equal to the ‘suspended’ property in Google. This is, of course, the property used to indicate a soft deletion event. But, it also indicates a disablement event. If you read the specific verbiage Microsoft uses about their Accidental Deletion Protection, it indicates that it protects against accidental deletions OR disablements. This led to a lot of confusion on my part until I unraveled all of this. Essentially, Azure is intentionally interpreting user disablements as deletions to keep you from accidentally deleting or disabling objects. To do so, the ‘IsSoftDeleted’ property is being set to the inverse of the ‘accountEnabled’ property automatically. Frankly, I find this really hacky. In reality, Google’s ‘suspended’ property is equal to the inverse Boolean value of Azure’s ‘accountEnabled’ property. I confirmed in Google’s documentation that their ‘suspended’ property accepts the ‘false’ value: https://support.google.com/a/answer/1110339. Microsoft details customizing attribute mapping here: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/customize-application-attributes. This can be achieved by using the Expression mapping type, and using the following expression: Not([accountEnabled]). If you’d like to read more about these types of expressions and their syntax, here is a link: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/functions-for-customizing-application-data. Accidental deletion protection places the provisioning application in quarantine if it is detected breaching the deletion (or disablement) threshold: https://learn.microsoft.com/en-us/entra/identity/app-provisioning/application-provisioning-quarantine-status.
On-Demand Provisioning – On-Demand Provisioning is a feature within Azure Provisioning Enterprise Applications that allows for individuals or small batches to be processed. This could come in very handy if you have attempted to synchronize bulk user disablements and your provisioning app has been placed in quarantine, which may be why you have sought out this article. Also, On-Demand Provisioning makes testing with small sample sizes possible, as limiting the scope is not really a great idea.
PSGsuite – I would recommend configuring PSGsuite for your G Suite domain, as it is instrumental in interacting with PowerShell. It is quite straightforward, and the project has excellent documentation: https://psgsuite.io/.
Understanding these items will help you configure your Google provisioning Enterprise Application in Azure. After performing these steps, user disablements will synchronize to your federated Google domain. Afterwards, a disabled user in Azure/Entra (accountEnabled = $false), will become a suspended user in Google (suspended = $true).