This article has contributions from Becky Cross
Introduction
In the very early Windows NT Days, we had computer accounts connected to domain controllers. This provided the early building blocks of securing data and computers in company networks. Since then, our entire digital landscape has transformed. With modern networking and cloud adoption across so much of our world, it makes sense for our computer accounts to make the move from on-prem Active Directory (AD) to Azure Active Directory (AAD).
Terminology
We will use three main terms throughout the article. Let’s review these terms to familiarize ourselves with each type of computer account.
On-prem Active Directory joined computer accounts – These are traditional computer accounts that are joined to a domain and are serviced by on-prem Active Directory servers.
Hybrid Azure AD joined devices – Sometimes called “mini-joined computer accounts”, these are computers that are on-prem Active Directory joined accounts that are also joined to Azure AD via Azure AD Connect or ADFS configuration. The mini join allows administrators to perform some functions with Microsoft Intune. Users can also benefit from Intune management by enrolling an existing device to Azure AD, which occurs when you install Office 365 and during login select “Allow my organization to manage my device.” However, most device management exercises like configuration policies and software deployment continue with on-prem-based solutions (or third-party solutions).
Azure AD joined devices – These are devices that are joined to Azure Active Directory only. Microsoft Intune will take over the functions of Group Policy. You will need to rely on Intune for software deployment or use another third-party solution. Applications will need to rely on Azure AD for authentication unless special services and configurations are made.
Microsoft Platform Migration Planning and Consolidation
Simplify migration planning , overcome migration challenges, and finish projects faster while minimizing the costs, risks and disruptions to users.
The Challenge
In reading those definitions, there are some major “gotchas” hidden in there. If they apply to you, there can be significant steps to get ready for this type of migration. The two big items are Legacy Application Authentication and converting Group Policy Object management to Intune Configuration Policies. Let us review these top issues and other considerations for migrating computer accounts to Azure Active Directory.
Legacy Applications
Applications running on domain-joined devices have leveraged domain services for their authentication method. This reliance has provided a single sign-on (SSO) experience for quite some time. These methods have leveraged Kerberos, NTLM authentication, and Lightweight Directory Access Protocol (LDAP) integration.
To shift to Azure AD joined devices, all applications will need to support Azure AD Authentification. If they do not support Azure AD Authentication, and you want to get rid of your on-prem domain controllers, you will need to deploy Azure Active Directory Domain Services and connect your application servers to them. While this service can be a tremendous help, it does require some setup and know-how. The overview of Azure Active Directory Domain Services is here: Overview of Azure Active Directory Domain Services
Group Policy Objects (GPO) / Configuration Management
Figuring out what do to with Device Configuration is one of the most time-consuming aspects of migrating to Azure AD joined devices. GPO management is very complex, often with multiple policies that are scoped to different users and layered on top of each other. Figuring out what the actual end settings are for each setting and user is quite tricky. When your inventory work is done, taking these policies and turning them into a configuration policy can be a lot of work.
The good news is that Microsoft has a tool in Preview to help with this. The Microsoft Policy Analyzer Tool instructions can be found here. The tool is located in the Microsoft Endpoint Manager Admin Center. Exported copies of your GPOs are imported with reports informing you about any issues. You can turn these into configuration policies and apply them to devices. This is a great tool for organizations with a few policies. However, large firms are often known for having multiple policies assigned to users. This policy layering can create conflicts with the most recently applied policy “winning” and taking effect. For firms that have layered their GPOs, this tool will only help you policy-by-policy. The tooling can still be very valuable; however, you will need to untangle this layering.
When organizations move to Azure AD joined devices, there may be the temptation to “migrate” these policies by trying to recreate them in Intune. If you find yourself in this situation, you may want to consider creating new policies from scratch or altering your primary policy. This is particularly true for organizations with layered policies.
Data and Applications
When it comes to your data and applications, many will try to declare that “everything” must be in the cloud to be successful. Whilst this can simplify your adoption of Azure AD, this is not a requirement. If you have some applications holding out or some data repositories, you can allow users to connect back into these services as long as authentication is addressed. Another option is to leave the small subset of users that need on-prem data and applications in their current state until they can be remediated.
Software Distribution
Another aspect of migrating computer accounts to Azure Active Directory is software distribution. If you are deploying software to devices using on-prem tools like Microsoft Configuration Manager, you will likely need to shift to a cloud-based alternative like Intune or a third-party option. When you move to Azure AD joined devices, you typically want to avoid users connecting to a VPN or another on-prem system to get software distribution jobs.
If you shift this to Microsoft Intune, Microsoft gives you a few options to create software jobs. Microsoft announced in 2021 that they were ending support for the Microsoft Store for Business and Education. The good news is a few weeks ago the replacement strategy was revealed. Among other exciting announcements, we found that the integration will shift to the consumer Microsoft Store. This will retain the same functionality of assigning Windows Store apps to devices. For software that is not listed in the Windows Store, you can convert .msi packages into .intune packages using the Microsoft Win32 Content Prep Tool.
Alternatively, you can leverage third-party solutions like KACE by Quest. These third-party options can be desirable to long-running projects with multiple platforms in one place.
Conclusion
The current process for moving computer accounts is highly manual with options and steps varying wildly based on your configuration. At a high level, the steps include dropping the computer to a workgroup, connecting the device to Azure AD with the primary user account, and copying files and profiles to the account. Third-party options are working on solutions to address this challenge. Becky Cross will be sharing some very exciting news in this space in our session, so stay tuned!
Microsoft Platform Migration Planning and Consolidation
Simplify migration planning , overcome migration challenges, and finish projects faster while minimizing the costs, risks and disruptions to users.
Should we always delete the cloud devices before running the sync to avoid conditional access issues?
hello, migrating the user profile in the manual migration we always use forensit. this can really help the end users.
Migrating domain joined devices to azure can be a real chore. If there is a 3rd party thing to help automate this process then that would be a amazing.
The Real Person!
Author Becky Cross acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Good news – Quest On Demand Migration for Active Directory (ODMAD) now migrates devices from AD or Hybrid Azure AD to Azure-only while retaining and re-permissioning the existing user profiles, data, and applications. This method eliminates the previously required task of rebuilding/copying profiles and data, which can be tedious and time-consuming, even with a tool like Forensit’s ProfWiz. If you have devices that you need to migrate to Azure AD, you can request a quote at quest.com
Hi Becky…just came across this blog. The ODMAD…is this a “run independently” tool or part of a wider enterprise solution? For example, looking for a tool (like ForensIT) which can migrate an AD joined device to an Azure (Entra) Join. The key is that essentially the device is a member of a “local AD” domain (in a different company), and the requirement is to add or migrate this direct to an Azure only Domain (in another company). We will need the usual user re-profile/Re-ACL (avoiding any rebuild/Autopilot etc.), plus retain the local apps/data etc. We tried the ForensIT tool which has been OK for conventional AD to AD migrations, but it is very “hit and miss” for AD to Azure…too risky for Production migrations. What does Quest and the ODMAD tool offer?