The Essential Ingredient to Managing Domain Consolidation Projects with a Remote Workforce
Sponsored IT content provided by Binary Tree
There has always been a challenge to effectively manage domain consolidation efforts within the enterprise. A large pain point that has persisted even down to this day is obtaining the ability to re-permission domain joined devices that are remote to the corporate network. Throughout the years, the way that we could choose to tackle remote machines has evolved — mostly in a positive manner. The net result though is that remote machines still pose a unique challenge and threat for domain consolidation projects.
What is the Actual Problem?
How times change. Just 10-15 years ago, the thought of dealing with a large number of remote workstations that would exist solely outside the corporate network was not something most IT departments had to deal with. For those machines that would stray from the comforts of the corporate office, a secure VPN connection was provided. These VPN connections typically would integrate with the logon screen and allow the user to initiate a secure connection to the corporate office before fully logging into the machine as shown in Figure 1.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
The method to allow remote machines to access the corporate network through a thick VPN client worked quite well for a number of years. While the ability to configure the registry within modern operating systems still exists allowing for a connection to take place during the logon process — another issue has been introduced.
A paradigm shift occurred with the emergence of SSL-based VPN connections that were brought to the market. The SSL VPN connection was quite handy for most system administrators because it meant that one less application had to be installed and managed on user workstations. However, the problem introduced with these connections is that they run within the active user session. This means that the user must log into the workstation first with local cached credentials before launching the SSL VPN client to the corporate network.
With the proliferation of remote-based employees along with broad sweeping BYOD polices adopted by the enterprise, the method by which workstations can be managed and connected into the corporate network has vastly changed.
Now the IT department has the challenge of understanding when remote machines can be contacted, which ones are corporate owned, and which devices have the ability to conditionally connect to enterprise applications.
With all the technology options available today and the rising adoption of SaaS-based applications within the enterprise, many of these remote workstations do not make regular connections into the corporate network anymore.
When the time comes to migrate these workstations over to a new domain, how does the administrator migrate the machine when a connection to the source or target domain is not available?
Another obstacle is understanding how user credentials for the target domain can be cached on the machine before cutover to the new domain since the connection back to the corporate office is likely unavailable. At this point in time, a built-in method to orchestrate this sequence end-to-end does not natively exist.
How Does Microsoft Solve this Problem?
Microsoft recognized the rising number of remote workstations and the general lack of network connectivity many of these machines have back to the corporate office when they released the ability to join a workstation to an Active Directory domain without the requirement to contact a domain controller. The ability to perform an offline domain join (ODJ) allows the administrator the flexibility to join machines when existing connectivity to the target domain does not yet exist for the machine.
How does the ODJ capability help ease the pain of remote workstations that are part of a larger domain consolidation project?
The ODJ process requires the use of the djoin.exe command to target a domain controller and pre-create a computer account in the desired domain. The unique information about this domain join action is then stored in a file that can be accessed by the computer. The file is then applied to the workstation to provide the relevant bits of information that are needed to join the targeted domain without actually contacting a domain controller. After application of this information and a reboot, the computer is happily a member of the targeted domain.
While ODJ functionality works great, there is a fundamental gap in the story. After consuming the provisioning file and a reboot the computer is a member of the targeted domain. That does not mean though that a cached profile and credential for a user in the targeted domain exists on that workstation.
In order to log onto the computer with user credentials from the targeted domain after this process completes, basic connectivity to a domain controller in the target environment must exist to authenticate the logon process and create the user profile. This of course poses a problem if connectivity to the target environment does not exist right after the domain join process completes.
What Other Options Exist?
The gap that exists here is really providing a secure mechanism to cache user credentials that exist in the target domain on the machine as part of the ODJ process. Achieving this would result in an end-to-end ODJ process that would allow a machine to join a targeted domain and log in with cached credentials from that domain, thus removing the dependency of having network connectivity to the domain for real-time authentication.
Enter the SMART Active Directory Migrator platform from Binary Tree. The domain consolidation platform was built with the common heartaches and challenges that come with migrating remote workstations in mind.
The platform provides the required orchestration to help download ODJ files to targeted computers, apply the ODJ file, create a credential cache for all users that have an existing profile on the machine, mark these users for migration, re-permission files and folders, and reboot the computer.
This approach allows the remote computers to be targeted for ODJ or cached credential (Figure 2.) actions, and re-permission jobs to ensure that machines within your network that typically do not connect to the enterprise network on a regular basis can be securely cutover in an end-to-end fashion.
Additionally, this automated process allows the owner of the machine to log in with his or her target credentials to obtain the same user profile they had prior to the migration without skipping a beat. No files lost, no hunting for files in the old user profile, and most importantly – minimal impact to the end-user’s day-to-day operations.
Ensure Successful Domain Consolidation with Binary Tree
Ensuring a successful domain consolidation project that includes remote workstations requires a multi-faceted approach that allows flexibility to conform to the swings of technology. By leveraging the native features of the Microsoft ODJ process, along with the orchestration of the Binary Tree SMART Active Directory Migrator platform the administrator can tackle even the most complex domain consolidation projects head on in a repeatable and successful manner.