Run a password migration

Early Access release

The password migration process is transparent to end users. While a migration is in progress and a user signs in to Okta using their password, it's securely captured and migrated. Okta immediately takes over authentication for that user. After the entire migration is complete, Okta handles all user authentication for all migrated users, replacing delegated authentication through AD.

A password migration involves three key phases: starting, monitoring, and ending the migration. After the migration is complete, you need to ensure that end users can properly perform password resets, and you must understand how to handle new users.

• Start a password migration
• Monitor a password migration
• End a password migration
• Handle post-migration password resets
• Handle new users post-migration

Before you begin

Sign in as an admin with the following permissions:

• Manage directories
• View groups

Start a password migration

1. In the Admin Console, go to DirectoryDirectory Integrations.

2. Select the AD instance whose users' passwords you want to migrate.
3. Click the Provisioning tab.
4. Click Password migration under Settings.
5. Optional. Select Enable password sync. When you select this option, any password changes made in Okta during or after the migration are synchronized back to AD. This is useful for legacy apps that use the AD password. Enabling this option is recommended. See Handle post-migration password resets.
6. Click Start campaign.
7. Search for and select the groups whose users you want to migrate. Click Migrate to start migrating passwords from the selected groups.

Monitor a password migration

While a password migration is running, you can monitor its progress by clicking the Migrated groups tab from the Password migration page. This tab displays the progress of the migration, including the number of successfully migrated passwords for each group. Some discrepancies may appear in the group migration numbers, which may occur for any of the following reasons:

• If any migration groups include members from other AD instances, those members' passwords aren't migrated. However, they're included in the member count for those groups.
• If a migration group contains members whose passwords are already in Okta, those members' passwords aren't counted in the migrated passwords, but the member is included in the total count of group members.
• If a member of a migration group belongs to other migration groups, only their successful password migration for the first group that they belong to is counted. The migration password count for the member's other migration groups isn't increased.

When you're either satisfied that enough passwords have been migrated or you want to cancel the migration, proceed to the next section.

End a password migration

You can end a password migration in one of two ways: finish it to disable delegated authentication to AD for the entire AD instance, or cancel the migration and revert any changes.

Finish a password migration

During a migration, you should regularly check its Migrated groups page. When you're satisfied that enough passwords have been migrated, click Finish campaign. This ends the migration by performing the following actions:

• Disables delegated authentication: Delegated authentication is disabled for the AD instance.
• Disables Just-In-Time (JIT) provisioning and Universal Security Group support: Both JIT provisioning and profile reload for the AD instance are disabled. This is because JIT relies on delegated authentication, which is now disabled for the AD instance, ending its ability to provision users.
• Sends password reset emails: Optional. When you finish a migration, select the Create Okta password option to send a password reset email to users whose passwords weren't captured during the migration. This ensures that the user is able to sign in after the migration is complete. Selecting Don't create Okta password means that users whose passwords weren't captured during migration will need to contact support to sign in.

Users whose passwords weren't successfully migrated may be unable to access their work email before they've reset their password. To ensure that your users can access their password reset emails, use one of the following methods to ensure their access:

• Send the password reset emails to each user's secondary email address, which should be a personal account that they can access.
• Allow users to authenticate to Okta using a factor other than password.

Cancel a password migration

You may decide to abandon a password migration that's already in progress. To do so, go to the Passwords migration page and click Cancel campaign. This stops the password capture process and reverts the AD instance to its state before the migration began.

When you cancel a migration, all migrated users in the selected groups are reset, and their login type is reverted to delegated authentication.

Handle post-migration password resets

After a successful migration, your users need to know that they must make any password changes in Okta.

If you want to synchronize password changes in Okta to AD after the migration, ensure that you select Enable password sync when you start a migration. This ensures that all password reset events initiated by the user, both during and after the migration, are synchronized back to AD after the password has been migrated.

Handle new users post-migration

When a migration finishes, JIT provisioning is disabled. This is because JIT relies on delegated authentication, which is disabled for the AD instance, ending its ability to provision users. Keep the following in mind when you create users after the migration:

• A user must exist in Okta for them to be able to sign in.
• Any new users imported into Okta after the migration need to set their password when they sign in for the first time.

Related topic

Role permissions