This article will explain what caused the Org2Org provisioning with Password Sync enabled to fail due to the following error in Spoke org for certain Org2Org app assignments:

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

• Org2Org Provisioning with Password Sync Enabled
• Okta Integration Network (OIN) 
• Existing or pre-created target provisioned user account in the Hub org
• Credential Provider Type set to "FEDERATION" (Passwordless user) 

This issue is normally caused by Okta's inability to push the password sync from the Spoke org into the Hub org. The most common scenario is that the target provisioned user has been pre-existing in the Hub org, and the target provisioned user's Credential Provider Type value is not currently set to "OKTA", which is required for the Org2Org Provisioning with Password Sync to work. 

It is important to understand that the "FEDERATION" credential provider type is also known as the Passwordless user account type, as it normally utilizes SAML IDP Federation SSO authentication, which does not require any password authentication. As a result, the Password Sync action cannot be completed for the Okta user account that has the "FEDERATION" credential provider type in the Hub org. The Credential Provider Type must be set to "OKTA," and the user account status must be 'ACTIVE' for the Org2Org Password Sync to complete successfully. 

To verify, please follow below troubleshooting steps: 

1. Spoke org's Okta Admin will work with Hub org's Okta Admin to verify whether the target provisioned matching user account already exists/is pre-created in the Hub org.
2. If yes, Hub org's Okta Admin will then run the GET User API call after obtaining the target userId in Hub org and then verify the problematic user's Credential Provider Type value. 

GET/api/v1/users/${userId}

For the sample problematic user, the GET User API call confirms that the Credential Provider Type is set to "FEDERATION" instead of "OKTA", as demonstrated in the GET User API response below:
 

Actual returned for problematic user: 

...
credentials": {
    "provider": {
      "type": "FEDERATION",
      "name": "FEDERATION"
    }
  }, 
....

Expected: 

...
credentials": {
    "provider": {
      "type": "OKTA",
      "name": "OKTA"
    }
  }, 
....

Before deciding which solution to apply, conduct a thorough investigation and review the current app configuration to ensure alignment with long-term business requirements and use cases. Therefore, Internally review the following:

1. Is this an old or discontinued user creation configuration or an ongoing new user creation flow?

   • When was the user created in the Hub org, and by whom?

   • How was the user created with the FEDERATION credential provider type? Was it through external IDP JIT provisioning or programmatically via Okta API?

2. If both Org2Org Provisioning with new user creation and Org2Org SAML JIT Provisioning are enabled, it's important to consider Okta's best practice recommendation. A decision needs to be made on whether to keep Org2Org SAML JIT provisioning or Org2Org provisioning.

3. If the decision is to keep Org2Org provisioning, further discussion is needed about whether Org2Org Provisioning > Password Sync needs to be enabled.

In general, if the organization enforces Org2Org SAML IDP SSO login, users will not need a password to log into their Hub org. They will be redirected to the Spoke org for Org2Org SAML IDP login. The synced password will only be used to log into the Hub org if the end user bypasses the IDP routing rule and accesses the default Hub org login page.

There are two possible solutions:

• Manually deactivate/delete the problematic user from the Hub org and then allow a new user account to be created in the Hub org via Org2Org Provisioning > Create New User with Password sync from the Spoke org.
• If manual user deletion/recreation is not feasible for business reasons, the only other way to avoid the error is to convert the "FEDERATION" credential provider type user to an "OKTA" credential provider type user using the Okta API call.

To convert the "FEDERATION" credential provider type user to an "OKTA" credential provider type user using the Okta API call:

1. Use a preferred REST API client tool and execute the following Reset_Password Okta API call. Have the end-user or admin user set a temporary password to ensure the account status is 'Active' in the Hub org. Refer to Okta API Documentation for details.

Request Header:

POST {{url}}/api/v1/users/{{userId}}/lifecycle/reset_password?sendEmail={{false OR true}}

Request body: 

credentials": {
    "provider": {
      "type": "OKTA",
      "name": "OKTA"
    }
  }

• • See the screenshot below for the sample API call made via POSTMAN for a problematic Hub org Okta user with a FEDERATION provider type. 
    
     
    
    
  • Replace the userId with the target Hub org user's userId. 
  • NOTE: If kept in sendEmail=false, a resetPasswordURL link will be generated, as depicted in the screenshot. This link can be shared with the end user or another business-approved candidate to enable them to reset their Hub org user account password. If email delivery to the end user is preferred, change to sendEmail=true. By doing so, the end user will receive an email containing instructions on how to reset their Hub org password. This password will be temporary. Once the Org2Org provisioning process is completed and the password sync push action occurs, the password synced from the Spoke org will overwrite the manually set password that was established during the reset-password procedure.

2. After the Okta password is set, the account will change from One-Time password mode to Active.
   
    to    
   
   
3. Then retry the failed Org2org app assignment/provisioning task again from Spoke org (with Org2Org app) > Dashboard > Tasks page > Retry failed task. It should be able to complete the App assignment/initial provisioning with password sync this time without the previous application API password sync error. 
4. Apply the same solution for all impacted users.