Migrating From Local Active Directory to Azure

Migrating from the local Active Directory (AD) to Azure AD is a necessary undertaking for organizations that wish to harness the full benefits of cloud computing. Single sign-ins for many devices and applications, centralized management and storage of credentials, and user reporting can justify such a migration. While our implementation experience presented its share of challenges, it did result in many valuable takeaways for other organizations that wish to do the same. What follows is a synopsis of the challenges we faced during the transition to Azure AD.

Background

Beginning with legacy infrastructure, we had local workstations joined to the local AD and servers deployed in Azure to support the local Active Directory and remote connectivity.

Our goals for the project were as follows:

• Decommission the local Active Directory services for Agile IT.
• Have all workstations and devices join Azure AD directly.
• Have all workstations and devices fully managed by Microsoft 365.
• Capture project steps and delivery actions to ensure packaging for additional customer services.

We did not set out to fully automate the process as this can be done in future deployments with customers. We also did not work on a full communication plan since there was a great deal of information to discuss. Applications won’t disrupt during the transition and post-transition.

Starting Point

The beginning infrastructure consisted of a virtual network already in place that housed our domain controllers running on Azure. We already were set up with Windows Virtual Desktop for access, which was the RDS host. We had a legacy server house files.

End State

While we still have servers in the environment, they are services with Azure AD Domain Services. The file server with the RDS host is the Windows Virtual Desktop. However, since then, we removed the file server because Azure files host the profile paths for Windows Virtual Desktop. We no longer have another network anymore or site-to-site VPN. We eliminated Azure AD Connect.

As a result of these changes, there are less infrastructure components to directly manage. This improves security since there are fewer components to attack. There is less investment necessary in IT in our own services to manage everything accordingly and handle such tasks as backups and restores.

Areas We Addressed

• Awareness of the traditional Windows infrastructure with local Active Directory containing users, groups, and group policies. Windows clients that were in use at the time.
• Servers running on Windows that are most likely authenticating against the local AD.
• One question posed was how are users logging into some of these Line of Business Applications since each application has its own user name and password. They use a domain/user name or just the user name and the domain are automatically assumed. However, there was some concern if this could be changed. In addition, consider Microsoft’s specific servers such as SQL, Exchange, SharePoint, and File Systems/Shares. We had to identify what we would do with them.
• Microsoft Cloud Services. What are we going to do with Azure AD?  We were syncing between our local AD through Azure AD Connect into Azure AD.  If we eliminated this, what happens to all user accounts?

We approached the project in three phases as follows:

Inventory

In this phase, identification of the affected inventory which included servers and their usages, applications, and configuration had to be conducted. We also had to address how we would support the application servers. Additionally, the server that was only used by a few people would be migrated to the SaaS version of the provider later on. However, in the short term, we had to remove it from the local AD and leave it in a Workgroup mode. Though it would not be a member of any AD, it could still be locked down. Instead of group policy, local policy would used, and we would just manage this one server in this manner.

Preparation

Next, consideration was given to the workstations that were a part of the local AD that were going to be removed. The challenge here was not having all the local passwords for the administrator on these accounts. Once they rebooted, they would join Azure AD and would not be able to log in anymore until the profiles were updated. This would require an administrator to physically handle. While there are ways to automate this process, it requires careful planning since it requires Bitlocker keys in case it won’t automatically decrypt.

Execution

We started this phase by powering off all the non-critical servers. Since we had some Line of Business Applications on them, we did not remove them from the domain, rather, we just turned them off. This enabled us to find out who was using them. By leaving them off for about a month and a half, we were able to verify if they were even used at all.

Next, the workstations had to leave Active Directory in order to join Azure AD. Everything else on the server-side was gradually turned off, including the domain controllers. If a problem arouse, they could have been turned back on since making them leave would not serve a purpose at the time.

Execute final sync with Azure AD Connect with password hash. Next we issued commands to the tenant to tell it we were not going to sync anymore. 80- Connect was still thinking it was going to sync and then it would eventually fail. This would cause Azure AD to see the accounts as cloud accounts unless another sync communicated otherwise. While there was some trepidation for this to not go as planned, we could have sent another command to 80-Connect it. We were able to successfully accomplish this several times.

Another issue we had to contend with was getting rid of the side-to-side VPN. We also deleted all the devices since they previously were seen as hybrid-joined. However, now they were going to be Azure AD- joined, which makes them a different device. We went in and cleaned those up and deleted them then powered off the servers.

Important Considerations

A consideration handling the Line of Business Applications is what can be moved and where can we move them to. There is also the question as to how do we want to handle the business applications. While there is a way to take care of all of these, it is a very critical decision that requires many discussions. Many legacy Line of Business Applications and infrastructure replace and file archives to Azure File. Move active files to Microsoft Teams or SharePoint.

Migrating to a SaaS-delivered service is something that many are already doing. All the rules and policies apply once complete.

Lastly, while a Lift and Shift is possible for the applications, the local AD must still be dealt with. A new deployment on Azure VM is preferred and joined to the Azure AD Domain Services. This is because this is a service that looks and behaves like Active Directory for the servers but there are no virtual machines to log into. Microsoft does all the updates and backups. The identities come from Azure AD and it is a much cleaner way to manage. This provides the capabilities needed for the Line of Business Applications which, again, reinforce the reason for removing the local AD.

Results

All local AD accounts convert to cloud-only which took seven hours. It happens faster for others, depending on the tenant. Many of the workstations successfully converted over, though there were some that went into a forever loop on reboot. This was caused by a confusion between Bitlocker and Policy compliance. No data was lost, with the exception of the workstations that were stuck in this forever loop.

There was already some mismatch between the group policy and the Intune policies that were pushing down. However, in our scenario, our site-to-site VPN tunnel was going up and down and workstations were unable to get the latest group policy information, so this could not be fixed. However, this is a problem that most organizations would not face.

We replaced some devices since it was part of a refresh and others we just had to wipe. OneDrive, Team, or SharePoint saved the data. As a result, when they connected to Azure AD, the files were intact.

Learn More About Migrating From Local Active Directory to Azure

When a project involves removing local Active Directory for other customers, the discovery phase is crucial to look at what there is for authentication and local AD. We also need to look at the Line of Business Applications and give guidance accordingly. Plan a “day of decommissioning” for the local AD.

Workshops and planning involving all of the ADs as well as the Line of Business Applications transitions are essential for understanding all aspects of the process.

As an award-winning Microsoft Gold Partner, we offer a full line of innovative cloud-based solutions for your infrastructure’s technology needs.