Password complexity enforcement with delegated authentication Skip to main content
https://support.okta.com/help/answers?id=906f0000000blvyiai&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fanswers
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Phil IbarrolaPhil Ibarrola 

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 Policy
We 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 Policy
Here 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.

Thanks,
Phil


 
Best Answer chosen by Phil Ibarrola
Karl McGuinnessKarl McGuinness (Okta, Inc.)
Hi Phil!

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.

ChangePassword
https://msdn.microsoft.com/en-us/library/aa746341(v=vs.85).aspx

SetPassword
https://msdn.microsoft.com/en-us/library/aa746344(v=vs.85).aspx



 

All Answers

api-workday api-workdayapi-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 history
2- 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 logs
Hope that helps
-Matt

 
Karl McGuinnessKarl McGuinness (Okta, Inc.)
Hi Phil!

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.

ChangePassword
https://msdn.microsoft.com/en-us/library/aa746341(v=vs.85).aspx

SetPassword
https://msdn.microsoft.com/en-us/library/aa746344(v=vs.85).aspx



 
This was selected as the best answer
Jim KnutsonJim Knutson (Okta, Inc.)
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.
api-workday api-workdayapi-workday api-workday
Sonofa

I should just delete my previous post but i'll let it stand so i can shame myself with it from time to time.

I was misinterpreting failures to meet compliance from the API as not meeting the Okta requirement (assuming the task for the ADagent would run async)
 
PS C:\> oktaAdminUpdatePasswordbyID -oOrg prev -uid $ident.id -password Afnn59861234
[ PUT https://some.oktapreview.com/api/v1/users/<uid> ]
{
    "credentials":  {
                        "password":  {
                                         "value":  "Ausername1234"
                                     }
                    }
}

E0000001 : Api validation failed: password


Digging deeper, Karl is right (obviously). This password fails to meet the prevailing requirements in AD because the username is included in the password.

2015/10/02 02:03:36.133 Debug -- EU-SSOADA-DEV(51) -- Running method SetPassword on LDAP://some.dom.where.com/<GUID=CED64F65-27EB-4B4E-9858-05344AA1953A>
2015/10/02 02:03:43.039 Error -- EU-SSOADA-DEV(51) -- Exception during Directory Invoke Action
2015/10/02 02:03:43.039 Debug -- EU-SSOADA-DEV   at System.DirectoryServices.DirectoryEntry.Invoke(String methodName, Object[] args)
   at Okta.DirectoryServices.ActiveDirectoryAdapter.DirectoryInvoke(String targetDN, String method, List`1 parameters)
System.Reflection.TargetInvocationException received with message Exception has been thrown by the target of an invocation. Source=System.DirectoryServices InnerException=System.Runtime.InteropServices.COMException (0x800708C5): The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements. (Exception from HRESULT: 0x800708C5).
    Caused by System.Runtime.InteropServices.COMException received with message The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements. (Exception from HRESULT: 0x800708C5) Source= InnerException=.

SetPassword is akin to changing a users password for them in ADUC while changepassword is akin to the user changing their own password.

SetPassword won't enforce minimum password age or password history requirements

 

Phil IbarrolaPhil Ibarrola
Thanks, Karl and Matt, for your helpful replies.

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.
Phil IbarrolaPhil Ibarrola
Sorry... didn't intend to exclude Jim.  We will definitely keep password age in mind when reviewing our AD password policies.
Parth SwadasParth Swadas
Hello All,

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.