What is Microsoft Identity Manager (MIM)? Everything you need to know

With the world increasingly heading towards the Cloud, you may find yourself wondering what use you have for a predominantly on-premises identity management solution – and whether it’s still worth investing in.

In this blog, I’ll provide answers to the most commonly asked questions around Microsoft Identity Manager, including what it is, how it works, how it came to be, and where it’s headed.

What does Microsoft Identity Manager do?

MIM is an identity management solution that enables your organisation to simplify identity lifecycle management with automated workflows, business rules, and easy integration with heterogeneous platforms across the datacentre.

MIM allows an organisation to have the correct users and access rights for Active Directory and on-premises business applications.

By leveraging Azure AD Connect, this information can be made available in Azure Active Directory for Microsoft 365 and cloud-hosted apps to use.

MIM consists of several related components:

• MIM Synchronization Service.
• MIM Service.
• MIM Portal.
• MIM Self Service Password Reset (SSPR) Web Portals.
• MIM Reporting.
• Privileged Access Management.
• MIM Client Add-Ins.

Common MIM scenarios include:

MIM – A brief history

MIM has come a long way from its origins as Zoomit’s VIA, the most widely deployed metadirectory product of the late-90s. Once acquired by Microsoft in 1999 – and a after a whole series of subsequent technology acquisitions, mergers and changes later – the product that would become MIM emerged in 2007 as Identity Lifecycle Manager (ILM).

Three years later, the long-awaited release of ‘ILM 2’ appeared as Forefront Identity Manager (FIM). FIM brought a human element to identity management by adding a web-based portal for configuration, administration, and self-service. Admins could now enable self-service password reset, manage groups, and trigger actions based on the passage of time.

In 2016, FIM became MIM. This change refreshed the product’s supported platforms (latest Windows, SQL, SharePoint, etc.). This meant that hybrid scenarios could now be supported, such as the use of Multi-Factor Authentication (MFA), a Microsoft Graph connector, and integration with Office 365 (now called Microsoft 365).

A new Privileged Access Management (PAM) component was introduced to help secure the corporate Windows environment by granting elevated rights to users on a ‘just in time’ and ‘just enough access’ basis.

Along the way, we have also seen the addition of a MIM reporting component, plus a role management component called bHold (from another acquisition). However, bHold failed to gain much traction and Microsoft does not support any new deployments of it.

MIM’s development has been a gradual evolution, rather than a revolution, and the synchronization engine at MIM’s core has remained largely unchanged throughout – providing a consistent, robust, flexible, and extensible platform for managing identities across heterogeneous platforms and business applications (too numerous to count).

What are the benefits of using MIM?

When dealing with multiple on-premises applications or identity directories, MIM can automate the provision, deprovision, and access management of all users (and groups) across the enterprise.

Using its rules-based synchronisation engine, MIM can ensure that any changes made in source objects are replicated automatically to target platforms.

If transformation of the data is required, then through built-in functions or via the open-ended add-in extension functionality, MIM can be configured to cater for almost any identity management scenario, and in our experience often is!

Deployment of MIM can remove or reduce the reliance on ad-hoc user management scripts, or manual processes currently in use in your organisation.

Coupled with Azure AD Connect sync, MIM provides a powerful solution for onboarding complex on-premises identity environments to Microsoft 365 and other Azure-hosted applications.

How does MIM work?

At the centre of the MIM Synchronization Service is the metaverse. This can be thought of as the single source of truth in the system, where connected authoritative systems can contribute different attributes and different target systems can consume them.

Information is synchronised between the metaverse and connected systems via connector spaces, and rules are configured to determine how that synchronisation is performed.

Rules Extensions can be applied at many different stages during the import, synchronisation, and export processes, allowing complete customisation of the solution.

This flexibility can be something of a double-edged sword.

Some organisations simply seek to replace manual processes. Others try to recreate their existing identity management solution that has become something of a Frankenstein’s monster, with bits added here and there. These additions are often undocumented and applied without effective change management.

Although MIM allows you to do this, all it would achieve is the ability to make a bad process, that nobody fully understands, run faster.

Ideally, the implementation of Microsoft Identity Manager – or a different identity management solution – is an opportunity to step back, analyse, and then simplify things.

If your identity management journey is ultimately heading for the Cloud, then I suggest it’s useful to start that thought process sooner rather than later.

State-based synchronisation

It’s important to understand that MIM is a state-based synchronisation engine. It imports data from connected systems and infers any changes by comparing it with existing data.

