Migratin to new AD while retaining activation

We have a sitatuaiton where a company will migrate their Duo Protected AD into a new forest.
The user ID will be retain but the old AD (which is synched with Duo) will be retired.
What is th best strategy to follow is such cases ? In particular we would like to avoid having to recongifure all end user devices…

Welcome back to the Duo Community, @AlexT ! Here are some steps that may help you with upgrading your AD FS servers.

To upgrade Duo on an AD FS 3 or 4 server, it is necessary to disable the Duo Authentication for AD FS authentication method in the AD FS Management console first.

  1. Launch the AD FS Management console on your AD FS internal server.
  2. Navigate to AD FS > Authentication Policies and click the Edit Global Multi-factor Authentication… action.
  3. Uncheck the box next to the Duo Authentication for AD FS X.X.X.X authentication method to disable Duo protection. Note that in older releases of Duo for AD FS, the authentication method is called Duo Security for AD FS 3.0.
  4. Update your ADFS servers.
  5. Download the most recent Duo AD FS Installer Package for AD FS 3 and 4 and run the MSI from an elevated command prompt.
  6. Follow the on-screen prompts to complete the upgrade installation.
  7. When the installer is finished, repeat the steps you originally followed to enable the Duo method in AD FS. Users may log on to federated services without two-factor protection until you’ve re-enabled the Duo authentication method.
  8. If you have deployed AD FS as farm, you’ll need to upgrade Duo on each of your servers. For a WID farm, install Duo on the primary server first. If you have a SQL farm, you may begin with any node.

Whilst the plugin is disabled users will be bypassing 2FA. No additional work will be required for users’ enrollments, activations, or their Duo mobile devices. This will be unaffected and will work again when you re-enable the updated plugin on your updated servers.

@AlexT is this your scenario?

  1. You’re syncing users from an existing AD forest (let’s call it foo.com with the base DN dc=foo,dc=com) into Duo.
  2. You will be migrating all your users into a new AD forest (oof.com with base DN dc=oof,dc=com).

In general, a sync migration plan consists of these steps:

  1. Delete the current foo.com AD sync configuration. The users previously synced from foo.com to Duo become manually-managed Duo users, with their existing devices. Note that it is important here to just delete the entire sync to convert the synced users to regular unmanaged users; if you delete groups from the sync instead of deleting the entire sync then it will mark your users for deletion.

  2. Create a new oof.com AD sync configuration, using the same attributes as the old foo.com sync and specifying groups to sync from OOF that have the same user members as the FOO groups you previously synced. When the new oof.com sync runs, it will take over management of the existing users.

Whether existing users already synced into Duo can be preserved with their devices depends on what attributes you’re currently syncing. What AD attributes are you using for the imported username? If the synced username attribute values in the new oof forest will exactly match the current values in the foo forest, then it’s possible to retain the existing users with their current usernames post-migration and have them managed by a sync with the new forest.


  • You are using the sAMAccountName as the username attribute (example jdoe), and the existing sAMAccountName values from foo.com will be used in oof.com = a new sync to oof.com can take over existing users.

  • You are using the msDS-PrincipalName username attribute (example FOO\jdoe) in the sync with foo.com. Because msDS-PrincipalName attribute values are constructed using the domain’s NetBIOS name, the msDS-PrincipalName values post-migration will not match (example after migration OOF\jdoe) = a new sync to oof.com will create new users instead of taking over the existing users.

So, the best practice to retain existing users and their attached devices is to ensure that the same attributes and attribute values exist in your new forest so that a new sync to the new forest can take over management of the existing users.

There is more information in these knowledge base articles: