Password History requirements ignored for AD mastered accounts Skip to main content
https://support.okta.com/help/answers?id=906f0000000hzp5iac&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:
Chandru AroorChandru Aroor 

Password History requirements ignored for AD mastered accounts

Currently Okta lets AD mastered users reset their password to either the current password or from recent history. Note our AD policy prevents users from using passwords from recent history, as does our current password reset tool. Okta bypasses those restrictions. Our QSA has ruled Okta as PCI in-scope as a supporting system and if we move forward with Okta we will likely fail our PCI audit.  As a result we have halted our Okta implementation because this is a violation of PCI DSS 3.0 requirement 8.2.5.

Okta has acknowledged this as a defect and plans on starting work on the fix in March 2016 or so. No telling when the fix will actually be available.

If someone has faced this issue, have you implemented any workarounds? Perhaps implemented your our API?

api-workday api-workdayapi-workday api-workday
Hi Chandru,

Okta allows you to allow your users to perform password recovery operations.  This is a configurable option and can easily be disabled.

have a read on this thread it does a wonderful job of explaining the various methods Okta leverages to perform password resets.

https://support.okta.com/help/answers?id=906F0000000blVyIAI

The notion that Okta is ignoring the password history is a little overstated. The setPassword method doesn't evaluate password history. That said Okta could overcome this deficiancy by providing the user a preexpired password and allowing them to then enter a flow that leverages the changePassword method. If your auditor is a stickler you might need to increase the enforced passwordHistory requirements within your domain to n+1 as the preexpired 'temporary' password that okta (or anyone) for that matter would be unnaturally popping an old password out of the retained history.

Workaround: don't enable the self-service feature and continue using your existing password reset tool that complies until Okta modifies their password recovery process.

-Matt
Parth SwadasParth Swadas
Hello Matt,

We raised a case with OKTA 2 months back and we received an update on Nov 18th "A fix was designed and will be released in a future update"

Case #00119624

/Parth
Jose KimJose Kim
Thanks for the helpful info.  

Has there been update to address the last four passwords requirement?