Overview

If you're currently using delegated authentication through Active Directory (AD) to perform user authentication, and you instead want Okta to perform this authentication, you need to migrate your users' passwords from AD to Okta.

Solution

A secure and phased password migration method, which is transparent to end users, is available from the Provisioning tab of an Active Directory (AD) instance. This one-time process enables you to seamlessly move user passwords from an AD instance to Okta.

How can I enable the feature for my organization? 

Please contact open a case and reach out to  Okta support to request to enable the FF. 

Frequently Asked Questions

Implementing and Monitoring a Campaign

Finishing a campaign switches DelAuth off for the entire AD instance. Can we run the campaign per group and then disconnect only the users belonging to the specific group from AD?

Finishing the campaign will indeed disable Delegated Authentication (DelAuth) for the entire connected AD instance. However, the migration itself at a group level. You can select groups to migrate one at a time over a set timeframe. When a user from a selected group signs in, their password is migrated, and DelAuth is immediately disabled for that specific user. Only click "Finish Campaign" once you are satisfied that all necessary groups have completed the trickle migration process. The timeframe of the campaign can extend from weeks to months based on the number of users in your AD Instance and internal change management processes. 

After finishing the campaign, delegated authentication can still show enabled since, after the campaign is finished, it will trigger a job, and only after the job is finished will delegated authentication appear disabled.

I've migrated a group, but the captured password count is not reaching 100%. Why is that the case?

It’s common for the capture rate to not reach 100% of the group size due to users who are not eligible for migration. Common reasons include: 

Non-AD Sourced Users: The selected Okta group contains users sourced from a system other than the AD instance in question. 

Multi-Directory Sourcing: The user is sourced from multiple directories that have Delegated Authentication enabled. To migrate this user, disable delegated authentication in all other directory instances this user is a part of except the one in which the campaign is running.

Passwordless Authentication: The user has only authenticated using a passwordless factor (e.g., Okta FastPass) and has not yet entered their password during the campaign window. 

Why has a user belonging to a single DelAuth enabled AD instance successfully entered their Okta password and logged in but has not been migrated?

There can be two reasons for the user password migration to not take place for the described case:

Is there an easy way to query or view which specific users in a group have and have not yet had their password captured?

The following syslog event provides information on the users that have been successfully processed: app.ad.password_migration_campaign.user.migrate.end 

(Find all migration related events here: Developer.okta.com)

A CSV report of all the processed users can be downloaded and compared with the Group Membership list to identify which users have not been captured yet.

To Note: In GA we will be providing an option to directly download a CSV report containing this information but the two step method mentioned above will provide the same information.

In case a campaign is completed and we have migrated all the users to Okta and everyone relying on DelAuth has been disconnected, what would be the roll-back plan in case we’d need to go back?

The feature includes simple rollback mechanisms, both during and after the campaign: 

During the Campaign: If you select "Cancel Campaign," all passwords migrated up to that point are deleted, and DelAuth is reinstated as the authentication method for all users, reverting the entire AD instance state. 

After Completing the Campaign: You can simply re-enable Delegated Authentication from the Admin console. This will revert the authentication source for all users back to AD, just as it was before the migration process began.

End-User Password Management

Will the user's password in Okta be updated if an end-user modifies their password locally in Active Directory, either through the Ctrl+Alt+Del method or any alternative means?

It is critically important that end users do not reset their password locally in AD once their password has been successfully migrated to Okta. If a user resets their AD password post-migration, the credentials will be out of sync, leading to access issues and subsequent helpdesk tickets. This requirement is a major component of the necessary change management process. All password resets for migrated users must be performed in Okta.

For users who primarily use Okta FastPass or other passwordless methods, how can we ensure their password is captured during the campaign?

For successful user password migration within the campaign, users are required to enter their plain text password on the Okta Sign-in widget. In instances where users employ passwordless authentication factors, administrators have the option to temporarily modify the authentication method for a frequently utilized application to password entry. Additional methods are detailed in the accompanying help documentation: Password migration considerations | Okta Identity Engine 

When a user's password is successfully migrated to Okta, when does the Okta password expiry counter (if enabled) begin?

The counter for the password expiry will start immediately as the user password is successfully migrated into Okta.

Related References

• Password migration from AD to Okta
• Developer.okta.com