Show

sorted by

Password complexity enforcement with delegated authentication

Hello Community,

Our users are experiencing an intermittent issue with password resets, specifically with respect to password complexity. They receive errors that their new passwords violate a constraint; however, when we try this password with a test account or in some instances, they try the same password again at a later time, it works.

In trying to troubleshoot the problem, we are trying to reduce the number of moving parts, so we can isolate and eradicate the problem. I was hoping to get some help understanding how Okta handles password complexity enforcement when authentication is delegated to AD.

So in the admin console there are two places that I have found where you can configure password complexity in a delegated environment like ours...

Security > Authentication > Active Directory > Delegated Authentication > Active Directory Password PolicyWe currently have Okta configured to allow AD password resets and also perform forgotten password resets. The Password Rules Message specifies our length and complexity requirements, but the label implies (to me anyway) that Okta isn't enforcing this as policy. It is merely informational. Okta is allowing you to enter some text which would inform users of our password policy in the event that an error occurs.

Security > Policies > Password PolicyHere you are able to set a password length and complexity policy; however, I believe this only applies to Okta only accounts. Since all of our user profiles are mastered by AD, these policies would not apply to any of our end users.

I guess I'm looking for confirmation that my understanding of Okta's password complexity enforcment is correct. In summary... For accounts with delegated authentication password complexity enforcement is also delegated. And the "Password Policy" only applies to Okta only accounts.

Your assumption is correct. The Okta Password Policy (Security > Policies > Password Policy) only applies to Okta-mastered users. Okta does not enforce any password policy requirements for AD delegated authentication users. We are cooking up a killer new soft-lock feature for AD that changes this assumption so lookout for the beta if you are interested.

The custom error message in Security > Authentication > Active Directory > Delegated Authentication > Active Directory Password Policy is available to help provide a description of your AD password policy as Okta doesn't know the AD password policy and will just receive a generic ADSI error when resetting a user's password when the password doesn't meet policy.

Most likely what is going on is the fact that the AD Agent uses both the ADSI ChangePassword and SetPassword methods depending on flow (e.g expired password vs self-service reset). ChangePassword requires the user's existing password. AD may not be enforcing all policy options during SetPassword.

All Answers

api-workday api-workday

Hi Phil,

I can share my experiences and understanding.

My setup, AD accounts with delegated auth. We also have some okta mastered accounts. My understanding and experience aligns with your description of the policies you describe above. 1 enforces the other informs.

We enforce a base password policy in Okta (it tends to coincide with our AD password policy as much as possiible).

When changing a password policy for a user with AD delegation it must meet the minimim requirements defined in Okta password before even being passed to AD.

Some of the password policy is self explanatory but there are additional validations described better here.http://developer.okta.com/docs/api/resources/users.html#credentials-object

After it has passed the okta validation it still must comply with the AD password policy (or fine grained password policy)

The problem we often see that might account for what you are seeing is.1- Password history2- Password complexity (including portions of their name)3- minimum password age

I don't know if you'll see an indication of failing to meet the password policy in Okta logs

I do know you'll see a failure to meet ad policy in the ADagent logsHope that helps-Matt

Your assumption is correct. The Okta Password Policy (Security > Policies > Password Policy) only applies to Okta-mastered users. Okta does not enforce any password policy requirements for AD delegated authentication users. We are cooking up a killer new soft-lock feature for AD that changes this assumption so lookout for the beta if you are interested.

The custom error message in Security > Authentication > Active Directory > Delegated Authentication > Active Directory Password Policy is available to help provide a description of your AD password policy as Okta doesn't know the AD password policy and will just receive a generic ADSI error when resetting a user's password when the password doesn't meet policy.

Most likely what is going on is the fact that the AD Agent uses both the ADSI ChangePassword and SetPassword methods depending on flow (e.g expired password vs self-service reset). ChangePassword requires the user's existing password. AD may not be enforcing all policy options during SetPassword.

One other constraint that needs to be considered is on the AD side and has to do with how frequently a user may change their password. I have seen cases where users are only alowed to change their password once in a 24 hour window.

I would like to point out that this was in direct contradiction to what Okta support was telling us in one of our long running support cases regarding intermittent password reset failures. This lead to a lot of interal discussion and confusion which I believe has allowed this issue to linger much longer than necessary. Now we can isolate the failures to our AD or how the Okta AD agent(s) are interacting with our AD, we have a much better chance of troubleshooting the problem.

We also have AD delegation enabled and we've set the same password policy in OKTA as in AD.

From the above discussions,it looks like even though OKTA & AD has same password policy , 2 features will not work when users try to reset password from OKTA portal :1) enforce minimum password age &2) password history requirements.

Is there any other way to enable these 2 features. Because i think, if users set the password as the previous one and keep doing that, we might face security issues.