<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D50Z00008G7VRoSANOkta Classic EngineAdministrationAnswered2024-04-17T12:38:40.000Z2015-12-23T15:33:55.000Z2017-05-03T03:57:59.000Z

Chandru Aroor (Customer) asked a question.

Edited by varun.kavoori1.5210444522562532E12 September 5, 2018 at 1:20 AM
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?

  • 3 answers
  • 1.45K views

  • svcV.75126 (Customer)

    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
    Expand Post

  • Parth Swadas (Customer)

    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
    Expand Post

  • pl4su (pl4su)

    Thanks for the helpful info.  

     

    Has there been update to address the last four passwords requirement?
This question is closed.
Loading
Password History requirements ignored for AD mastered accounts