One feature of the Okta service is to provide an administrator with a comprehensive review of all events in order to provide an audit trail that can be used to understand platform activity and diagnose potential problems. 

This article provides details on how to audit Okta System Log for any resets or updates to passwords and other factors by an Okta Administrator or by a Technical Support Engineer (TSE). This article also explains how to search for queries for impersonation access by a TSE, which can only be granted by an Okta Administrator during an engagement with Okta Support. 

Please note that events are only retained in the Okta System Log for three months. Customers may leverage their own SIEM (Security Incident Event Management system) to retain data over longer periods. 

While Okta has published more exhaustive reference documents with instructions on how to review events in the Okta System Log, this document is intended to provide specific answers to questions raised by customers over the January 16 - January 21, 2022, compromise of devices on the Sitel network. As a result, the scope of this discussion is limited to explanations of showing how to audit the administrative actions a TSE (Technical Support Engineer) could take on an Okta customer tenant or events a TSE might undertake if an Okta Admin seeks for a TSE to “impersonate” their access to the Admin console for a temporary period for troubleshooting support issues. We have also included step-by-step instructions on how to perform password resets and/or enroll MFA, if one wishes to do so.

For further information on this functionality, please open a case with Okta customer support. 

End-User Password Reset - Okta System Log Search

The following steps allow an Okta administrator or security analyst to search for end-user-initiated password resets, admin-initiated password resets within the Okta org, and a TSE-initiated password reset. A successful password reset log entry means that a password reset occurred and documents when that successful password reset took place. 

It is important to understand that while a TSE can initiate a password reset, a TSE cannot see the new password or change the password. This is because the TSE would require access to the relevant user’s email inbox or to answer a factor/challenge in order to see the new password or change the password successfully.

1. Log in to the Okta Admin Console.
2. Navigate to Reports > System Log.
3. In the search section, paste in the following query to search for successful password reset events for both an admin authenticated in the Okta Admin Console  as well as self-service reset by the end user:

eventType eq "user.account.reset_password" 

4. To search for events initiated by a Support Engineer, use the following query: 

eventType eq "user.account.reset_password" AND actor.alternateId eq "system@okta.com" AND transaction.id eq "unknown"

5. To search for events when an admin initiated a ‘reset password email’ link in the Okta Admin Console, use the following query: 

eventType eq "system.email.password_reset.sent_message"

6. To search for events with a password update, use the following query: 

eventType eq "user.account.update_password"

NOTE: This event is also logged when an admin initiates a ‘Temporary Password’ link in the Admin Console.

 

7. To search for events with a temporary password sent by a TSE, use the following query: 

eventType eq "user.account.update_password" AND actor.alternateId eq "system@okta.com"

End-User MFA Reset - Okta System Log Search

The following steps will allow the search for MFA factor resets within the Okta tenant. A successful MFA factor reset log entry means that a factor reset occurred. It identifies which factor was reset and when the factor reset took place.

1. Log in to the Okta Admin Console.
2. Navigate to Reports > System Log.
3. In the search section, paste in the following query to search for a successful MFA reset by an admin authenticated in the Okta Admin Console: 

eventType eq "user.mfa.factor.deactivate"
 

4. To search for a query to reset all MFA factors by an Okta admin authenticated in the Admin console or by a TSE, use the following query: 

eventType eq "user.mfa.factor.reset_all"
 
NOTE: If initiated by a TSE, the actor name will be the TSE name. If initiated by an Okta Admin in the Admin Console, the actor name will be the name of the Okta Admin. 

To Enable MFA for All User Accounts in Okta Classic

Please note that Okta recommends Multi-Factor Authentication (MFA) as a best practice in identity management.  The following procedures provide the details on how to enable MFA accounts as an Okta administrator:

1. Log in to the Okta Admin Console.
2. Navigate to Security > Multifactor.
3. Click on the Factor Enrollment tab.
4. Click on Add Multifactor Policy. Give it a policy name and description.
5. Select the group for which the policy should apply. It is recommended to choose the specific groups per organization's security requirements rather than applying it to everyone. In this example, the 'Everyone' group will be used.
6. Under Effective Factors, select all factors that should be supported for the organization. The required factors must be enrolled by the users. Optional factors allow the support of other common factors. Note that the security is only as strong as the weakest factor, so Okta does not recommend the use of SMS, Voice, or Security Questions.
    
