Root Cause Analysis - March 3 2017 User Accounts Unable to be Unlocked Skip to main content
https://support.okta.com/help/oktaarticledetailpage?childcateg=&id=ka02a000000xalusak&source=documentation&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fdocumentation%2fknowledge_article%2froot-cause-analysis-march-3-2017-user-accounts-unable-to-be-unlocked
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.
Average Rating:
Root Cause Analysis - March 3 2017 User Accounts Unable to be Unlocked
Published: Mar 15, 2017   -   Updated: Mar 15, 2017
Root Cause Analysis:
Users Unable to unlock accounts following deployment of MFA Soft Lock Feature
March 3, 2017 
    
Problem description: 
On Friday, Mar 3rd, 2017 at approximately 5:45am PST, a subset of users in Okta tenants configured for delegated authentication began experiencing issues with accounts being locked in Okta with no ability to successfully unlock via self-service or administrator initiated unlock.

Root Cause: 

Okta deployed a new feature, MFA Soft-Lock, within the 2017.05 release.  This feature provides the ability for Okta tenants configured to use delegated authentication to Soft-Lock (lockout the Okta account only) accounts upon incorrect entry of five incorrect multifactor authentication prompts. A bug in the MFA Soft-Lock feature did not correctly handle all legacy user-states within the database.  

Prior to becoming an AD Mastered Account, Okta Mastered accounts which had become locked out resulted in a locked-out status on their user record.  If the locked-out status for the user was not cleared prior to the user becoming AD Mastered, the legacy lockout status was not removed from the account record.  The new MFA Soft-Lock feature bug observed the legacy lockout status and caused an Okta account lockout at time of MFA Soft-Lock deployment.  

Furthermore, a subset of Okta customers had misconfigured permissions applied to their Active Directory Agent service account.  In such cases, users attempting to perform a self-service unlock of their Okta accounts were unable to do so as the process is reliant upon a successful delegated unlock call to Active Directory.  Upon remedying the incorrect permissions, customers could perform the unlock operation.

Mitigation Steps and Recommended Future Preventative Measures:  
  • Okta identified the root cause and immediately rolled back the MFA Soft-Lock feature for impacted orgs.  This operation was completed at 11:09am PST, Friday, Mar 3rd, 2017.
  • Okta is working to identify users still retaining this legacy locked out status within all customer tenants and will remove this Okta legacy state to prevent this issue from occurring in the future.    
  • Additionally, Okta will be reaching out to customers to ensure appropriate Active Directory service account permissions are in place for ORGs with self-service account unlock functionality enabled. 
  • Okta has identified a gap in the release notes process which caused the release of this feature for existing orgs to not be highlighted in our release notes.  This process gap is being addressed to ensure customers have visibility to feature changes affecting their ORGs in the future.
 
 

Post a Comment