Azure AD identity governance — Part 6 — Reach back to on-premises
The blog series
Part 1 — The basics
Part 2 — Govern identity lifecycle
Part 3 — Govern resource lifecycle
Part 4 — Govern Azure AD B2B
Part 5 — Govern access lifecycle
Part 6 — Reach back to on-premises
Let’s find out how to use Access Reviews and Entitlement Management for on-premises groups.
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.
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.