The (near) perfect Entra Hybrid sync setup
Many of us use Microsoft Entra Connect Sync in our environments to synchronize on-premise objects to Entra. Not long ago, Microsoft introduced Cloud Sync, which offers some different services. They even have a cool comparison tool to help you decide which one you need. But what if you need services from both connectors?
I got curious; can I use both? Short answer: Yes, go ham.
Letsgo:
The only reason we need both connectors is Entra security group writeback. I really wanted this, because our environments vison is to move as much as possible to Entra and Azure. But we still have legacy onpremise apps that rely on Security Groups (Dont forget hybrid azure storage shares that needs an cloud and onprem object...). Entra Connect can’t writeback security groups; Cloud Sync can. But Cloud Sync can’t write computer objects to Entra, and even if it could, we’d save a lot of time by not having to rebuild the whole [complex] sync process. Plus, this setup lets us gradually migrate sync configurations from the Entra connector to the Cloud connector.
Setup:
First, set things up properly. And test, of course.
Create a new container or location for the group write‑back, and be sure it isn’t included in the Entra Connect Sync rules. If it is, you’ll get sync loops or, at best, duplicate groups. I havent tried it and not planning to do so haha.
If you’ve been using the Entra Sync connector for a long time—like we have—you’re probably still on the old cloud anchor. For group and user membership write‑back to work correctly, you need to upgrade to the modern anchor: ms-DS-ConsistencyGuid .
How to enable the ConsistencyGuid feature - Existing deployment - learn.microsoft.com
Or
Read more about Connect Design Concept's for your situation
After configuring Entra Connect to not interfere, install Cloud Sync Agent next. It can run on a machine that already has the Entra Connect service installed and running. We use a dedicated machine that runs all our connectors and sync services. They should be designed not to cause conflicts.
Now we'll set up our (custom) Cloud sync configuration
(Choose Microsoft Entra ID to AD sync)
This can be different for your environment, but for us we designed:
- All security groups starting with a prefix (ex. grAZ-)
- To the specific OU container
- -= No random id that's default in the CN =- (attribute mapping)
I'm sorry but i didn't create screenshots while setting it up...
For the attribute mapping we changed the CN to not include a custom id, this is not recconmended but we need it for legacy applications to work
If you do change it make sure to thourougly test it
Save, Test & congrats, you now have your Entra security groups available and synced onpremise!
Proost
