Can I use Entra API-driven provisioning to synchronize user data but not provision the user?

[BoucherD]

I'm thinking of scenarios that I've supported using MIM in the past where there is a primary HR system that would feed the user provisioning but there were also one or more secondary systems that would enhance the Identity information with additional attributes. In these scenarios only the HR system would initiate the user provisioning and the secondary systems would only be authoritative for some attributes. If the user were to appear in the secondary system and not the HR system the user would be ignored.

Is this type of scenario currently supported by Entra? If not, is it something that is on the horizon?

[#2]

@BoucherD 

Hi, Darren.

There's no inherent smarts in the Azure provisioning API - that comes from the integration.

I'd make the relatively safe assumption that every integration provides the first part of your scenario (i.e. provisioning), so I'll just speak to the second (joining only).

In the case of using pre-canned integrations, you'd have to check with the integration's vendor.

If you author your own integration, you can make it as complex as you like, in which case the second scenario is quite possible.

In both cases, you're definitely "trading down" in compliance.

HR/API-driven provisioning operates in the "account management automation" space while MIM and every other identity platform operate in the compliance space.

There's key conceptual differences in the data realm is of scope and "statefulness".

The scope of an IDM implementation spans the entire directory service (or any connected platform). The scope of API provisioning is only the subset of identities coming from your HR and secondary system.

On statefulness, I've only seen a couple of vendor integrations where they are best depicted by the following (taken from Learn😞

What's missing - in comparison to any IDM platform you care to choose - is the comparison of changes made directly in the directory services back to the data contained in the source. In the case of MIM, this is achieved through leveraging the metaverse.

This leads to the loss of compliance I mentioned above since if changes to users are effected directly on the account in the directory services, this will never be corrected by the Azure provisioning service (or more correctly, the vendor's integration).

So, using a contrived example, let's say I'm provisioned with a job title of "Cleaner" and by some means I get that changed directly on the account to "Chief Financial Officer". An IDM platform (normally) would come along and change my job title back to "Cleaner" while Azure provisioning will not.

If compliance does not matter to your organisation then Azure provisioning is fine. If MIM was only being used to perform account automation then it was definitely being underutilised.

Cheers,

Lain