The primary component (and what people often mean when they say “Azure AD Connect”) is Azure AD Connect Sync. The primary component of MIM is the synchronization service. These two – though they differ somewhat in architecture – are functionally very similar, and most of what can be done in MIM can be done in Azure AD Connect. The biggest difference here is that most of this is not supported in Azure AD Connect, which is designed as a wizard-driven tool to meet the requirements of specific scenarios. That will take a little more explaining – but before we do that let’s exclude some features entirely from our discussion.
Present in MIM but not Azure AD Connect:
- A portal for managing users and groups, running workflows, and providing self-service features (group management, white pages, password reset etc)
- MIM certificate management
- The ability to receive passwords from AD and send them to other systems (using PCNS)
Present in Azure AD Connect but not MIM:
- Authentication services either through federation nor its pass-through authentication agent
- An agent that can provision AD with WorkDay users (though MIM could be made to do this)
- The ability to receive Azure AD password changes and feed them to AD
- The ability to flow AD password hashes to Azure AD
- The Rules Editor application
Comparing the sync services
MIM is designed as a generic tool for synchronizing sources of identity data (users, groups etc.) It is highly flexible, but does almost nothing out of the box. It requires a lot of configuration to make it do anything useful, and generally code as well. It is very powerful – in the right hands!
Azure AD Connect is based on MIM, looks a lot like MIM, behaves under the covers a lot like MIM, but is configured in an entirely different way. Much of it can be configured via a wizard, and most of the rest is configured using a rules editor and rules that are quite different from anything you might see in MIM. No code is required (or even possible). It is powerful and capable right out of the wizard. Beyond that it would be wrong to suggest that configuration is easy, but it does not require programming.
Both are capable of importing/exporting identity data from/to just about any data source – but Azure AD Connect has been designed to connect to all your AD forests, and your (single) Azure AD tenant – and anything else is not supported.
It is thus the case than many organizations have both MIM and Azure AD Connect. A very typical usage is for MIM to import identity data from sources of truth such as HR systems, and export it to AD, while Azure AD Connect synchronizes that data with Azure AD. It should be stressed that MIM can handle many more scenarios than this, involving many on-premises systems (and even cloud systems), synchronizing identity data as necessary.
For a longer discussion about the differences between MIM and Azure AD Connect, see this recording of our very popular webinar: MIM and Azure AD Connect: Two Sides of the Same Coin?
Want to learn more about the differences between MIM and Azure AD Connect? Our Azure AD Connect Masterclass will teach you everything you need to know, or learn topic by topic with our highly practical video training courses.
Need to learn MIM? We offer the world’s best and most comprehensive training courses.
Updated July 2022