Azure AD identity governance — Part 6 — Reach back to on-premises

Alexander Filipin
Apr 4, 2020 · 4 min read

The blog series

Part 1 The basics

Part 2Govern identity lifecycle

Part 3Govern resource lifecycle

Part 4Govern Azure AD B2B

Part 5 Govern access lifecycle

Part 6Reach back to on-premises

Let’s find out how to use Access Reviews and Entitlement Management for on-premises groups.

Current situation

In part five of my blog series I gave an overview of the Azure AD Governance features that can be helpful in implementing an access lifecycle. As great as these Azure AD governance features may be, there is one big problem. Many customers are in a hybrid environment and need these governance features for their on-premises systems. Currently, the Azure AD governance functions only work with cloud resources: cloud groups, applications authenticated via Azure AD and SharePoint sites. With the exception of on-premises applications published via Azure AD application proxy, the Azure AD Governance functions do not cover the on-premises resources. This is primarily because the functions only work with cloud groups and not with synchronized groups of on-premises AD.

In recent years, on-premises has always been the leading system and this is reflected in parts of the current Azure AD design. Objects which are synchronized from on-premises to Azure AD are in a “read only” mode and have to be adjusted on the on-premises side. If we imagine a user’s authorization is revoked due to an authorization re-certification (access review), this information would have to flow from Azure AD to on-premises AD, but the current design does not offer this.

We are already seeing a trend from on-premises mastered to cloud mastered throughout the information technology industry and Azure AD is at the forefront of innovation with features like user provisioning from cloud HR systems to on-premises AD.

However, Azure AD Governance out-of-the-box is not yet “hybrid cloud mastered ready” and we need to think about alternatives until this changes. While we could customize Azure AD Connect Sync Rules and synchronize group memberships of synchronized on-premises groups from Azure AD to AD, the groups cannot be changed in Azure AD due to the “read only” mode.

Solution architecture

On-premises groups for which we want to use Azure AD Governance features will be removed from the synchronization scope of Azure AD Connect and we will use the Microsoft Identity Manager connector for Microsoft Graph to create cloud only shadow groups for our on-premises groups whose membership will be managed in the cloud.

Our on-premises groups are divided into two categories

  • On-premises mastered, synchronized via AADC
  • Cloud mastered, synchronized via MIM

This distinction can be made using organizational units or attributes on the groups.

Thus we get cloud groups which we can use for functions such as Entitlement Management, Group self-services and Access Reviews whose group membership is reflected in an on-premises group.

Joining / matching

In order for Microsoft Identity Manager to perform this synchronization, the groups and users of both sides must be made known there.

For users who continue to be synchronized with Azure AD Connect I recommend using the existing sourceAnchor logic which can also be used in MIM.

For groups the existing sourceAnchor logic cannot be used because they are not synchronized by Azure AD Connect. On Azure AD side these are cloud groups. The Azure AD object ID of the groups could be written into a custom on-premises AD attribute.


This blog article does not show the exact Microsoft Identity Manager configuration, much more it only describes the architecture. To keep the effort on the on-premises side as simple as possible the MIM Sync Engine is sufficient for this approach, the MIM Service and Portal is not needed.

The big advantage is that we can take advantage of the Azure AD’s innovation in the identity governance area while the infrastructure effort on the on-premises side is kept within limits. This includes the user interfaces but also reporting functionalities that are available to us through the Azure AD audit logs in Azure Log Analytics / Azure Sentinel.

With solutions like this, the challenge is to maintain a balance between rapid business benefits [a primary IDaaS goal] and not falling back into complex on-premises projects with long implementation times.


  • I have not yet implemented this approach in a customer scenario and therefore have no experience with the performance of the Graph Connector.
  • If the solution is used for already synchronized on-premises groups, these groups will be deleted in Azure AD and created as cloud groups, all permissions set on Azure AD / cloud services side will be lost and it has to be planned how the group membership of the cloud groups will be initialized (migration)
  • I have no information if or when this functionality will be available out-of-the-box, although I am working for Microsoft but not for the product group.
  • I cannot say to what extent this approach is officially supported.


Identity all the things

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store