Question About AD Password Migration and Login Failures in Okta

Hi @ShoichiroK.00155 (LAC Co., Ltd)​ , Thank you for reaching out to the Okta Community! 

You are asking whether any AD passwords could fail to work in Okta after migration, covering unsupported characters, policy conflicts, known limitations, and an official list of unsupported characters.

Summary: Okta does not publish a standalone blocklist of password characters for migration, so the reliable approach is to validate the specific password types in your directory during a pilot before the full rollout.

Root Cause: Active Directory stores passwords as one-way hashes and does not expose clear-text passwords, so Okta cannot copy them directly from AD. Migration therefore depends on the method used to validate or import passwords, and each method has its own limits.

Solution: Review each limitation below and validate it with a pilot group before the main campaign.

1. Review the character and length limits. Okta supports a maximum password length of 72 characters, and this limit applies to Active Directory, LDAP, and Okta-mastered users alike. Any AD password longer than 72 characters will not be usable in Okta. Okta's published documentation does not list a separate set of unsupported Unicode or control characters for migration. Test passwords that include non-ASCII characters, leading or trailing spaces, and control characters with a pilot group.
2. Confirm the migration method before you rely on password behavior. If Delegated Authentication to Active Directory remains enabled, the AD agent validates each sign-in, so the user keeps the same AD password and Okta password policy does not apply to that validation. If you import password hashes through the Password Import Inline Hook or the bcrypt hash import API, the imported password is stored in Okta, and the hash algorithm must be one that Okta supports.
3. Check the password policy behavior. Changing or tightening the Okta password policy does not force existing passwords to change. The new policy applies when a user sets or resets a password, through self-service, expiration, or an administrator action. A password that does not meet the current policy can still be used to sign in immediately after migration, and the user is prompted to change it only when the policy requires a change.
4. Note the known limitations that can cause a migrated password to fail:

• An org supports only one Password Import Inline Hook, so only one external password source can be migrated through that hook.
• Hash algorithms that Okta does not support cannot be imported, and the import must match the original hash exactly.
• A password expiration prompt can appear for users whose profile is mastered in Okta, and it can conflict with Delegated Authentication settings. Confirm the "Prompt user x days before password expires" setting and the user's password master before the migration.

1. Validate the migration with a pilot. Select a representative set of users, including users with special characters, long passwords, and different password master settings. Confirm sign-in through the Okta sign-in page for each group, and review the System Log for failed password import or authentication events. If a pilot user fails, use the Okta troubleshooting article on imported hashed passwords to isolate the cause.

Sources:

Okta Community thread on the Password Import Inline Hook and the single-hook limitation — https://support.okta.com/help/s/question/0D54z00007dBwSrCAK

Okta Community thread on the maximum password length of 72 characters — https://support.okta.com/help/s/question/0D51Y00008C1jzWSAR

Okta Community thread on Delegated Authentication and Okta password policy — https://support.okta.com/help/s/question/0D5KZ00001Qohsb0AB

Okta Community thread on how password policy changes apply to existing users — https://support.okta.com/help/s/question/0D54z00009sh7yyCAA

Okta Community thread on password policy changes applying to new passwords only — https://support.okta.com/help/s/question/0D54z00007WigyOCAR

Okta knowledge article on importing a user through the API with a bcrypt hash — https://support.okta.com/help/s/article/how-to-import-a-user-through-api-using-bcrypt-hash

Okta knowledge article on users unable to log in with an imported hashed password — https://support.okta.com/help/s/article/Users-are-unable-to-login-using-imported-hashed-password

Okta developer guide on migrating to Okta with password hooks — https://developer.okta.com/docs/guides/migrate-to-okta-password-hooks/main/

Please follow up with Okta Support or your Okta Account Executive for account-specific verification of your migration method, because the directory configuration determines which of these limitations apply to your users.

If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you. 

Hope my answer helps! 

--

Help others in the community by liking or hitting Select as Best if this response helped you.

Collect them all. Learn a new skill and earn a new Okta Learning badge.

Just released: More Okta Community badges just added