Password synchronization fails between Okta Org2Org applications when System for Cross-domain Identity Management (SCIM) and Just-In-Time (JIT) provisioning are enabled, setting user credentials to a federated type, or when password policies mismatch between the Hub and Spoke tenants. Resolve this by removing JIT from the Identity Provider (IdP) and either re-provisioning the user via SCIM or disconnecting the user from the IdP. The password synchronization fails with one of the following errors and corresponding task failures.

Push new user to external application failure:

API validation failed: password (password: Password requirements were not met. Password requirements: at least 10 characters, a lowercase letter, an uppercase letter, a number, a symbol, no parts of your username. At least 1 day(s) must have elapsed since you last changed your password

FAILURE: Api validation failed: password (password: Password).

Automatic provisioning of user Test Test to app Okta Org2Org failed: Error while creating user test.test@okta.com: HTTP error 400 (Older version of the same error).

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Password Sync
• Application Programming Interface (API) Services
• System for Cross-domain Identity Management (SCIM)

If password policies match, the error occurs because SCIM and JIT provisioning are enabled for the Org2Org application. The user credentials are set to the FEDERATION type, which prevents password synchronization because a federated user has no password that Okta can update. Review the following Postman body example showing a federated user credential type.

A mismatch in password policies between the Hub Okta tenant (target - Service Provider (SP)) and the Spoke Okta tenant (source - IdP) also causes this error.

How are Org2Org password synchronization failures resolved?

The user must not be sourced by the Security Assertion Markup Language (SAML) IdP for the synchronization to work. Remove JIT from the IdP. Okta cannot synchronize passwords for users sourced by the IdP with credentials backed by it. Resolve the issue for affected users using one of the following two methods.

Re-provision the user via SCIM.

Re-provision the user via SCIM by removing the user from the Spoke and Hub applications and re-adding them to the Spoke application.

1. Remove the user from the application in the Spoke tenant.
2. Delete the user from the Hub tenant.
3. Re-add the user to the Org2Org application in the Spoke tenant and allow Okta to re-provision the user.

Disconnect the user from the IdP.

Disconnect the user from the IdP on the Hub tenant, deactivate de-provisioning from the To App page, unassign the user, and re-assign the user to the Org2Org application.

1. Disconnect the user from the IdP on the Hub tenant.
   
2. Deactivate de-provisioning from the Provisioning > To App page.
   
3. Unassign the user from the Org2Org application.
4. Re-assign the user to the Org2Org application and allow Okta to provision the user.

Related References

• Okta Password Policy
• Okta API docs for user credentials time identification