As the name of this blog (“MIM and Beyond”) suggests, one of the key themes of this blog is to explore how the enterprise can move to a new IAM approach from on-prem based MIM reliant IAM Architecture. Each successive release from Microsoft, with the introduction of new Entra ID releases, demonstrates a gradual and purposeful shift towards more effectively replacing Microsoft Identity Manager (MIM).
Within enterprise environments, Microsoft Identity Manager (MIM) offers a distinctive capability by virtue of its comprehensive integration prowess. This is exemplified through the utilization of the Extensible Connectivity 2.0 Management Agent Reference, the Windows PowerShell Connector, and the Grendfelt Powershell Management Agent. These mechanisms enable seamless connections with various systems encompassing the enterprise landscape.
Furthermore, the intrinsic capability to tailor data to align with the distinct requirements of enterprises is a key facet of MIM’s value proposition. This customization is facilitated through tools such as MIMWAL and the Management Agent Rules Extension, enabling efficient data transformation processes.
In view of the aforementioned features and capabilities, Microsoft Identity Manager (MIM) emerges as a highly useful utility within the enterprise context.
However, Microsoft Entra ID has come up with capabilities for matching MIM Capabilities as follows.
Identity Capability | Solution using MIM | Solution using Entra ID |
---|---|---|
Integration with well known HR Data Solution | Microsoft Identity Manager PowerShell Management Agent for Workday HR , | HR application to Azure Active Directory user provisioning |
Integration with In House HR Data Solution | File-Based ECMA 2.2 Management Agent | API-driven inbound provisioning |
Provision to SAAS Application | Windows PowerShell Connector | App provisioning in Azure Active Directory |
Provision to On-Premise Application | MIM Connector Reference | Azure AD on-premises application identity provisioning |
Provision to On-Premise Active Directory | How Do I Provision Users to AD DS | Cloud HR app to Active Directory user provisioning |
Custom Transformation in Provisioning | Transforming Data Using Extension Code | Understand how expression builder in Application Provisioning works |
The Azure AD provisioning service just got a major upgrade making us one step closer towards MIM Replacement and even Active Directory Replacement Now, it plays super well with all sorts of HR systems. 🎉 Enterprise IAM Admins can take their pick of automation tools ( Powershell or Logic App ) to integrate employee data from their record systems and smoothly transfer it into Azure AD or On Premises AD.
🌟 Once your workforce data is in Azure AD, you can use Lifecycle Workflows to automate onboarding, offboarding, and other common identity lifecycle Joiner , Mover , Leaver tasks. 📊💼
This method involves turning off directory sync, converting users to Cloud Only Users, and uninstalling Azure AD Connect. A key part of this approach is connecting HR data with Entra ID seamlessly.
# Connect to the Microsoft Graph API with Organization.ReadWrite.All permission scope
Connect-MgGraph -scopes Organization.ReadWrite.All
# Check if the Microsoft.Graph.Beta.Identity.DirectoryManagement module is installed, and install it if necessary
$module = Get-Module "Microsoft.Graph.Beta.Identity.DirectoryManagement" -ListAvailable
if($null -eq $module)
{
Install-Module Microsoft.Graph.Beta.Identity.DirectoryManagement -scope currentuser -force
}
# Get the ID of the current organization
$OrgID = (Get-MgOrganization).id
# Define parameters to update the organization's on-premises sync settings
$params = @{
onPremisesSyncEnabled = $null
}
# Update the organization's on-premises sync settings using the Microsoft.Graph.Beta.Identity.DirectoryManagement module
Update-MgBetaOrganization -OrganizationId $OrgID -BodyParameter $params
You can verify the value of the OnPremesisSyncEnabled property, you can use the Select statement as follows:
Get-MgOrganization | Select OnPremisesSyncEnabled
However, this approach makes me nervous for the following reason.
The success of the Big Bang Approach depends on how well HR data and Entra ID integrate. Keep in mind that this integration is still in the early stages, so be cautious when rolling it out across your organization. Make sure the integration is solid before taking this big step. Building a complex integration process that matches all the requirements of an enterprise takes considerable skills and iterative development phases.
Once you disable sync for the whole organization, reversing users back to on-prem managed hybrid users gets tricky. So, think things through before jumping into this major change.
A phased approach to convert hybrid users into cloud users can offer a prudent and controlled transition.
Assessment and Planning 📊
We select a small batch of users for gradual migration. Develop a clear plan outlining the migration timeline, potential challenges, and mitigation strategies.
Pilot Phase 🛫
Set-ADSyncScheduler -SyncCycleEnabled $false
# Connect to Active Directory
Import-Module ActiveDirectory
# Get the distinguished names (DNs) of the users to move
$user1DN = (Get-ADUser -Identity User1).DistinguishedName
$user2DN = (Get-ADUser -Identity User2).DistinguishedName
# Move the users to the new OU
Move-ADObject -Identity $user1DN -TargetPath "OU=NonCloudSynced,DC=example,DC=com"
Move-ADObject -Identity $user2DN -TargetPath "OU=NonCloudSynced,DC=example,DC=com"
Resume synchronization and force a delta sync. This will synchronize the cloud-based identities with the on-premises identities, but only for the users that have been moved to the new OU.
Set-ADSyncScheduler -SyncCycleEnabled $true
Start-ADSyncSyncCycle -PolicyType Delta
Restore users from the recycle bin in Azure AD. These users are now orphaned, so they need to be restored before they can be used. Fix any attributes and data for the ‘new’ users. Sometimes it’s necessary to tweak the immutableId, but this isn’t strictly required.
$OldUPN = "firstname.lastname@example.com"
$cloudTenant = "onprem.onmicrosoft.com"
$UserName = ($OldUPN -split '@')[0]
$oldSuffix = ($OldUPN -split '@')[1]
$tempUPN = "${UserName}@${cloudTenant}"
$NewUPN = $OldUPN
$filterUrl = "https://graph.microsoft.com/v1.0/directory/deletedItems/microsoft.graph.user?\$filter=endsWith(userPrincipalName,'$OldUPN')&\$count=true"
$deletedObj = Invoke-MgGraphRequest -Uri $filterUrl -Method Get -ErrorAction Stop -Headers @{ConsistencyLevel = 'eventual' }
if ($deletedObj.'@odata.count' -eq 0) {
# Output error or do nothing
Write-Error "User $OldUPN not found in deleted items"
}
else {
$userId = $deletedObj.Value[0].id
Write-Output $userId
Restore-MgDirectoryDeletedItem -DirectoryObjectId $userId | Out-Null
Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/users/$userId" -Method PATCH -Body @{ OnPremisesImmutableId = $null } -Debug
Start-Sleep -Seconds 5
$userObj = Get-MgUser -UserId $NewUPN -Property OnPremisesImmutableId
if ($null -eq $userObj.OnPremisesImmutableId) {
"All good!"
}
}
The original AD identities cannot be moved back to their initial structure, as they would be matched again with the cloud-based identities. Ideally, the on-premises AD account would be disabled or permanently deleted after a grace period. It is sometimes necessary to tweak the immutableId, but this is not strictly required.
In this article, we explored the future of identity provisioning and how Entra ID is poised to replace Active Directory as the central hub for identity management. We discussed the benefits of moving to Entra ID, including its support for modern authentication methods, its cloud-native agility, and its simplified lifecycle management. We also outlined the steps involved in migrating from Active Directory to Entra ID, including a phased approach that can help organizations transition in a controlled and thoughtful manner.