Solving Okta's Password Complexity Provisioning Problem without Changing Passwords

During Okta’s initial application assignment it syncs over a randomly generated password based on the Okta password policy. Which is fine when Okta’s password policy is stronger than or the same as the downstream application’s password policy. But on the rare occasion the downstream application’s password policy is stronger, Okta will fail provisioning when the user.

In my case, I had an Org2Org connection set up from my Spoke Org (strong password policy) to my Hub Org (even stronger password policy). I won’t go into why my Hub Org has a stronger password policy because if you find yourself in the same situation, your reasons might be different.

Side note: I’ll be referring to the Spoke Org as the source and the Hub Org as the target application for the rest of this article. I can’t wrap my head around Okta’s terminology. To me there is one hub in the center of a wheel and many spokes that come out from the hub.

Okta’s recommendation for this problem, is to bring the password complexity up on the source app to match the password complexity on the target app. https://support.okta.com/help/s/article/Provisioning-users-to-an-application-fails-because-of-password-complexity

Unfortunately, this was not possible for me, at least not without some pushback from our employees having to create new passwords or __ strict security requirements. Luckily, we were able to solve the provisioning errors automatically using Okta Workflows, without any user having to change their password.

Maybe when I said without changing password policies I wasn’t being truthful. We will need to create new password policies and move users to the password policy. But in the end, users will not have to change their password and they will still be provisioned into the target organization.

sdf

To start you should have an Org2Org application and a group that is assigned to the Org2Org app, for me that group is named org2org_users. This method will not work with individual assignments. Everything will be done in the source Okta org.

First, create a two new groups, I named them org2org_password_complexity and org2org_provisioning. Next, create a new password policy, the password complexity should match the target Org2Org’s password complexity and assign it to the password_complexity group from the previous step.

Lastly, create a new Global Session Policy named “Org2Org Provisioning Sign-In Block”. Assign it to the password_complexity group and add one rule with Access is Denied. This is important because if the user attempts to sign into Okta while they are in the password complexity group, Okta will ask them to update their password to meet the new policy.

Great, now we’ll jump into Okta Workflows.

The first workflow is triggered whenever a user is added to a group. Add in the first action card continue if the group id equals the org2org_provisioning group id. If that is true, we want to add the user to the org2org_password_complexity group, this bumps their password policy and also blocks login. And also the org2org_users group which triggers the application assignment and provisioning. The workflow waits for 30 seconds for the provisioning to finish, then removes the user from the password_complexity group to drop down their password policy and allow logins again.

The other workflow is simpler, just to remove users from the app assignment when they are removed from the provisioning group.

If you had users assigned to the org2org_users group, you should now assign them to the provisioning group. You can still use Group Rules to assign users to the provisioning group. And you should delete any group rules that automatically assign to the org2org_users group.

Dealing with failed tasks

Since the workflow waits a set period of time and not necessarily if the provisioning succeeded, or if the provisioning failed for an unrelated issue, that can leave users in a bad state where retrying the failed task will not succeed. To manually fix the password complexity problem, add the user to the password_complexity group, re-run the failed task, and then remove the user from the password_complexity group.