These may be changes that have been made in the connected system itself or changes that MIM has exported to a connected system and is now confirming have been successfully applied. MIM may accept changes made in a target system or may back them out depending on the rules you have configured.

MIM stores state information in the form of holograms (binary data structures in the connector space). By comparing holograms from different steps in the process, it can decide whether data needs to be synchronised.

This approach makes for a very robust synchronisation process. In general, connected systems that you wish to manage with MIM do not themselves have to be modified to allow MIM integration to happen.

MIM can connect to APIs, databases, directory services (i.e., LDAP) or even flat files (CSV, fixed-width, attribute-value-pair etc.) – and it’s unlikely that your target application won’t support one of those methods.

The MIM Portal

The MIM Portal provides a human interface into the identity management system. It allows scenarios to be constructed for delegated administration and self-service, as well as the development of workflows and the configuration of other features such as dynamic group management.

The portal can also be used to configure the Synchronization Service by defining declarative rules (rules defined in the Synchronization Service itself are referred to as classic rules). However, not all the extension points of the Synchronization Service have a declarative option, so we tend to stick with classic rules for consistency whenever possible.

All access to the MIM Portal and the assignment of permissions are defined in Management Policy Rules (MPRs), as are the triggers for workflows, be they for notifications, approvals, or actions. MPRs work with sets of requestors and resources, allowing permissions to be granted at an extremely granular level.

Microsoft Identity Manager licensing

MIM requires a server licence for any server running a MIM component. MIM server licenses are included with the Windows Server licence.

Any MIM components other than the Synchronization Service also require client access licenses (CALs). There are several ways of acquiring these, including through your Azure Active Directory licensing.

Navigating Microsoft licensing can be a bit daunting, so speak to your Microsoft account manager for more info or get in touch with us if you need help.

SharePoint licenses are also required for the MIM Portal as the portal is a SharePoint Application.

Microsoft Identity Manager and Azure Active Directory

Whereas MIM enables the organisation to have the right users and access rights for Active Directory and on-premises business applications, it’s Azure AD Connect sync that makes those users available in Azure Active Directory for Microsoft 365 and cloud-hosted apps.

MIM and Azure AD Connect sync share a common heritage that becomes apparent once you get under the hood. Azure AD Connect sync has the same Synchronization Service Management Console and the individual management agents can be seen. Just like in MIM.

Beyond that, they are quite different. The most obvious difference is the way they are configured. Azure AD Connect sync is primarily configured through a wizard, while MIM uses either its classic rules and extensions via Visual Basic / C# or through declarative rules and workflows defined in the MIM Portal.

Azure AD Connect sync also performs password hash synchronisation between on-premises Active Directory and Azure AD, as well as providing the on-premises agent that is used by other services such as cloud HR provisioning.

Azure AD Connect sync has a limitation in that it can only synchronise one on-premises directory per Azure AD instance.

As a result, many organisations use MIM to gather all their identities into one master on-premises Active Directory which is then synchronised to Azure. In this scenario, MIM and Azure AD Connect sync complement each other well.

MIM end of life

A few years ago, rumours of the imminent demise of MIM started to swirl around our “IdM” world – and Microsoft did little to counter them.

Microsoft’s focus was clearly on Cloud solutions and over time some elements of MIM have gradually been replicated in Azure, e.g. self-service password reset, self-service requests to join groups, and the provisioning of identities into downstream SaaS applications.

More recently, the development of cloud HR provisioning apps in Azure has meant that potentially any organisation can provision accounts for users based on their HR data without going through MIM. Provided their HR system is Workday or SuccessFactors (at the time of writing), of course, but you can see where this is heading.

All this is great, and I’m a big fan, but MIM still has a valuable role to play. Many organisations still have a very large on-premises infrastructure with many diverse and often unique requirements and that won’t change any time soon.

This isn’t an “either/or” situation and Microsoft has now recognised that. Although it won’t affect its strategy, Microsoft has acknowledged that MIM will be essential to many organisations for quite some time.

In view of this, it has announced that MIM will continue to be supported until January 2029.

Support, and even new features, can be requested via the Azure Portal. When asked if the support lifetime will be extended further, we get the cryptic reply, “wait and see”.

Conclusion

If there’s one message to take away, it’s this: if you have a requirement that can best be solved by MIM today, then deploy MIM.

You’re probably already covered for MIM licenses – depending on the components you need – either through your Windows or Azure licenses (but please check).

If your requirement can be addressed from the Cloud in the future, then that’s fine – you can look to make the move when that time comes.

Remember that half the battle here is understanding your processes, your requirements, your users, and your data. The technology is probably the easy bit.

Key takeaways

Next steps