7. For the example above, all users will be required to enroll for Okta Verify/Push, Google Authenticator, and FIDO2 (WebAuthn) on their next login to their Okta org. As this is an example list, the organization may choose to select other factors to meet security requirements.  
8. Click Create Policy.

To Enable MFA for All User Accounts in Okta Identity Engine (OIE)

1. Log in to the Okta Admin Console.
2. Navigate to Security > Authenticators.
3. Click on the Enrollment tab.
4. Click on Add Multifactor Policy. Give it a policy name and description.
5. Select the group for which the policy should apply. It is recommended to choose the specific groups per organization's security requirements rather than applying it to everyone. In this example, the 'Everyone' group will be used. 
6. Under Effective Factors, select all factors that should be supported for the organization.  The required factors must be enrolled by the users. Optional factors allow the support of other common factors.  Note that the security is only as strong as the weakest factor, so Okta does not recommend the use of Phone or Security Questions.
    
7. For the example above, all users will be required to enroll in Google Authenticator, Okta Verify, and FIDO2 (WebAuthn) when they log in to their Okta tenant. 
8. Click Create Policy.

To Enforce User Password Reset as an Admin

As stated previously in our security advisories, we are confident in our conclusions that the Okta service has not been breached, and there are no corrective actions that need to be taken by our customers to reset passwords of their end users. We are offering information related to this activity to provide a comprehensive guide to self-administration activities that an Okta admin can perform within their Okta Org. For more information related to our security event, please visit our Frequently Asked Questions and our Okta Security Blog.
 

As an Okta Administrator, if there is a desire to reset a user's password in the Okta Admin Console, it is possible to do so easily by following the steps below:

1. Log in to the Okta Admin Console.
2. Navigate to Directory > People.
3. Select an active user by clicking on the user in the ‘Person & username’ column. 
4. Click on Reset Password.
    
5. The next screen provides two options. Select one that applies.

 
A reset password link is sent to this user's primary and secondary email addresses. If the user has an Okta-sourced password, it is automatically reset, and the user must click this link to change it. If the user has an AD or LDAP password, it is not reset until the user clicks this link. The link expires in 1 hour.

A temporary password is created for the account and shown to the admin who created it. The account is then marked as expired so that the user is required to change their password the next time they sign in.

To Check if Impersonation Access was Initiated by Okta Support

Customer Super Admins have the ability to grant Okta customer support impersonation access to the customer’s Okta org. Customer Super admins can grant this impersonation access for 8 hours or for additional 24-hour increments. When an Okta Support Engineer initiates impersonation access into an org for troubleshooting issues, there is always an entry logged in the Okta System Log. The following steps show how to search for an impersonation entry. 

1. Log in to the Okta Admin Console.
2. Navigate to Reports > System Log.
3. In the search section, paste in the following query to search for impersonation access: 

eventType eq "user.session.impersonation.initiate"
 

To Check if Impersonation Access was Terminated by Okta Support

After the completion of a support session, the Support Engineer signs out of the active session. This action creates an entry in the Okta System Log. The following steps show how to search for a log entry for an impersonation end. 

1. Log in to the Okta Admin Console.
2. Navigate to Reports > System Log.
3. In the search section, paste in the following query to search for impersonation access: 

eventType eq "user.session.impersonation.end"
 

CORRECTION 04-12-22

The original text of this article included a suggested query for "User password reset sent to user email account from SuperUser" that generated false positives, as the same query also returns examples of self-service password resets. The modified query (which adds "transaction.id eq "unknown") returns the correct result. The following query, which uses the "not equals" operator, returns self-service password reset events:

eventType eq "user.account.reset_password" and actor.alternateId eq "system@okta.com" and transaction.id ne "unknown"
 

Related References

• System Log Queries for Attempted Account Takeover