Exploring the Use Cases of ADMS Application Pipeline

A Comprehensive Overview:

An Insight into Active Directory Migration Services Application Pipeline.

Introduction

ADMS, ADSS, and ADGMS are all cloud-based services that come within the ADxS services portfolio offered by Microsoft and designed to facilitate efficient and cost-effective migrations. For additional information around migration use cases, refer to this blog: https://techcommunity.microsoft.com/blog/microsoft-security-blog/exploring-the-use-cases-of-adxs-services/4373299?previewMessage=true . In this blog, we will examine the various use cases of ADMS application pipeline, highlighting its key features and advantages.

ADMS or Active Directory Migration Service – is a service designed to facilitate the migration of users and workstations across domains and forests by offering diverse number of migration methods such as Self-Service Migration which is unique to the ADMS service and it comes with two types, Self-Service for corporate connect users, and Self-Service for Remote of VPN users,  Admin automated Migrations, user only migration and Migration for workstations shared by more than one user.

ADMS Queuing Framework

The ADMS user migration is accomplished by several backend processes in addition to the ADMS Portal, which provides a self-service user interface, does pre-validation checking and ensures that the user is approved to migrate. The ADMS solution is scalable to support many concurrent user migrations submitted using the Self-service Portal and by the bulk account submission tool. An ADMS user migration spans across several processes in a workflow. These migration processes are tracked by several persisted work items across several queues. There are four primary types of queues in the ADMS solution for queuing up and serving work items. These work items are processed on a first-in-first-out (FIFO) basis where interactive migrations using the Self-service/Surrogate Portal have a higher priority than ones submitted in bulk with the Auto Migration app or the Bulk Account Submission tool.

Each ADMS work item carries information to enable migration and application remediation features in our solution. This blog will focus on the application remediation (AR) work items.

Each user account migrated through the ADMS Migration Portal will be submitted to the app remediation pipeline. When a task appears in the queue destined for that agent, the agent retrieves the task and performs the actions that the agent is configured to perform. This is done per user at migration run-time.

ADMS approach for Application and/or Service Remediation during migration.

The objective of this blog is to ensure you have a clear understanding of how ADMS delivery approaches application and/or service remediation during migrations. At a high level, we know that there are applications and services that will have some issue when a user migrates from one domain to another. We suggest identifying each application and service and then figuring out whether they will need to be remediated by performing configuration change, a code update, database update, or via an ADMS application remediation (AR) agent.

The ADMS delivery team provides a sample application/service catalog where we suggest documenting application and service remediation details along your migration journey and continuing to do so as migrations complete. Migration teams utilize this sample that becomes a living document along the migration journey and a hands off to operational teams post migrations leads to long-term success.

Application and service remediation philosophy during ADMS migrations are about coexistence. The user identities that migrate from source to target domain must maintain access across their migration journey and coexistence is key during the migration process focusing on lifting and shifting applications and services downstream allows more runway for operational teams. Coexistence allows primary focus to be on user and device identity management during migrations while allowing a foundation that will support pivoting to rationalizing and upgrading application and service operations downstream from migrations.

The ADMS sync engine enables downstream ADMS features to consume identities based on logic provided by our customers early on in our process allowing a mapping for coexistence. Once ADMS sync engine is enabled and running, ADMS delivery team performs our smoke testing, where we validate if our solution meets our agreed upon blueprint for your solution. Once testing is completed, we hand over our solution to the customer migration teams to perform their own UAT.

The key to customer migration success around applications and services remediations is getting started early testing with early adopters. We suggest our customers use identities that mirror their migration use cases prior to getting into production identities to validate remediation tasks during the migration journey. The next phase would be to ramp up into a larger pilot, where most customers use technology friendly business units to perform deeper dive remediation testing use cases.

ADMS migration is non-destructive to the source user identity. We are not touching or altering any accounts in the source so customers can start with a pilot knowing that we have not done anything to unravel the source account, maintaining coexistence. Customers can migrate a test account forward and confidently know that the source account remains intact while you are testing with the migrated target domain identity.

ADxS in Action: Practical Approaches to Application Remediation

The ADMS delivery team suggest classifying applications and services into categories or “buckets” to help identify remediation types and timings during your migration journey. Let’s discuss those in more detail from a typical ADMS delivery:

• ADMS Runtime: This category would be where ADMS can help the most during migrations. There are per instance fees for each ADMS AR instance so typically limited to a few configuration items. As an example, a proprietary database update is needed at the time a user is migrating, ADMS updates the reference to the source and changes it to the target identity for that migration user or bulk or migration users. An example would be calling an existing stored procedure to update a custom application/service in the customer environment.
• Static Change: This category would be where customer migration teams need to make a one-time application or service change. These types of changes usually need a change control, scheduled change per application/service. An example of this use case would be an LDAP application only putting to the source domain/realm and needs an update to include the target domain/realm.
• Dual ID: As mentioned, we do not do anything destructive to the source account so you can pivot back to that identity and retain the existing access obtained while in the source domain.
• Out-of-Band: The last category would be applications and/or services that can be decoupled from user migration. Once we have user identities synced, we can work with customer migration teams to provide an identity mapping file that can assist in security translations to remediate the out-of-band processes where appropriate.

The key objective from our perspective to building out an application/service catalog as it relates to coexisting during migration is putting these “buckets” in place. They help migration teams sort the entire application/service portfolio so as everyone goes through their test use cases and someone says “hey, this app/service doesn’t work”, your team can ask, “ok, WHY doesn’t it work?” and it typically falls into one of those categories or “buckets” listed above. They help migration teams to define what needs to be done to correct the issue and allow coexistence during your migration journey.

The Ultimate ADxS Guide: Application Remediation for Modern Migrations

The ADMS delivery team has seen these common types of application and service dependencies most frequently during ADMS migrations. Let’s discuss those in more detail from a typical ADMS delivery:

• AD Security Group Membership: As part of the ADMS sync engine, we have the ability to sync source groups to the target environment based on an agreed upon mapping of group objects. ADMS has a feature we can enable that will bring over SIDHistory for in scope groups that are part of the ADMS sync process. This resolves many of the AD-dependent application/service access scenarios where SIDHistory is honored by that application/service.
• AD Attributes: Exchange is an example of where we can pick up attributes in the source and flow them to the target. Some applications/services require an attribute for authorization and in those cases, you’ll want to identify requirements and include them in the ADMS sync engine configuration.
• Proprietary Database: Some applications/services have a proprietary database that needs to update when the user migrates to the target. SharePoint is a good example of this use case, where we must reach out to the database, and update that reference from the source identity to the target identity at user migration run-time.
• LDAP Application - Best case scenario, the LDAP application is capable of binding to multiple realms, meaning it can connect to multiple Active Directory domains that are in scope for user and device migrations. Customer teams can remediate the application by configuring the application to bind to the target domain, which is the landing zone for migration. If however, you have an application that is only single-realm bind capable there are a couple options: -- Migrate all users in scope for this single-realm bind use case in a single migration batch then change the application to point to the target domain post user migration. -- Another possibility is changing authentication to use local accounts during the migration, then point the application back to target domain authentication post user migration. -- A third option is to check with the application owner to determine if an update is available to the application to allow multi-realm bind use case. -- The last resort option would be to leave the source account enabled to allow existing access while your team works on a long-term solution.
• Cloud Identity - There are some applications and services that rely on a cloud Identity to allow access. Your source of authority that determines source vs target Identity will come into play for this use case. Customer may need to review and update their sync to cloud configuration to allow coexistence for this use case as the user and device migrates to the target domain.

How can ADMS help?

The ADMS delivery team can handle at run-time remediation in the ADMS AR pipeline. This is done per user at user migration run-time to allow coexistence, maintaining access for those pending migration, and updating access for those that have performed migration throught the ADMS Portal.

Customer teams will need to identify any changes that need to be made within the organization to allow coexistence per application/service. A critical role during ADMS migration is the customer UAT role. During workshops, we enable this role to assist in building out the customer application/service catalog as well as the migration test plans. Migration success relies on this role in regards to customer application/service remediation. As migrations end, customers can use this catalog as a living document that is a key factor in long-term operational success.

With this guide in hand, customers know what it takes to allow and disallow access to every application/service in the organization so their provisioning and deprovisioning process is better than it ever has been based on the efforts put in during their ADMS migrations.

Conclusion

ADMS AR pipeline offers endless extensibility options during user migrations by allowing customers to execute remediation at time of user migration. This feature has been priceless in recent migrations to allow customers to execute downstream workflow assisting their migration journey goals end to end.

Learn more about IMS and explore its powerful migration capabilities today!

• Read our latest insights on the IMS blog 
• Learn more about IMS and start hassle-free migrations and its capabilities today! On our YouTube Channel 
• Want to speak with an expert? Reach out to us at imssales@microsoft.com to connect with a sales representative. Let’s power the future of digital collaboration — together.