The Active Directory (AD) Migration is one of the most foundational elements of change in a corporate network. Active Directory is really an identity and access management system with impacts to IT Security, Audit and Compliance, and operational efficiency and effectiveness. Ninety-four percent of the world’s corporate networks use Active Directory in an ever-evolving way. Giving Active Directory its due respect is never a bad idea.
Active Directory migrations are almost always justified by a merger/acquisition/divestiture, an IT Security event, and/or a cost-savings initiative. Therefore, the outcome of an AD migration effort should be an enabling of a new business entity, a more secure AD, and/or reduced complexity and cost. Those outcomes are easy to lose sight of when taking on a large AD migration effort. This article will focus on two decisions within an AD migration that often are later regretted.
Objective 1: Include servers in your AD Migration
The first decision to make is to include server migration scope in the AD migration project so that you can untrust, shut down the Source environment, and remove sIDHistory in the Target environment – even if that means your AD migration project plan spans more than one budget year.
Leaving servers behind has repercussions
Perhaps because some older AD migration solutions did not include the capabilities to migrate servers, customers were trained to focus only on the users, groups, and workstations in an AD migration. In the case of a cost-saving justification, perhaps the Microsoft ELA terms also caused customers to ignore servers as those were not part of an O365 cost-savings consolidation into a single tenant.
In any case, many corporations have later regretted what’s accurately known as “AD Sprawl” or the leaving behind of one or many resource forests from Active Directories that long ago migrated their users, groups, and workstations from them. In many cases, there are still Directory Synchronization engines that perpetually keep the Source and Target AD environments in sync. And in egregious scenarios, new hires and terminations are still being managed in both Source and Target AD environments.
This sprawling AD problem delivers neither cost savings due to less complexity and overhead nor improved IT Security with a multiplier of privileged admin accounts and Tier Zero assets that are typically AD-trusted with the “production” AD environment where the users/workstations have lived for a long time.
Obtaining subsequent migration funding can be challenging
Typically, when an AD migration is planned and executed with a specific schedule and budget, having that plan fall short of delivering improved IT Security and/or reduced complexity/cost is difficult to remediate in the following years. An AD migration is a special project with its own special budget. It is not always easy to justify continued AD migration spending in the following operational budget years to remediate AD sprawl.
Too many times a corporation will again start another merger and acquisition event while still in the period of “we’ll get to the left-behind servers later”. The lesson learned is “we’ll get to it later” seems to fail more than succeed enough that it deserves its own white paper to describe. And in some cases where “get to it later” actually does happen – it was because there was an IT Security event or significant outage scenario that highlights the risk of hanging a server resource AD forest off the production domain.
Additionally, unless the original AD migration infrastructure has been maintained all the while, setting up a second AD migration for servers is re-work. As is all the application coexistence testing that likely already happened during the original AD migration of workstations.
Objective 2: Disable source user accounts as part of the AD migration
The second decision to make is to disable the source user accounts upon a user’s AD migration. You should do this in the phase of the AD migration when you ask the migrated users to use their Target AD accounts to login to their workstations that exist as part of the Target AD.
Keeping source accounts enabled can impact server migration planning
If you’ve been trained to not consider servers in the scope of an AD migration, then you must figure out how to use the target User account to reach back into the Source environment for non-migrated servers. However, you might just be leaving source accounts enabled, meaning that a user can always continue use of their source account in the Source AD environment where the servers continue to live.
If you leave source accounts enabled, then you just keep waiting until that perpetual next-year-project to move the old servers into the Target environment where the users live. These delays can cause technical debt, an IT Security risk, and an operational hazard that’s hard to see when planning an AD migration effort. Disabling a user’s source AD account upon a user’s migration is a good mitigation strategy.
Disabling source accounts can identify server dependencies
By disabling a user’s source account, you will force the users to use their future-state accounts to authenticate with any remaining Source servers and you can identify the dependencies on the Source accounts. In the pilot phase of the project, the pilot users should be strategically selected to test against as much of the Source environment as necessary using their Target accounts.
It is likely you’ll find less than four percent of your servers cannot authenticate with Target user accounts. Remediation in the vast majority of those instances can be done by repermissioning the servers with Target AD accounts (dual ACL’ing), adjusting group types and membership (Domain Universal to Domain Local groups with Target accounts in it), and/or making use of the sIDHistory AD attribute.
To a migration team (and anxious AD migration sponsor), this decision means more work up-front. But the return on investment is the migration of servers has all the AD dependencies removed from the server migration scope.
Finding servers you can migrate in advance
Consider that the transitive nature of AD dependencies goes both ways. If a migrated user/workstation can reach back across the domain threshold with their Target AD account to authenticate with a server still in the Source AD, then the same will hold true in reverse, provided you have a two-way AD trust in place.
That means once you prove the AD authentication works with the migrated pilot user, the server can be moved in advance of all the other users that still exist in the Source AD. Users/workstations are typically migrated at velocity at 250+ per day, but servers take more time in small batches or one at a time. Getting a jump start on migrating server scope is usually a good idea.
Note, if you only have a one-way trust, then the servers must be migrated after the users are all migrated; however, disabling the source accounts still ensures you flushed out all the AD dependency problems when it’s time to migrate servers.
Application servers may require additional remediation
Once all the Source user accounts are disabled and users can successfully access the server and application with their Target user accounts, then the only remaining risks you have in migrating servers are environmental or internal to the application.
Common challenges for migrating application servers include DNS aliases, GPOs, dedicated service accounts, other servers that have dependencies, and application-level code. If you migrate a server and an application stops working, the easiest way to remediate is to simply migrate the server back to the Source environment.
The application will start functioning again, giving you time to investigate the issue and create a remediation plan for a successful re-migration in the future. If you made other changes to the application in conjunction with the server migration, remember to also undo those changes when migrating back to the Source.
The server migration is the reliable and repeatable part of the migration. The application’s dependencies are the risky part.
Make the right decisions for your AD migration
The bottom line is that to realize increased IT Security and reduce costs, your end goal is to shut down the Source AD environment by disabling user accounts and migrating servers. Failing to disable the Source accounts during the users/workstation migration means there will be redundant risk and work later when it’s time to migrate servers. Disabling the Source accounts and migrating the servers “later” is a plan that more often than not fails to deliver increased IT Security or reduced overhead/costs.