Transforming your organization to cloud-only: Migrating Active Directory identities to cloud identities

Transforming your organization to cloud-only: Migrating Active Directory identities to cloud identities

About a year ago, I wrote about transforming your organization by retiring the on-premises Active Directory. This post is a bit of a sequel to that, as I left you with the thought of migrating your Active Directory identities to Azure Active Directory-sourced identities. The idea is to gradually move your locally managed identities to the cloud so that one day we can demote the on-premises Active Directory as it will no longer be needed.

The problem

Every great story starts with a problem statement. This time, our antagonist in this riveting story is Azure AD Connect. That’s the software you perhaps deployed back in the day to flow your on-premises identities and groups to Azure AD. Thus, creating synchronized identities.

These identities are managed within the local AD. Changes flow to Azure AD, and users can log on to their services using their cloud identity as if by magic. I’ll leave the federation out of this design, as I feel it’s already on the way out anyway.

Identities that are synced are marked within Azure AD as on-premises managed. There are attributes (within the synced objects) and references populated so that the cloud knows to keep you from breaking things when you edit these users later.

Let’s envision a scenario where a company – which we shall call Fabrikam because I like the name – has an on-premises AD with 15,000 users. These 15,000 users are synchronized to a single Azure AD tenant, and we have the equivalent of 15,000 users in the cloud.

Fabrikam uses a third-party HR system to manage changes to user objects in the on-premises AD – such as when the Manager or Phone number fields need updating. The HR system integrates with AD to update changes on a nightly basis. Then Azure AD Connect syncs these changes to Azure AD, where they are visible and are leveraged in Microsoft 365, for example.

This is a typical situation, and it works well. Until you conclude that the on-premises AD, with its 15,000 users, and the third-party HR are cumbersome and expensive to manage and monitor. Why not migrate fully to the cloud, and ditch the on-premises HR for good? But with 15,000 users, nobody wants to do an over-the-weekend death march migration project. Instead, we gradually migrate identities to Azure AD, and eventually, AD is no longer managing any users.

The problem of the problem

Microsoft hasn’t provided an easy and clean way to flip synchronized on-premises AD identities to non-synchronized Azure AD identities. The usual wisdom I see thrown around is to “just stop syncing.” The intention, I think, is good – when you stop syncing, the identities in Azure AD become non-synchronized and can be claimed as cloud identities.

Fabrikam, our imaginary dream company, cannot just stop syncing. Things take time. Re-building integrations are complex projects, and an overnight flip to “just use Azure AD” is a pipe dream.

The problem of the problem, therefore, is that Azure AD, at least today, lacks a big button that says, “Hey, I have these 15,000 identities already; let’s claim a portion of these and stop overwriting them via the sync from AD, okay, thanks.“

The solution

I’ve spent some time finding a solution for companies like Fabrikam. Ideally, you’d have a way to manage identities from two sources of authority: you could perhaps edit some bits of data in AD and other bits in Azure AD, and magically these would be multi-master synced. Sadly, this solution would require a real identity management solution, which Azure AD cannot provide today. This capability isn’t built-in into Azure AD, at least not today.

Weaning off local AD by dropping a designated number of identities from the sync and fixing those identities in the cloud is then what we have to do. It’s not a new solution, by far, but it’s something that is – what I call – semi-supported. It works, and it’s the way to do it, but I’ve yet to find a good support article outlining this on a .microsoft.com property.

The necessary steps are for transforming an identity to cloud-managed are:

  • Stopping identity synchronization briefly – not permanently
  • Moving the designated users outside the scope of Azure AD Connect – perhaps by creating a new, separate OU in AD and moving those users there
  • Resuming synchronization and forcing a delta sync
  • Restoring users from the recycle bin in Azure AD, as these identities are now orphaned
  • Fixing any attributes and data for these ‘new’ users
  • Pointing the HR system to update these identities in the cloud instead of via AD

The identities are now, as best Azure AD can tell, cloud-based. You cannot move the original AD identities back to their initial structure, as they’d be matched again with the cloud-based identities. Ideally, the on-premises AD account would be disabled or permanently deleted after a grace period. Sometimes it’s necessary to tweak the immutableId, but this isn’t strictly required.

This solution works, but it’s an arduous process. In addition, this is intended for organizations like Fabrikam that require months or years to switch over to Azure AD-based identities.

What this solution will not provide, however, is the ability to manage attributes for a single identity in the two realms, AD and Azure AD, at the same time. It’s one or the other. Thus, the initial need for a third-party HR system now needs to maintain both the on-premises AD (for the synchronized identities) and Azure AD (for the migrated cloud-only identities) while the overlap exists.

In closing

I’ve left out complex commands and syntax on purpose; each project and environment is so different that you have other models and approaches. The general gist is still the same, though.

I’m glad that there is a way. Yet I’m bummed at the same time that leaving AD behind is still so cumbersome.