Root Cause Analysis:
Users Unable to unlock accounts following deployment of MFA Soft Lock Feature
March 3, 2017
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.
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: