Forum Discussion
Connect Sync vs Cloud Sync vs other?
Hi,
Been going through this comparison: https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync#how-is-microsoft-entra-cloud-sync-different-from-microsoft-entra-connect-sync
Both Cloud Sync and Entra Connect, take user and group accounts from On-Prem, and provision (and sync) these to Entra ID (Azure).
Is there, however, a similar free Microsoft tools that would run in the opposite direction? i.e. take existing user and group accounts in Entra ID (Azure) and provision them into an On-Prem Active Directory?
Thanks,
SK
Hi, Shim.
No, there is no free tool from Microsoft to synchronise users created in Azure AD back to on-premise Active Directory.
You also need to consider that if you already run AAD Connect and somehow "synchronise" a user from Azure AD back to Active Directory, then that user can no longer be (fully) managed in Azure AD. Instead, AAD Connect will join the the on-premise account to the Azure AD account making the on-premise account the one which (almost) all management must take place.
If you have a strategic plan to go cloud-native, you don't want to go down this path. It's not even a great outcome for hybrid environments - at least not at the strategic level (tactical exceptions come up from time to time).
Cheers,
Lain
Thank you LainRobertson & Kidd_lp
The background to my question is this:
We have an on-prem AD that is already being synced to Azure AD, via AADConnect.
We also have an on-prem MIM solution, that imports employee data from our HR system and provisions them to the on-prem AD (and AADConnect syncs them to Azure).
Our on-prem environment will remain for quite some time, but we would like to replace MIM with the new Microsoft IGA solutions.
This could potentially mean using Entra IGA and LIfecycle Workflows to import the HR data via a SCIM connector and create new employee directly in Azure, and were hoping there would be a way to reverse the AADConnect tool (which is not the case, as you say).
We will need to revisit our plan.
Many thanks,
SKHi, Shim.
On a technical level, MIM is a very different beast to AAD Connect (despite the latter using the MIM engine, it's been very heavily customised and restricted), cloud sync and user provisioning.
The primary remit of MIM - like other fully-fledged identity platforms (SailPoint, Okta, etc.), is to deliver compliance.
Conversely, the remit of the others - including the newer user provisioning, is automation.
Identity platforms are capable of handling the most complex of scenarios while automation tools are not. Identity platforms also have a bidirectional relationship with integrated systems and can interface with far more systems/platforms.
Conversely, automation tools almost always require complexity to be handled external to them while they loaf about simply creating, updating and deleting unidirectionally.
Some quick examples on differences between compliance and automation:
Example 1
- New staff is created in HR;
- In HR, they are not flagged as being eligible for having IT admin access;
- Someone inappropriately manually gives them IT admin access within AD and/or Azure AD;
- For compliance with organisational policy, this IT access should be revoked ASAP.
In this scenario, a well-implemented identity platform would become aware of this unauthorised change fairly quickly and undo it.
In the case of inbound provisioning, it will never know about it since they do not utilise a bidirectional, stateful representation of the user. Rather, they only push changes out in one direction from HR to AD and/or Azure AD.
Example 2
- Your company comes up with a new policy that must be enforced for all accounts.
This is possible with an IDM platform since it can be scoped to everything in AD and/or Azure AD. It is not possible for the automation tools since they will never encompass all accounts (think service accounts as one commonplace example).
Of course, having an identity management platform doesn't mean you ever really needed it, that it's doing anything complex or even delivering compliance. I've seen a good number of poorly-implemented IDM platforms - MIM in particular - that under-deliver. So, I'm not suggesting the newer user provisioning isn't well suited to your organisation's needs, just that it's not comparing apples to apples, so make sure you fully understand all that your MIM platform is doing for you.
Getting back to your initial scenario, it sounds like the current strategy needs alteration. If you're positive that people being created in Azure AD natively need access to on-premise resources in a way that is only achievable through having an on-premise account, then they should really be being created on-premise and left to AAD Connect to manage the Azure side.
This approach at least allows the user to have a single username and password.
If you go down the path of creating an Azure AD-native account as well as an on-premise account that does not sync to Azure AD, then it's not a pleasant user experience since they not only have two disjointed usernames and passwords, but the added confusion of trying to remember which one to use in which scenario.
Cheers,
Lain
- The main problem with Entra Cloud Sync and Entra Connect is mostly related to small businesses; it is the requirement to install an agent on a server, which might be expensive for small companies due to hardware requirements and the need to purchase an Entra ID P1 license to perform the synchronization.
I have seen a solution where Active Directory Federation Services (AD FS) was used to sync users from different organizations to Entra ID, without the need to deploy a dedicated Entra Cloud Sync or Entra Connect server for each organization. In this setup, the organizations shared the same Windows Server Active Directory forest, and the sync was performed by a custom Powershell script (using the Graph API) that ran every 30 minutes on a Windows Server by using the Task Scheduler. I do not know how much this synchronization solution costs, but it is the cheapest solution I can imagine. This solution cannot perform tasks as device synchronization, but you can synchronize users, groups and password hashes.
However, I would recommend you to actually install the Entra Cloud Sync. The agent is very lightweight and you get a fully managed administration experience in the cloud at a very little cost. The solution that I provided (using AD FS) is not a complete "solution" or "end product" by Microsoft, and the script has to be developed by you personally. This might not cost much money but will cost a lot of development effort. I advise you to just go with the Entra Cloud Sync or Entra Connect (depending on your requirements).
